---
url: 'https://www.corbado.com/pt/passkey-benchmark-2026/passkey-authentication-success-rate'
title: 'Taxa de Sucesso na Autenticação de Chave de Acesso'
description: 'Benchmark da taxa de sucesso de autenticação de chave de acesso mostrando como os inícios de sessão se convertem em logins concluídos com confiabilidade.'
lang: 'pt'
dir: 'ltr'
keywords: 'taxa de sucesso de autenticação de chave de acesso, sucesso de login com chave de acesso, benchmark de início de sessão com chave de acesso, KPI de chave de acesso'
---

# Taxa de Sucesso de Autenticação com Chave de Acesso

*Traduzido automaticamente do inglês. Ver o [original](https://www.corbado.com/passkey-benchmark-2026/passkey-authentication-success-rate.md) →*

[← todos os benchmarks](https://www.corbado.com/pt/passkey-benchmark-2026.md)

A taxa de sucesso de autenticação com chave de acesso mostra a confiabilidade com que as chaves de acesso existentes se convertem em logins concluídos. Ela foca na camada de uso após a existência de uma credencial, onde o design de entrada, o comportamento de fallback e a cobertura entre dispositivos decidem se as chaves de acesso se tornam o caminho de login padrão.

## Taxa de sucesso por contexto do dispositivo: desconhecido vs. conhecido

*Q1 2026 · sucesso por caminho de login*

O sucesso é medido a partir do momento em que a cerimônia da chave de acesso realmente começa, ou seja, a relying party enviou o desafio WebAuthn ao cliente e o usuário está vendo o prompt de chave de acesso do sistema (Face ID / Touch ID / Windows Hello / um código QR de CDA). Ele se divide claramente em dois regimes dependendo de quão bem a relying party consegue classificar o contexto do dispositivo. A diferença entre eles é toda a história.

**Identifier-first.** O usuário digitou um e-mail ou nome de usuário e o sistema ainda não reconheceu o dispositivo.

**% CDA.** A parcela desses sucessos de chave de acesso onde o usuário teve que escanear seu telefone (Cross-Device Authentication) em vez de usar uma chave de acesso local.

### Ciclo de vida de autenticação

1. **Dispositivo desconhecido** — *55–95%*. Momento de descoberta, entrada identifier-first com Conditional UI. Cookies, memória de conta ou estado de sessão não classificaram o dispositivo. O login começa pelo campo de texto. A Conditional UI pode exibir uma sugestão de chave de acesso ou a relying party tem que adivinhar se uma chave de acesso é alcançável. Uma vez oferecido um caminho de chave de acesso, a conclusão depende muito se ela é local ou se precisa fazer ponte para outro dispositivo.
2. **Lembrar ou vincular uma chave de acesso local** — *Etapa de ponte*. Converter um sucesso em um dispositivo conhecido. Após um login bem-sucedido em dispositivo desconhecido (especialmente um concluído via CDA), crie ou lembre uma chave de acesso local neste dispositivo. Pular esta etapa é a principal razão pela qual usuários de desktop continuam pagando a taxa de descoberta a cada visita.
3. **Retorno em dispositivo conhecido** — *95–99%*. Login de retorno automático, quase totalmente local. Uma vez que o dispositivo é classificado como conhecido, a relying party direciona diretamente para o caminho de chave de acesso local. A % CDA cai para 1–5%. A conclusão se aproxima do teto técnico e o login parece invisível. O KPI termina aqui.

> **Onde as forças se encontram.** A lacuna entre desconhecido e conhecido não é apenas um problema de cerimônia. É o valor de converter um login bem-sucedido em dispositivo desconhecido em uma via rápida de dispositivo lembrado. Cada sucesso de CDA que não deixa uma chave de acesso local para trás é um custo que o usuário paga novamente na próxima visita.

### Sucesso por caminho de login

A taxa de sucesso abaixo exclui fallbacks e começa assim que um caminho de chave de acesso é oferecido. Mobile e desktop divergem drasticamente: usuários mobile geralmente fazem login no dispositivo que contém a chave de acesso, enquanto usuários de desktop frequentemente precisam fazer uma ponte para um telefone.

| Caminho de login | Sucesso da chave de acesso | % CDA |
| --- | --- | --- |
| Dispositivo desconhecido: identifier-first móvel | 85–95% | 0–5% |
| Dispositivo desconhecido: identifier-first desktop | 55–70% | 35–50% |
| Dispositivo conhecido: retorno automático de login | 95–99% | 1–5% |

*Entradas baseadas apenas em botões de chave de acesso em dispositivos desconhecidos são excluídas do mix principal: a conclusão por tentativa é alta, mas o volume é muito baixo para publicação como número primário.*

### Sucesso por plataforma

O mesmo regime identifier-first, dividido por sistema operacional. Uma % CDA maior significa que o usuário teve que pegar um telefone separado para finalizar o login.

| Segmento | Sucesso do Identifier-first | % CDA |
| --- | --- | --- |
| iOS web | 85–95% | 0–5% |
| Android web | 70–85% | 5–10% |
| macOS web | 70–85% | 10–15% |
| Windows 11 web | 45–60% | 55–65% |
| Windows 10 web | 45–60% | 40–55% |

### Regimes de diagnóstico

- **iOS & Android** (% CDA 0–10%): O telefone é o dispositivo. A conclusão de identifier-first é mais alta aqui (85–95% no iOS, 70–85% no Android) porque a chave de acesso da plataforma reside onde o usuário está fazendo login. Quase não há ponte a pagar.
- **Windows 10 / 11** (% CDA 40–65%): O telefone é separado. Mais da metade de cada sucesso de chave de acesso identifier-first no Windows é uma ponte para um telefone (55–65% no Windows 11, 40–55% no Windows 10). Toda sessão no Windows sem uma chave de acesso local lembrada paga esse custo novamente.
- **macOS** (% CDA 10–15%): Entre os dois. A maioria dos sucessos identifier-first no macOS é local (70–85% de conclusão), mas uma fatia significativa ainda faz ponte para um telefone (10–15%), geralmente quando o iCloud Keychain ainda não está ativo no Mac ou o usuário trabalha em diferentes ecossistemas.

### KPIs de Uso Relacionados

Use [Conclusão de Login com Conditional UI](/pt/passkey-benchmark-2026/conditional-ui-usage.md) para o comportamento de entrada de CUI e preenchimento automático, e [Taxa de Conclusão de Cross-Device Authentication](/pt/passkey-benchmark-2026/cross-device-authentication.md) para conclusão específica de CDA.

## Leitura complementar

Pesquisas selecionadas da Corbado e referências principais.

- **UX de login · Corbado blog** — [Passkey Login Best Practices](https://www.corbado.com/blog/passkey-login-best-practices) — Padrões de design e implementação para fazer com que as chaves de acesso existentes concluam o login de forma confiável.
- **KPI relacionado · Corbado KPI** — [Passkey Authentication Success Rate](https://www.corbado.com/kpi/passkey-authentication-success-rate) — Definição para medir tentativas de chaves de acesso que alcançam uma sessão autenticada.
- **Guia de design · Passkey Central** — [Passkey Design Guidelines](https://www.passkeycentral.org/design-guidelines/) — Recomendações de UX para prompts de chaves de acesso, fallback, recuperação e fluxos de login voltados para o usuário.

[← todos os benchmarks](https://www.corbado.com/pt/passkey-benchmark-2026.md)

---

*Benchmark anual para prontidão, criação, uso e estratégia de adoção de chaves de acesso pela Corbado, a plataforma de inteligência de chaves de acesso para equipes de CIAM. [Saiba mais →](https://www.corbado.com).*
