Passkeys Are Great. Shipping Them Is Harder Than the Demos.

A founder messaged us recently to ask why their passkey rollout was costing more in support tickets than the entire authentication stack it was supposed to replace. The product team had watched the FIDO Alliance keynote, read the WebAuthn spec, run the integration in a week, and shipped it behind a feature flag for ten percent of users. That ten percent was now generating half the support load.

This is not unusual. Passkeys are the best authentication technology that has hit production in a generation. They are also, when you look at the rollout reality, a harder problem than most teams plan for.

We want to share what we have learned helping clients ship passkeys without losing customers in the process.

Why passkeys are worth the effort

Before getting into what goes wrong, it is worth grounding why this matters. Passwords have failed for as long as we have used them. The industry response was to bolt on second factors. SMS one-time codes were the easy default and turned out to be susceptible to phishing, SIM swapping, and operator-side interception. Authenticator app codes were better but still phishable. Anyone who has watched a credential phishing kit harvest a TOTP in real time understands that the second factor was never actually a second factor.

Passkeys are different in a way that matters. They are a public-private key pair bound to a specific origin. The browser refuses to release a passkey to a domain that does not match the one it was registered against. A phishing page on a lookalike domain cannot trigger the prompt that authenticates the user. The attacker can lure the user, but the credential never travels.

That single property changes the threat model. Credential phishing, the most reliable initial-access vector for two decades, stops working against passkey-protected accounts.

The catch is everything around the credential. Where it lives, how it syncs, what happens when the user changes devices, who has the authority to certify the device the key is on. Those questions are where rollouts go sideways.

The synced versus device-bound split

When the FIDO Alliance and the major platform vendors agreed to call these things "passkeys" in 2022, they were really wrapping two different products under one name. The distinction is now formally codified, and it matters more than the marketing suggests.

A synced passkey lives in a cloud-backed credential manager. Apple's iCloud Keychain. Google Password Manager. 1Password. Bitwarden. When the user signs into a new device using the same account, the passkey is available. It is the consumer story. It is also the part that gets used in keynote demos because it looks like magic.

A device-bound passkey is generated and lives on a single piece of hardware. A YubiKey. A TPM. A platform authenticator that does not sync. If that device is destroyed or lost, the credential is gone.

The trade is straightforward. Synced passkeys are recoverable but rely on the security of the credential manager. Device-bound passkeys are unrecoverable but cannot be stolen by compromising a cloud account. The right answer depends on what you are protecting.

For consumer apps, synced is almost always the right default. For enterprise admin accounts, regulated workflows, and high-value credentials, the calculation flips. We have seen organizations require device-bound passkeys with hardware attestation for anyone who can touch production. Anything weaker, and an attacker who compromises a personal Apple ID gets a way in.

Account recovery is the entire game

If you remember nothing else from this post: the recovery flow is where attackers go.

Imagine the user has a passkey, the passkey is unphishable, the attacker cannot reach the credential through any normal route. What does the attacker do? They go around the credential. They call support. They submit a recovery form. They convince someone that they are locked out and need access restored.

If your recovery flow falls back to an SMS code, you have the worst of both worlds. The strongest authentication in the industry sitting behind the weakest. The attacker phishes the recovery channel and walks in.

We have audited a number of passkey rollouts where the threat model was thought through carefully right up until the recovery question, at which point the team shrugged and reused whatever was there for the password flow. That is the part that needs to change.

Patterns that hold up under attack:

The honest answer is that good recovery is expensive and inconvenient. It will be the most contested design decision in your rollout. We push hard for getting it right on day one, because retrofitting it later means migrating millions of users through whatever you decide to change.

The cross-platform sync gap is real

If your users live on a single platform, synced passkeys feel seamless. If they switch between iOS and Android, between macOS and Windows, or between a personal Mac and a managed corporate Windows laptop, the experience gets bumpy fast.

Apple's keychain does not sync to Google's password manager. Google's password manager does not sync to Apple's. Third-party managers like 1Password and Bitwarden bridge the gap, but the user has to install them, configure them, and remember to use them when registering each new passkey. The browser-level UX for choosing which credential store to save into is still messy on most platforms.

