Passkeys Have a 93% Login Success Rate. Only 36% of Accounts Enroll.

Two numbers, both from primary sources, both true, and they do not sit comfortably in the same sentence. Passkeys have a 93% sign-in success rate against 63% for passwords. And among the best-resourced identity teams on the planet, only 36% of eligible accounts have a passkey enrolled. In ordinary deployments that second number is usually 2 to 5%, and it stays there.

TL;DR

• The two numbers measure different funnels. 93% is a success rate among users who already enrolled. 36% is whether you ever got them to the starting line.
• Both come from the FIDO Alliance's Passkey Index, published October 2025, aggregating Amazon, Google, Microsoft, PayPal, Target, TikTok, LY Corporation, Mercari, and NTT DOCOMO.
• The single biggest cause of stalled enrollment is prompt placement: a toggle buried in account settings that almost nobody opens.
• Uber traced over 90% of enrollments to login and signup nudges. TikTok traced 99% of passkey creations to one well-placed upsell prompt.
• As long as a weak fallback stays live for everyone, your effective security is the fallback, not the passkey.
• Default-everywhere passkeys are a 2027 story, and the blockers are recovery and portability, not cryptography.

Microsoft's own numbers are starker than the aggregate: 98% success for passkeys against 32% for passwords, roughly eight times faster than password-plus-MFA. More than 15 billion accounts are now passkey-eligible. By every performance measure that exists, passkeys are the best consumer authentication method ever shipped.

So which number is lying? Neither. The space between them is the most important thing nobody explains when they sell you passkeys.

What each number actually measures

The resolution is almost embarrassingly simple once stated.

	The 93%	The 36%, or your 4%
What it is	Success rate	Enrollment rate
Population	Users who already hold a passkey	All of your users
What it proves	The credential works	Whether your product can onboard anyone to it
Who owns it	The standard, and it is solved	Your enrollment flow, and it is usually not
Who quotes it	Every vendor deck	Your dashboard, quietly

These are two different funnels, and passkey marketing quietly conflates them. The technology's performance is genuinely excellent and not in dispute. The product's ability to enroll users is where nearly every deployment fails. You are not choosing between a good technology and a bad one. You have a great technology strapped to a broken onboarding flow, and the onboarding flow is the part your vendor's default configuration ships badly.

The single most-cited reason enrollment stalls, across practitioner writeups and the FIDO data alike: the only place a user can create a passkey is a toggle buried in account settings that almost nobody ever opens. That is the whole story in one sentence. The credential is proven. The door to it is hidden.

The mechanics of the failure

"Bad enrollment UX" is too vague to fix. Here is what specifically breaks, in the order it bites.

Failure	What happens	The fix that exists today
The blind prompt	Fires at the wrong moment on the wrong device, training users to dismiss	Conditional UI and checking for existing credentials
The fallback hole	Attacker suppresses the passkey option and attacks the password	Passkey-only per user, once they hold two credentials
Cross-device scam feel	QR code flow is indistinguishable from a scam to a careful user	Explain the flow inline, and avoid it when a local option exists
The ghost credential	Deleted server-side, still in autofill, fails forever	WebAuthn Signal API

The blind prompt. A naive implementation prompts every user to create a passkey without knowing whether this device can make a good one, or whether the user already has one synced. So it fires at the wrong moment, on the wrong device, to a user with no context, and trains them to dismiss it. Every dismissed prompt makes the next one easier to ignore. The fix exists in the spec. The default vendor flow often does not use it.

The fallback that eats the whole benefit. This is the deep one, and it is a security problem disguised as a UX problem. If 36% are enrolled, the other 64% still sign in with a password or an SMS code, which means your login page still offers "sign in another way." A phishing kit does not need to defeat the passkey. It suppresses the passkey option and presents the password field, and your users are back to adversary-in-the-middle-defeatable auth. As long as the weak fallback stays live for everyone, your effective security is the fallback. The 93% success rate is cold comfort when the attacker chooses which path to push your user down.

The cross-device scam problem. The worst real-world passkey moment: a user on a laptop with no local passkey gets shown a QR code and told to scan it with their phone. To a security-aware normal person, that is indistinguishable from every QR-code scam they have been warned about. The flow (CTAP hybrid transport, BLE plus a tunnel service) is cryptographically sound and genuinely phishing-resistant. It also feels exactly like fraud, and a meaningful share of users abandon rather than complete it. We spent a decade training people not to scan unexpected QR codes, and then built a login flow that requires them to.

The ghost credential. When a passkey is deleted server-side but the user's credential manager is never told, a dead entry lingers in autofill forever. They tap it, it fails, and they conclude passkeys do not work here. The WebAuthn Signal API exists specifically to clear these. Most deployments have not wired it up, so ghosts accumulate and quietly poison trust in the feature.

Notice the pattern. Every one of these is a product and orchestration failure, not a cryptography failure. The standard is fine. The vendor default wrapping it is what costs you the other 90% of your users.

What actually moves the number

Deployments that break out of the single-digit trap do a specific, repeatable set of things. The evidence is unusually clean because a few companies published their attribution.

Prompt at the moment of high trust, not at signup. Uber traced more than 90% of its passkey enrollments to prompts placed at login and signup rather than settings. TikTok traced 99% of its passkey creations to a single well-placed upsell prompt. The lesson is blunt: the enrollment surface is the entire ballgame, and "we added passkeys to account settings" is functionally the same as not shipping them. The highest-converting single moment is immediately after a successful sign-in, when the user has just proven who they are and is in a trusting state.

