The Passkey Adoption Bottleneck

Passkeys are available. That is not the same as passkeys being used.

Over the last two years, passkeys have moved from “early” to “everywhere.” The FIDO Alliance reported that more than 15 billion online accounts can leverage passkeys, and that passkey adoption “doubled in 2024.” FIDO Alliance

Google has also shared scale numbers that are hard to ignore: passkeys were used to authenticate users more than 1 billion times across more than 400 million Google Accounts (as of April 2024). blog.google

So why do many teams still see passkeys behaving like a feature that exists, but is not reliably chosen?

Because the hard part is no longer the cryptography. The hard part is getting everyday users to understand what is happening, trust it, and repeat it.

That is a usability problem.

The adoption gap: availability vs utilization

Most companies measure passkeys with “did we ship it?” metrics:

• passkey support launched
• passkey button appears on the sign-in screen
• passkey creation succeeds in QA

But utilization is a different measurement:

• what percent of eligible users create a passkey
• what percent of sign-ins are actually completed with passkeys
• how often users fall back to passwords or OTP
• what happens when the same user switches devices

Consumer data already hints at this gap. FIDO’s 2024 barometer reports that passkey familiarity has risen, but it is still not universal (57% familiar in 2024, up from 39% in 2022). FIDO Alliance If almost half your users are not even familiar with the concept, the UX cannot assume “they get it.”

The practical takeaway: adoption is not a feature launch. It is a behavior change program.

Where users get confused (and why it matters)

Passkeys feel simple when everything is aligned: same device, Face ID works, the prompt looks familiar, and the login finishes quickly.

Confusion shows up when any of those assumptions break.

1) Users do not know what a passkey is, they only know what they just saw

A passkey prompt often looks like:

• a system dialog
• a biometric request
• a device PIN screen

To a user, that can feel like “my phone is asking for Face ID,” not “I am using a new login method called a passkey.”

If your UI says “Use passkey” but the system prompt says something else, users may hesitate. Hesitation creates drop-off, especially in high-intent flows like checkout, onboarding, or account recovery.

2) Cross-device moments feel like “it worked yesterday, why is it broken today?”

Users do not experience “platform ecosystems.” They experience “my stuff.”

A common trust-breaking moment looks like this:

• user creates a passkey on iPhone
• later tries to sign in on a Windows laptop or a shared device
• the experience is different, or the passkey is not available, or the fallback is unclear

Even when this is expected behavior, it can feel like unreliability. And unreliability is what pushes users back to passwords.

3) Fallbacks quietly teach users to ignore passkeys

If you offer passkeys as an option but your flow makes fallback effortless and default, you are training users to treat passkeys as optional friction.

A subtle example:

• “Try passkey” is on the screen
• an error happens once
• the UI immediately routes them to password or OTP without explanation
• the user learns: passkeys are flaky, passwords are safe

This pattern is common when teams optimize for immediate success rate, not long-term behavior change.

4) The “new phone” scenario is where adoption wins or dies

If you want utilization, you have to design for device change, reinstall, device loss, and device upgrade.

When these flows are unclear, users conclude one of two things:

• passkeys are risky because I might get locked out
• passkeys are annoying because I have to re-do setup constantly

Both outcomes reduce future usage.

Why inconsistency destroys trust

One reason passkeys can feel confusing is that the user experience is not entirely owned by your product team.

Passkeys are delivered through operating systems, browsers, and credential managers. That means:

• the wording and layout of prompts can vary
• the “chooser” experience can differ
• the user may see different behaviors depending on device state

Even major platforms are still iterating on passkey UX and portability. For example, Microsoft has been working on making passkeys more usable across Windows devices by adding passkey syncing in Edge on Windows 11. That change is explicitly aimed at reducing “passkeys are stuck on one device” friction. Windows Central

When the same user sees different experiences across contexts, they do not interpret it as “standards evolution.” They interpret it as “this login method is unpredictable.”

The adoption guide: how to drive utilization (not just availability)

This section is intentionally practical. If you implement only a few of these, you will typically see measurable utilization improvements.

