iskander@ivane:~$
← cd ../posts

The recovery path is the login

2026-09-22securitywebopinion

My passkeys live in a third-party password manager, not in the OS keychain. That's deliberate and it's off the happy path: Apple and Google would both much rather I anchored my identity in their account, and every prompt they show me is designed to make that the easy choice. I picked the awkward one because I wanted to be able to move.

I have never implemented WebAuthn on a server. I'm a user of this thing, not an operator of it, and that turns out to be the axis the whole argument runs on.

Ethan Hawksley published I don't like passkeys on 18 September. It reached the Hacker News front page and, as of this morning, has 828 points and 802 comments — one of the longest threads of the week. His conclusion is that the ecosystem isn't mature enough for individuals and that a password manager plus TOTP is the better bet for now. I'm not sure I agree with the conclusion. I think one sentence in the middle of his post is the actual story, and it isn't the one people picked up:

An account's security is still dictated by the weakest recovery method.

That is not a caveat attached to the passkey argument. That is the argument, and it was true before passkeys existed.

What the week actually showed

The German-language coverage is a good illustration. heise is running a practice series on passkeys; part two, on registration and authentication, walks through the ceremony in detail — challenge, attestation, the whole handshake. Careful, useful writing about the part of the system that works.

Meanwhile the most-watched passkey explainer of the week was Ask Leo!'s "How Passkeys Work (A No-Tech Version)," 105,240 views in five days, and one of its twelve chapters is titled What happens when you lose your device.

So the technical writing is about the ceremony and the civilian question is about the failure case, and those are two different subjects wearing the same name. That gap isn't anyone's fault. It's what happens when the interesting engineering and the consequential engineering are in different places.

Somebody did write this down

Here is the part I can check rather than assert. NIST SP 800-63B, revision 4, final since July 2025, has a normative section on account recovery, and it is unusually specific about what recovery is allowed to be.

To recover an account that authenticates at AAL2 — the level a consumer account with a passkey would sit at — the guidelines say a provider SHALL require one of: two recovery codes obtained by different methods, or one recovery code plus authentication with a single-factor authenticator already bound to the account, or repeated identity proofing. Issued codes get hard expiry windows: ten minutes over text or voice, twenty-four hours over email. Providers SHALL allow at least two recovery addresses, and each one SHALL be verified before it counts.

Read that list and then think about what recovering a consumer account actually looks like. One link, to one address, that you set up years ago and have never re-verified.

There's a second distinction in there I keep coming back to. NIST notes that replacing a forgotten password while you can still authenticate some other way isn't account recovery at all — that's binding a new authenticator. Recovery is specifically the case where everything is gone. It has no happy path, no demo, and no onboarding flow.

I want to be careful about the claim. NIST 800-63 binds US federal agencies. It does not bind Google, and pointing at it is not a compliance argument. What it is: the one place I could find where someone wrote out the shape of the problem, which makes it easy to see what the passkey pitch leaves out.

Why this is worse for passkeys than for passwords

The obvious objection is that none of this is new. The weakest-recovery-path problem applied to passwords exactly as much, and nobody wrote a post about it. Fair. Two things changed.

The first is that a password is a string and a passkey is not. You could write a password on paper, mail it to yourself, keep three copies in three places. Those are bad practices and they were also, quietly, redundancy. A passkey on a hardware key can be added or deleted but never moved, and the storage is finite: Yubico's documentation puts the YubiKey 5 Series at 25 discoverable credentials on firmware 5.0–5.6 and 100 on 5.7 and later. Redundancy that used to happen by accident now has to be built on purpose, one enrollment at a time, per key, and the registration flow doesn't mention it. (A higher figure, 300 slots on top-end keys, is circulating this week alongside that same link. I couldn't find it in Yubico's documentation, so I'm not using it.)

The second is visibility. Everyone has clicked "forgot password." You exercised the recovery path routinely, badly, and knew roughly how it behaved. Passkeys are sold specifically as the thing you never have to think about, which means for most people the first time they exercise recovery will be the day they can't get in — on a new phone, in a hurry, with the old device already wiped.

The FIDO Alliance is fixing the adjacent problem. The Credential Exchange specs move passkeys between providers as encrypted credentials rather than via a CSV file, and the work is genuinely multilateral: the working draft was announced in October 2024 with Apple, Google, Microsoft, 1Password, Bitwarden and Dashlane among the contributors, and FIDO's specification page currently lists the Format at Proposed Standard and the Protocol still at Working Draft. So it's coming, and the lock-in complaint has a visible expiry date. It also does nothing for the case I'm describing, because export moves keys from one place you control to another place you control. It doesn't help when you control neither.

A number I'm leaving out

The figure in almost every passkey article right now is five billion passkeys in use. It traces cleanly, to the FIDO Alliance's own World Passkey Day announcement in May, alongside adoption percentages from a survey of 11,000 people that FIDO commissioned. So it isn't made up. But FIDO is the trade body whose members ship the prompts, "in use" is its own estimate rather than a count, and the percentages are self-reported. I'd want that number from someone with nothing riding on it before building a paragraph on it, so I haven't.

What I actually do, and what it doesn't fix

Passkeys where they work, in my own password manager rather than the system keychain. The cost is real: autofill outside the browser is noticeably worse, native apps on Android are inconsistent even with Credential Manager, and I fall back to copy-paste in a way I never did with passwords.

I made that trade for portability, and it does not solve recovery. All I did was choose my own single point of failure instead of the one Apple picked for me — a failure mode I understand better and can take responsibility for, not one I removed. Honestly described, my setup is one manager, two hardware keys, and a set of recovery codes I generated once and have never tested. I'd bet most people reading this have the same third item.

Where I might be wrong

The strongest counter is one Hawksley concedes and I should too: for someone reusing one password across forty sites — which is most people — a passkey is a straight upgrade even with a terrible recovery path. My argument only applies to people who already run a password manager, and that's a minority.

I'm also borrowing authority from NIST that it doesn't have in this context. A consumer provider isn't out of compliance for running a single email link, because it was never in scope. Using a federal identity standard as a yardstick for Gmail is a rhetorical move, and I'd flag it if I saw someone else make it.

And I have not systematically audited consumer recovery flows. I have my own accounts, a lot of forum reading, and the NIST text. What would actually settle this is someone comparing the recovery paths of the fifty largest consumer sites against those AAL2 requirements, and as far as I can find, nobody has. Until then I'm generalizing from a small sample, which is exactly the kind of evidence I'd push back on in someone else's post.

Finally, the alternative I'd otherwise reach for isn't clean either. TOTP is phishable by an attacker-in-the-middle proxy, and that isn't hypothetical — it's a tooled, commodity attack. If the real choice is between a phishable second factor with a forgiving design and an unphishable one with a fragile design, reasonable people land in different places.

The narrow claim

Not "don't use passkeys." I use them.

The claim is that whatever you pick, the thing deciding whether you still have your account in three years is the recovery path, and it's the one part of the login page nobody designs, demos, or tests. The passkey is the part that works. It's also the part that gets all the attention, from vendors and from us, because it's the part with interesting cryptography in it.

If you do exactly one thing this month, it shouldn't be enrolling another passkey. It should be finding out what happens to your three most important accounts if your phone goes in a river — and then doing the boring half: two recovery addresses, both verified, and codes stored somewhere that isn't the device you're recovering from.

Sources