Passkeys, and when to bother

Written 24 June 2026. This one touches fast-moving tooling. The tradeoffs should hold; check anything version-specific against current documentation before relying on it.

Passkeys replace the password with a key pair held by the device. The private half never leaves it, so there is nothing to phish, nothing to reuse across sites, and nothing useful for an attacker to steal from your database.

That is a real improvement over passwords, which are the cause of most account compromises. It still does not make them automatically right for your product.

What actually improves

• Phishing largely stops working, because the credential is bound to your domain and simply will not offer itself to a lookalike.
• A database breach no longer leaks anything an attacker can log in with.
• Sign-in is a fingerprint or a face rather than a password plus an SMS code — faster, and people stop reusing passwords they were reusing anyway.

The problem nobody puts on the slide

Account recovery. A password can be reset by email. A passkey lives on a device, and devices get lost, broken, sold and replaced.

The major platforms sync passkeys through their own accounts, which covers most people most of the time. It does not cover the user who moves between ecosystems, the one who lost the only phone they own, or the shared machine at a shop counter.

So you build a recovery path — and a recovery path is, by definition, another way in. Build it carelessly and you have reintroduced the weakness you removed. This is the actual work in a passkey project, and it is where the time goes.

Any authentication system is exactly as strong as its account-recovery flow. Passkeys do not change that.

What I would do today

1. Offer passkeys as an additional way to sign in, not the only one.
2. Keep one conventional fallback — email link or password — until your own numbers show most users have enrolled.
3. Encourage enrolling more than one device.
4. Design the recovery flow deliberately, and make it as hard to abuse as the front door.
5. Watch how many people actually use it. That number decides whether step two ever ends.

Is it worth it for a small product?

If you hold anything users would be upset to lose — money, business data, personal records — yes, as an option. If you are building a booking page for a salon, an email link is simpler and perfectly adequate. Match the effort to what is behind the door.

What it costs to build

Adding passkeys as an option to an existing login is not a large project — the browser APIs do the cryptography and libraries exist for every common backend. Reckon on a week or so for the happy path.

The estimate goes wrong when the recovery flow, the multi-device story and the admin tooling are treated as details. Realistically, budget two to three times the happy path for everything around it: enrolling a second device, replacing a lost one, letting support see which credentials an account has, and revoking one.

That ratio is not unusual for authentication work. It is just unusually often left out of the estimate, because the demo is the happy path and the demo is what gets costed.

The things worth doing before this

If account security is the goal and the budget is finite, passkeys are not the first thing I would spend it on. In rough order of value per rupee:

1. Rate-limit the login endpoint. Credential-stuffing is the most common attack on small products and it is largely stopped by sensible limits and lockouts.
2. Store passwords correctly. A modern hashing algorithm with a proper work factor. If this is wrong, nothing else matters.
3. Offer two-factor at all. Even SMS, imperfect as it is, beats a single factor for most accounts.
4. Check new passwords against known-breached lists. Cheap to add, and it stops the reuse that causes most compromises.
5. Then passkeys, as an additional option.

What it looks like to a user who has never seen one

Worth being blunt about: many people will not know what a passkey is, and a sign-in screen offering an unfamiliar thing loses users. The wording matters more than the cryptography.

What works is describing the outcome rather than the mechanism — “use your fingerprint or face to sign in next time” rather than “register a passkey”. Offer it after a successful login, not instead of one, so nobody is blocked by a concept they did not ask about.

Every authentication improvement is also a chance to lock out the people you were protecting. That is the tradeoff to design around.

Where they are genuinely worth the trouble

If your users are businesses, if the account holds money or client data, or if you have already seen credential-stuffing attempts in your logs, passkeys move the needle and are worth the recovery work.

If you are building a booking page where the worst outcome of a compromised account is a cancelled haircut, an email link is simpler, cheaper and honestly proportionate. Security effort should match what is behind the door, not what is fashionable to have implemented.