Passkeys don't stop account takeover

A passkey can’t be phished by a fake login screen. It’s bound to the origin it was registered for, so the browser won’t release it to a lookalike domain, and it’s asymmetric, so a server breach leaks a public key an attacker can’t replay. That closes the standard login flow. It leaves the recovery flow untouched, and an account’s security is still set by its weakest recovery method: SMS, email links, security questions.

An attacker who can’t produce the passkey triggers a reset instead. They intercept the SMS, click the email link, or answer the security question, and they land inside the account the passkey was supposed to protect. The login page becomes the hardest surface and the recovery page the softest, which is where takeover moves. The reason passkeys breed a false sense of security is that the part they fix is the part the user sees every day.

If you operate an account system, passkey enrollment is the cheap win and the recovery path is the work. Give it the same threat model: rate limits, step-up verification, and no SMS fallback that silently downgrades a passkey-protected account to a one-time code anyone can phish. A passkey sitting in front of a security-question reset is decoration.

The failure moves to the platform account

For an individual the risk runs the other way. Phishing resistance matters less than the things that actually lock people out: a permanent account lockout, an automated ban, a lost device. Here the design of passkeys works against the user.

Hardware keys don’t back up. A passkey on a key can be added or deleted, never copied or moved, so the only redundancy is buying two or three keys and enrolling every one of them on every site. That cost grows with every account. Discoverable credentials, where the site looks up your username instead of you typing it, carry a hard ceiling of roughly 25 to 100 resident credentials per key, up to about 300 on top-end models. Past that you delete accounts or buy more keys.

Synced passkeys trade that for a single point of failure at the platform. Apple and Google both want identity anchored to the OS, and the happy path stores your passkeys against your Apple or Google account. If their automated systems ban that account, every synced passkey across every third-party site goes with it. The FIDO alliance is working on export and interoperability, but today it’s fragmented enough that moving keys between providers isn’t something to rely on. A password is a string you can write down and carry out by hand.

Third-party managers like Bitwarden and KeePassXC can hold passkeys now, and OS hooks like Android’s Credential Manager exist, but autofill outside the browser and inside native apps is still inconsistent. The polish that password autofill earned over a decade isn’t there yet.

The stack the argument lands on for individuals is a familiar one: randomly generated passwords in a third-party password manager, paired with an independent TOTP app. TOTP has known phishing weaknesses against an adversary-in-the-middle proxy, but for most people the daily risk of lockout and bans outweighs the AiTM risk, and the combination keeps credentials exportable and under the user’s control. For anyone who was reusing a single password everywhere, passkeys are still a clear upgrade.