Step 1: pick the passkey moment that matters

Do not start with “add a passkey settings page.”

Start with one of these high-leverage moments:

• post-login upgrade prompt (user is already authenticated)
• password reset completion (user is motivated to avoid repeats)
• high-risk action step-up (user will accept extra security)
• repeat sign-in journeys (daily or weekly users)

Your goal is to attach passkey creation to a moment of motivation.

Step 2: write microcopy that describes what the user will see next

Most confusion comes from the gap between your UI and the system prompt.

Good UX copy does two jobs:

• describes the next screen in plain language
• reassures the user about what is happening

Example pattern:

• “Next you will see a Face ID or fingerprint prompt from your device.”
• “This creates a passkey on this device so you can sign in faster next time.”
• “You can still sign in another way if needed.”

This reduces abandon rate because the prompt feels expected, not suspicious.

Step 3: make success visible and repeatable

After creation, show a short confirmation that connects the action to value:

• “Passkey created. Next sign-in will be one tap.”
• “Use Face ID to sign in on this device.”

Then ensure the next sign-in defaults to passkey where possible.

Google has pushed adoption by making passkeys a primary experience for accounts, rather than hiding them as an advanced setting. Their scale numbers suggest that defaulting behavior matters. blog.google

Step 4: treat fallbacks as part of the product, not an escape hatch

Fallbacks are necessary. The mistake is making fallback invisible.

When a passkey attempt fails:

• explain what happened in one sentence
• offer the next best method
• tell the user how to avoid the issue next time

This keeps trust intact.

Step 5: instrument the real funnel

If you do not measure the funnel, you will optimize the wrong thing.

Minimum funnel metrics:

• passkey prompt shown
• passkey creation started
• passkey creation completed
• first passkey sign-in
• repeat passkey sign-in within 30 days
• fallback rate after passkey attempt
• device-change recovery completion rate

If you want one north-star metric, pick: percent of eligible sign-ins completed with passkeys.

Why device binding matters for usability, not just security

Device binding is often discussed like a security detail. But it also affects adoption.

Here is the usability argument:

When a passkey is clearly tied to a specific device and protected by that device’s local unlock (Face ID, fingerprint, PIN), users build a stable mental model:

• “My phone is my key.”
• “I sign in the same way every time.”
• “A fake website cannot trick me into giving this away.”

That mental model is what creates repeat usage.

It is also why passkeys are commonly described as resistant to phishing, since they are bound to the legitimate relying party and rely on device-based authentication. The Verge

If you want passkeys to become habitual, you need them to feel deterministic and predictable. Device binding is a big part of that predictability.

A quick checklist you can use this week

• add a post-login “create a passkey” prompt for eligible users
• explain the system prompt before it appears
• confirm success and default to passkey on the next sign-in
• do not auto-fallback silently, explain and guide
• build reporting on passkey sign-in rate, not just passkey creation
• test the “new phone” and “new laptop” journeys end-to-end
• ensure your UX language matches what the OS prompt implies

Closing thought

Passkeys are scaling quickly, and awareness is rising, but usability is what determines whether they become the default behavior or remain a checkbox feature. FIDO Alliance+1

If your passkey rollout feels slower than expected, it is probably not because users hate passkeys. It is because your product is asking them to adopt a new mental model, across devices, with inconsistent prompts.

Treat passkey adoption like a guided program, design for trust at every step, and the utilization curve usually follows.

sources
https://fidoalliance.org/passkey-adoption-doubles-in-2024-more-than-15-billion-online-accounts-can-leverage-passkeys/
https://fidoalliance.org/wp-content/uploads/2024/10/Barometer-Report-2024-Oct-29.pdf
https://blog.google/technology/safety-security/google-passkeys-update-april-2024/
https://www.windowscentral.com/microsoft/windows-11/microsoft-finally-makes-passkeys-viable-thanks-to-edge-on-windows-11-you-can-finally-sync-them-across-devices
https://www.theverge.com/news/689410/facebook-passkey-support-phishing-attacks

‍