In practice, this means you should expect every active user to have at least two passkeys registered against your service. One on each major device they use. The rollout flow should make multi-device registration the default, not an afterthought. When a user signs in for the first time on a new device using a fallback method, the very next screen should offer to register a passkey on that device. Most do not do this. The ones that do see far less churn.

Enterprise: attestation, AAL, and the audit you will eventually have

Consumer passkeys are deliberately permissive about attestation. The relying party usually does not get to see the make, model, or origin of the authenticator. That is a feature for privacy and a problem for compliance.

If you are in a regulated environment, or if you intend to make claims about authentication assurance level under NIST SP 800-63 or equivalent guidance, you will eventually need attestation. That means:

In practice, most enterprises that do this end up issuing FIDO2 security keys to employees and requiring those keys for sensitive access. Synced passkeys are then accepted for low-risk applications. Treat attestation as a knob you turn for specific resources, not a property of your whole identity stack.

The users you will lose if you are not careful

Every rollout has a long tail of users who cannot use passkeys yet. The reasons vary.

If your rollout is binary, passkeys or nothing, you will lock these users out. Every passkey rollout we have seen go well kept passwords or another fallback available for at least a full release cycle, and used analytics to find the cohort still relying on the fallback. That cohort gets targeted help. The fallback retires only when it is genuinely unused.

A staged rollout that has worked for us

For a product with a few million users, this is the pattern we have recommended and seen succeed:

Stage one: optional registration. Existing users can register a passkey alongside their password. No pressure, no UI nag. Metrics: registration rate per device class, sign-in success rate for users with at least one passkey.

Stage two: opportunistic prompts. After a successful password sign-in on a device that supports passkeys, offer to register one in a non-blocking modal. Skipping is one click. Track friction.

Stage three: passkey-first sign-in. New sign-ins default to the passkey flow. Password is still available as a secondary option. Monitor the recovery flow load.

Stage four: phasing out passwords. Existing users with at least one passkey can opt to remove their password entirely. The application stops accepting password sign-in for accounts that have opted out.

Stage five (high-risk accounts only): mandatory hardware-attested passkeys. Admins, finance, anyone with destructive permissions. The fallback is a hardware key in a safe, not an email link.

The whole sequence takes most teams nine to eighteen months. Trying to compress it tends to produce the support-ticket storm we opened this post with.

What we look at when we audit a passkey deployment

A typical engagement covers a handful of things.

The registration ceremony itself: are challenges generated with sufficient entropy, validated, and not reused? Is the user verification flag enforced for sensitive operations? Are credential IDs and public keys stored in a way that resists tampering?

The sign-in ceremony: is the origin check tight? Is the relying party ID configured to the narrowest scope that works? Are credentials bound to user accounts at the server side so that one user cannot present another user's credential?

The recovery flow: every branch, every fallback, every support-agent override.

The enrollment of additional devices: how does a user with one passkey register a second? Is that flow itself authenticated, or can an attacker who has session access add their own passkey and persist?

The session model: after a passkey sign-in, how long does the session live, and what triggers reauthentication?

The logs: when something goes wrong, can we tell what happened? Can we tell from which device, against which credential ID, with what failure reason?

These details are where well-intentioned rollouts go quietly wrong. The passkey API surfaces are small but unforgiving. A subtly broken origin check or a relying party ID that is too broad turns a phishing-resistant credential into an ordinary one.

What we tell teams about timing

The honest take: 2026 is the year passkeys are ready for a wide consumer rollout, and the year enterprise rollouts can be done with off-the-shelf identity providers. It is not the year you should expect a smooth ride if you are doing it yourself and underestimating recovery.

If you have the resources to do it carefully, the upside is real. Phishing-resistant authentication for your customer base is a meaningful step up in security posture, and it is a story your sales and trust teams will use. If you do not have the resources to do it carefully, lean on an identity provider that has already absorbed the operational pain.

If you want a second set of eyes on a passkey rollout before it goes wide, or a security review of a deployment that has already shipped, we are happy to help.