Design Passkey Sign-In With a Real Fallback

Security & Access · authentication, security, mobile

Updated 2026-08-04

Explain what a passkey is in terms of what changes for the user, not in terms of WebAuthn. The private key stays on their device and nothing reusable is ever sent, which is why it cannot be phished or leaked in a breach.
Never present it as a password stored somewhere. Users who think of it as a saved password will look for it, try to copy it, and worry about where it lives.
Say which device the passkey is on. Someone signing in on a laptop with a passkey on their phone needs to know that before they hit the prompt.
Design the enrollment moment rather than interrupting sign-in with it. The best time to offer one is just after a successful sign-in, when the user is already authenticated and unhurried.
Keep a second way in, always. Losing the device that holds the only passkey must not lose the account.
Design the recovery path with the same care as the primary one:

A second passkey on another device.
A verified email or phone route.
Recovery codes generated and confirmed at setup.

Handle the browser prompt failing quietly, because it does. A cancelled or unsupported prompt has to fall back visibly rather than leaving the button apparently dead.
Name the devices in account settings and let them be removed. A list of unlabeled credentials is one nobody will ever prune.
Do not remove the old sign-in method the day you add the new one. Passkey support varies by device and browser, and a user on an unsupported combination must still get in.

A passkey removes the weakest part of sign-in, and it also removes the familiar recovery story, so the recovery design is the part that decides whether it works.