Passkeys Are Finally Boring, Which Means You Should Ship Them

Passkeys spent several years in the awkward phase where the technology worked but the ecosystem did not. Device support was patchy, syncing was inconsistent, and every implementation had to ship an apologetic fallback. That phase has ended. Support is broad, syncing works across platform accounts, and users increasingly encounter passkeys often enough to recognise the prompt.

What you actually gain

The security argument is well worn but worth restating precisely. Passkeys eliminate credential reuse, because there is no shared secret to reuse. They eliminate phishing of the credential itself, because the key is bound to the origin. And they remove the most expensive class of breach exposure, since your database no longer holds anything an attacker wants.

The product argument is stronger and gets less attention. Sign-in becomes a biometric prompt instead of a password field, a password manager negotiation, and possibly a code from an email. Conversion on sign-in improves, and support volume for password resets falls sharply.

The hard part is recovery

Every passwordless project underestimates account recovery, and every one of them is eventually defined by it. If a user loses access to their platform account, what happens? The honest answers are limited: a second registered passkey on another device, a recovery code they stored somewhere, or an identity verification process that costs you money and costs them patience.

Design this first. A recovery flow bolted on afterwards will either be insecure, because it becomes the weakest link an attacker targets, or unusable, because it is so strict that legitimate users are locked out permanently.

A migration that does not annoy anyone

1. Support passkeys as an additional method, not a replacement. Existing sessions are untouched.
2. Prompt for enrolment after a successful password login, when the user has already proven who they are and is not in a hurry.
3. Encourage a second passkey on a different device, framed as a backup rather than a security chore.
4. Once a user has two, offer to remove the password entirely, and make that a deliberate choice.

Implementation notes worth knowing

• Bind to your registrable domain carefully; subdomain mistakes are the most common source of "it works locally" bugs.
• Store metadata about each credential, including device label and last used time, so users can manage them meaningfully.
• Handle the case of a user with a passkey on a device they no longer have, which is the same problem as recovery and should reuse that flow.
• Keep an authenticated session refresh path that does not require re-authentication for routine actions, or users will feel the prompt too often.

The measure of a good authentication system is how rarely a legitimate user thinks about it and how expensive it is for everyone else.

The technology is ready. What is left is product work, and product work is the part your team is actually good at.