Passkey Authentication Success Rate
Passkey authentication success rate shows how reliably existing passkeys convert into completed sign-ins. It focuses on the usage layer after a credential exists, where entry design, fallback behavior and cross-device coverage decide whether passkeys become the default login path.
Success rate splits by device context: unknown vs. known
Success is measured from the moment the passkey ceremony actually starts, i.e. the relying party has sent the WebAuthn challenge to the client and the user is looking at the system passkey prompt (Face ID / Touch ID / Windows Hello / a CDA QR code). It splits cleanly into two regimes by how well the relying party can classify the device context. The gap between them is the entire story.
- Identifier-first
- The user typed an email or username and the system did not yet recognize the device.
- % CDA
- The share of these passkey successes where the user had to scan their phone (cross-device authentication) instead of using a local passkey.
Cookies, account memory or session state did not classify the device. The login starts from the text field. Conditional UI may surface a passkey suggestion or the relying party has to guess whether a passkey is reachable at all. Once a passkey path is offered, completion depends heavily on whether it is local or has to bridge to another device.
After a successful unknown-device login (especially one that completed through CDA), create or remember a local passkey on this device. Skipping this step is the single largest reason desktop users keep paying the discovery tax on every visit.
Once the device is classified as known, the relying party routes directly into the local passkey path. % CDA drops to 1–5%. Completion approaches the technical ceiling and the login feels invisible. The KPI ends here.
The gap between unknown and known is not just a ceremony problem. It is the value of converting one successful unknown-device login into a remembered-device fast lane. Every CDA success that does not leave a local passkey behind is a cost the user pays again on the next visit.
Success by login path
The success rate below excludes fallback and starts once a passkey path is offered. Mobile and desktop diverge sharply: mobile users are typically logging in on the device that holds the passkey, while desktop users often need to bridge to a phone.
| Login path | Passkey success | % CDA |
|---|---|---|
| Unknown device: identifier-first mobile | 85–95% | 0–5% |
| Unknown device: identifier-first desktop | 55–70% | 35–50% |
| Known device: automatic return login | 95–99% | 1–5% |
Passkey-button-only entries on unknown devices are excluded from the headline mix: per-attempt completion is high, but volume is too low to publish as a primary number.
Success by platform
The same identifier-first regime, cut by operating system. A higher % CDA means the user had to reach for a separate phone to finish the login.
| Segment | Identifier-first success | % 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% |
The phone is the device. Identifier-first completion is highest here (85–95% on iOS, 70–85% on Android) because the platform passkey lives where the user is logging in. Almost no bridge to pay.
The phone is separate. More than half of every Windows identifier-first passkey success is a bridge to a phone (55–65% on Windows 11, 40–55% on Windows 10). Every Windows session without a remembered local passkey pays that cost again.
Between the two. Most macOS identifier-first successes are local (70–85% complete), but a meaningful slice still bridges to a phone (10–15%), typically when iCloud Keychain is not yet active on the Mac or the user works across ecosystems.
Further Reading
Curated Corbado research and primary references.
- Passkey Login Best Practices Design and implementation patterns for making existing passkeys complete sign-in reliably.
- Passkey Authentication Success Rate Definition for measuring passkey attempts that reach an authenticated session.
- Passkey Design Guidelines UX recommendations for passkey prompts, fallback, recovery and user-facing sign-in flows.