Passkeys, Practically: Dropping Passwords Without Locking Users Out

Passwords are the single largest source of support tickets, breach exposure and abandoned signups in most products. Passkeys fix the underlying problem properly: the secret never leaves the user's device, there is nothing phishable to type, and the login is a fingerprint or a face rather than a memory exercise. Support is now broad enough across browsers, phones and password managers that the question is no longer whether, but how to migrate without breaking anyone.

What a passkey actually is

It is a public and private key pair bound to your site's domain. Your server stores the public key; the private key stays in the platform authenticator or password manager, unlocked by biometrics or the device PIN. At login the browser signs a challenge issued by your server. Because the key pair is bound to the origin, a lookalike phishing domain cannot use it, which removes the entire category of attack that credential stuffing and fake login pages rely on.

• Nothing shared is reusable, so a server-side breach leaks no credential usable anywhere.
• Origin binding kills phishing rather than mitigating it.
• Sync through a platform keychain or password manager means a new phone is not an account loss.
• No password reset flow means one less email pipeline to keep secure.
• Your support queue loses its largest single category overnight.

The details that decide whether it feels good

Three settings do most of the work, and getting them wrong produces a login that technically functions and irritates everyone. Set the relying party ID to your registrable domain rather than a subdomain, or credentials created on one host will not work on another. Ask for discoverable credentials so the user can log in without typing an identifier first, which is the whole point of the experience. And wire up conditional UI, the browser autofill prompt that offers the passkey on a normal login field, so people are not hunting for a separate button.

• Relying party ID set once, at the registrable domain, and never changed afterwards.
• Discoverable credentials, so login starts with a tap rather than an email address.
• Conditional UI on the existing login field, not a second competing button.
• A clear device name captured at enrolment, so the account settings page is readable a year later.
• User verification required for anything sensitive, and be honest that this is what makes the biometric prompt appear.

The migration that does not strand people

Do not flip the switch. Run passkeys alongside your existing login for at least a full billing or seasonal cycle. Offer passkey creation right after a successful password login, when the user is already authenticated and the friction is lowest, and phrase it as a faster way in rather than as a security chore. Once a meaningful share of active users have enrolled, make passkey the default option on the login screen and leave the old method behind a link. Track enrolment as a percentage of monthly active users, not of total accounts, because dormant accounts will never move and will distort the number until you give up on it.

Every authentication migration that removed the fallback before measuring enrolment ended as a support incident.

Plan the recovery path first

Recovery is where passkey rollouts fail, and it is also where the real security level of your system is set. A user with one enrolled device that ends up at the bottom of a river needs a route back in, and whatever that route is, an attacker will use it too. Design it deliberately rather than letting it emerge as an email link nobody reviewed.

• Prompt for a second passkey once the first is working, not during signup when it reads as friction.
• Keep at least one verified out-of-band contact method per account.
• Rate limit and log recovery attempts the way you would a password reset, and alert on bursts.
• For business accounts, let an administrator re-enrol a locked-out colleague; that is faster and safer than a support email.
• Never let a recovery flow silently remove existing passkeys without notifying every enrolled device.

What to store, and what not to

Per credential you need the credential ID, the public key, the user handle, the signature counter, the transports the authenticator reported and a created timestamp. Keep a last-used timestamp too, because it is what lets a user recognise which device is which. Do not store anything that identifies the physical authenticator more precisely than you need, and do not build features on the signature counter, since plenty of authenticators leave it at zero. Use a maintained WebAuthn library rather than assembling the ceremony yourself; the specification has enough edge cases that hand-rolling it is a poor use of a week.

Test on the devices your users actually have

Test on a mid-range Android phone that is three years old, in a private browsing window, and on a desktop with no biometric hardware. Those three cases are where assumptions break. On older or cheaper Android devices the passkey may live in the password manager rather than the device itself, the prompt looks different, and cross-device flows using a QR code and Bluetooth need both devices awake and nearby, which is an awkward thing to explain in a support call. Write the fallback copy for the moment cross-device sign-in fails, because it will.

When to skip it

If your product is a shared workstation tool where several people use one login, or your users are on managed devices without biometrics, passkeys will fight your usage pattern. In that case put the effort into a proper single sign-on integration instead. If you have a small internal user base and no phishing exposure, enforcing a password manager and a second factor gets you most of the benefit for a fraction of the work. Everywhere else, this is the rare security upgrade users experience as a convenience rather than a tax.

The compliance angle nobody mentions

Removing stored password hashes narrows what a breach can expose, which shortens the answer to several questions on every security questionnaire you will be sent by an overseas client. It does not exempt you from anything, and it does not replace access logging, retention limits or a deletion process. If you are selling into markets with data rules attached, the ground covered in US privacy laws for small product teams still applies unchanged; passkeys just remove one of the more embarrassing items from the list.

Roughly what it costs

For a product that already has a working session and account system, adding passkeys alongside passwords is a small piece of work: the registration and authentication endpoints, a credential table, the account settings screen, recovery, and the testing above. The genuinely hard parts are the recovery policy and the enrolment prompts, which are product decisions rather than engineering ones. We build this into new logins as a matter of course on web development and software projects, and retrofitting it into an existing product is normally measured in days rather than weeks.