Passkeys fix phishing and nobody wants to talk about account recovery

Let me start by conceding the argument, because I lost it.

Passkeys are phishing resistant in a way nothing before them was. The credential is bound to the origin by the browser, not by the user’s judgment, so a convincing lookalike domain gets nothing — there is no secret to type into the wrong box. No shared secret sits in a database to be dumped. TOTP codes, which people still call two-factor, are phishable in real time by any proxy that relays them, and passkeys aren’t.

Every one of those is a genuine improvement over the password-plus-SMS status quo, and I spent longer than I should have complaining about the user experience instead of acknowledging it.

What I got wrong

My objection was that passkeys re-tether identity to devices, and devices break, get stolen, and get replaced. Ties your accounts to a phone, I said. Lose the phone, lose your life.

Credential syncing largely answered that. Passkeys sync through the platform keychain or a password manager, they’re in more than one place, and losing a device is no longer losing the credential. That was the actual objection and it got addressed.

It also introduced the thing the FIDO purists warned about — the credential now lives in a cloud account, protected by that account’s own recovery flow, which is a password and probably an SMS code. The hardware-bound guarantee is gone for synced credentials, and what you have is a very good password manager with excellent anti-phishing properties. That’s a real trade and it’s the right one for most people. It’s just not the thing the marketing describes.

The part that’s still unsolved

Here’s the question nobody in this space answers directly: what happens when a user has lost every device and every sync account?

Because whatever that answer is, it’s your real authentication mechanism. Attackers don’t attack the strong path. They attack recovery.

Go look at the recovery flows on the services you use. What you’ll find, over and over:

• Email a link to the address on file. Now your account security is your email account’s security, and if that email is also passkey-protected, it has its own recovery flow, which is usually a phone number.
• SMS a code. SIM swapping is a solved problem for anyone motivated, and the industry has known this since at least 2016.
• Answer security questions. Publicly available facts, in a database, in plaintext, forever.
• Contact support, prove identity somehow. Social engineering, aimed at a person whose job metrics reward resolving tickets quickly.

So: cryptographically unphishable credential, guarded by a support agent under handle-time pressure. The chain is exactly as strong as its weakest link, and the weakest link did not move.

Why it stays unsolved

Not because it’s technically hard. Because the good answers all have terrible conversion metrics.

Recovery codes printed at enrollment and stored offline work. Users lose them, and worse, they abandon signup when asked to deal with them. A hardware backup key in a drawer works — that’s the actual FIDO answer, two keys, one enrolled and one in a safe — and it requires buying a second key and remembering where it is. Delegated recovery through a trusted contact works and confuses people.

Every robust answer costs signups. Every cheap answer is a phone number. Product organisations have a very consistent record on that tradeoff, and it’s not the record where security wins.

That’s the whole problem. It’s not cryptographic and it never was.

Deploy them anyway

None of this is an argument against passkeys, and I want to be clear about that because the last time I wrote about this someone quoted me as one.

Phishing is the dominant credential attack by volume, by an enormous margin. Passkeys structurally eliminate it. Ship them. Push users toward them. Kill SMS as a second factor while you’re there.

Just don’t tell yourself you’ve fixed authentication, because you’ve fixed the front door of a building whose back door is a support ticket. Do this alongside:

Audit the recovery path as an attack surface. Write it down as a graph. Follow every edge until it terminates in something that isn’t another account. Whatever it terminates in — that’s your security model, and I’d bet on it being a phone number or a human.

Enroll two credentials, always. Prompt for a second passkey on a different device at enrollment. This is the single highest-value thing you can do and almost nobody does it, because it’s a second step in a signup flow.

Treat support-based recovery as privileged access. Because it is. Rate limits, secondary approval for high-value accounts, and logging that someone reads. Your support tool is an authentication bypass with a ticketing system attached.

The cryptography has been fine for years. It was never the part that was going to fail.