Upgrade silently after a password login. The WebAuthn spec supports conditional create(), which registers a passkey in the background right after a successful password sign-in. No modal, no interruption, no decision fatigue. It is the single most effective enrollment lever available, and the one most often left switched off in default configurations.

Gate the prompt by device and cooldown. Do not ask on every device, every time, forever. Ask once per device, fingerprint it, and set a cooldown before asking again on a device that declined. Thirty days is a sane default. Asking correctly is an orchestration problem, and it is exactly the layer separating a 4% deployment from a 20% one. I laid out this pattern in the CIAM Compass passwordless guide: post-login prompt, device fingerprint, 30-day cooldown. It converts because it respects the user instead of nagging them.

Only then, go passwordless for that user. Once an account holds at least two passkeys across two different credential managers, you can flip that specific user to passkey-only and hide the password field, which finally closes the fallback hole. Not before. The two-credentials-across-two-managers rule is what makes passkey-only survivable without creating a recovery disaster the first time someone loses a device. Skip it and you trade a login problem for a lockout problem, which is worse.

The through-line: adoption is a funnel you drive, not a feature you announce. Vendors that treat it as a checkbox ship the 5%. Teams that treat enrollment as a product surface to be measured and optimised ship the 20%. Your vendor's marketing sells you the 93%. Your enrollment orchestration determines whether you ever get to use it. For the full method stack and where passkeys sit against magic links and OTP, my complete guide to passwordless authentication covers the architecture, and the enterprise passkey deployment playbook covers the rollout sequence.

The prediction, with a date

Aggregate passkey enrollment becomes a mainstream reality above 30% when platforms stop making passkeys a choice and start making them the default. Not an option in settings. Not a dismissible prompt. The default account state, with password as the fallback you opt into rather than the reverse.

That is a 2027 story, not a 2026 one, and the reason is recovery, not technology. You cannot make passkeys the default until recovery is solved at population scale, because an account's real security ceiling is the weakest path back into it. Deploy passkeys while "email me a reset link" stays live and you have capped your security at the strength of the user's email account. The industry knows this, which is why the serious 2026 work is in recovery design, multiple enrolled factors, cooldowns on reset, document verification for high-value accounts, rather than in the passkey ceremony, which was solved years ago.

The other gating factor is portability. Passkeys currently cannot be exported between providers at all, because the FIDO Credential Exchange Protocol is still a draft explicitly marked as not yet intended for implementation. Until that is final and shipped, going all-in means accepting a lock-in worse than the password-hash export problem: there is no export format at all. Platforms will not push default-passkey hard until users can move credentials, and that plumbing lands in 2027.

So the honest read for 2026: passkeys are ready, the enrollment problem is solvable today with orchestration you can build or buy, and teams that treat enrollment as a real product surface will pull double-digit adoption while their competitors sit at 4% and blame the technology. The default-everywhere tipping point comes a year later, when recovery and portability catch up. The companies that spend 2026 getting the enrollment funnel right are the ones positioned to flip the default the moment platforms make it safe.

The 93% was never the hard part. Getting users to the starting line is, and that is a problem your vendor's default configuration will not solve for you.

What is your passkey enrollment rate right now, and do you know where in the funnel you are losing people?

Frequently Asked Questions

Why is passkey adoption so low if the success rate is so high?

The two numbers measure different things. The 93% success rate applies only to users who already have a passkey enrolled. The enrollment number, 36% even among the FIDO Alliance member companies and 2 to 5% in typical deployments, measures whether users ever enroll at all. The technology performs excellently. The enrollment flow is where deployments fail.

What is the single biggest reason passkey enrollment stalls?

Prompt placement. The most common failure is offering passkey creation only as a toggle buried in account settings that almost no user opens. Companies that moved the prompt to a high-trust moment, immediately after a successful login, saw dramatically higher enrollment. Uber attributed over 90% of enrollments to login and signup prompts. TikTok attributed 99% of passkey creations to a single upsell prompt.

Does deploying passkeys improve security if adoption is low?

Only partially, and this is the trap. As long as a weak fallback such as a password or SMS code stays available to all users, a phishing kit can suppress the passkey option and attack the fallback instead. Your effective security is the weakest available method, not the passkey. You close this hole by moving individual users to passkey-only once they hold at least two passkeys across two different credential managers.

What is conditional create and why does it matter?

Conditional create() is a WebAuthn capability that registers a passkey in the background after a user successfully signs in with another method, with no interrupting modal. It is widely considered the single most effective enrollment lever available, and it is frequently left disabled in default vendor configurations.

When will passkeys become the default instead of an option?

Likely 2027 rather than 2026, and the blockers are not technical. Account recovery has to be solved first, because an account is only as secure as its weakest recovery path. Portability is the second blocker: the FIDO Credential Exchange Protocol that would let users move passkeys between providers remains a draft not intended for implementation. Both are expected to mature around 2027.

What enrollment rate should I expect from a good passkey rollout?

Deployments that only offer passkeys in account settings tend to sit at 2 to 5% indefinitely. Deployments that prompt at high-trust moments and use silent conditional create commonly cross 20% within a few months. Flat single-digit enrollment across two quarters is a signal that the enrollment flow, not the user base, is the problem.

Why do users abandon the cross-device QR code flow?

Because it looks exactly like a scam. Being asked to scan an unexpected QR code with your phone to authorise access is the shape of an attack users have been trained to refuse. The flow itself, CTAP hybrid transport over BLE plus a tunnel service, is cryptographically sound and phishing-resistant. The problem is that a decade of security awareness training taught people to distrust precisely this interaction.

---

I founded and scaled a CIAM platform past a billion users, which mostly taught me that authentication problems are rarely authentication problems.