Passkeys don't stop account takeover

A passkey is a cryptographic key pair. The private half signs a challenge, the public half sits on the server, and no shared secret crosses the wire. That design defeats phishing and credential stuffing. It does not defeat account takeover, and the vendors pushing passkeys keep letting those two ideas blur into one.

My objection is not to the cryptography. WebAuthn and FIDO2 are sound. My objection is to the claim stacked on top of them: that a passkey ends the authentication problem. It does not end it. It relocates it. The credential stops being the weak point and something else becomes the weak point, and most of the messaging never names what that something is.

I have run the attacks passkeys are supposed to stop. Credential theft, password reuse, phishing pages that harvest and replay. Passkeys close those routes cleanly. An attacker who used to phish a password now has nothing to phish. That part is real. But an attacker does not go at the strongest control. He goes at the one you forgot to count. Passkeys change which control that is. They do not remove it.

Start with where the private key actually lives. A device-bound passkey stays on one piece of hardware. A synced passkey, which is the default most people receive, is copied into a platform vault: iCloud Keychain on Apple, Google Password Manager on Android and Chrome. The key material is now available to any device that can authenticate to that platform account. The security of the passkey becomes the security of the platform account. That is observable in the design. It is not an inference.

So the question stops being how strong is your passkey and becomes how strong is your Apple or Google account. Whoever controls that account controls every passkey synced into it. The boundary you were told to trust, a private key that never leaves your device, quietly became a private key that leaves your device by design. For most users that platform account is guarded by a password and a second factor, which is the exact model passkeys were sold to replace.

Then there is recovery. Adding a passkey to an account almost never removes the account’s other ways in. The email reset link still works. The SMS code still works. Security questions, a recovery email, a support agent who can be talked into a reset, in many services the original password, all still work. The passkey becomes the strongest way to authenticate and at the same time the least relevant, because an attacker will not touch it. He goes at the recovery path. You installed a vault door and left the service entrance open.

The mechanism here is a shift in the trust boundary, and it is worth stating precisely because the pitch avoids it. With a password, the secret and the risk sat with you. You could be phished, but the failure domain was one credential you held. With a synced passkey, the secret sits inside a platform ecosystem and the risk moves with it. You are now trusting the sync fabric, the vendor’s account security, and the vendor’s own recovery process. Trust got delegated. It did not get validated on an ongoing basis. It was assumed at enrollment and then carried by the platform session.

What changed is the location of the single point of failure. Before, compromise meant compromise of one credential. Now, compromise of one platform account can mean compromise of every service that account holds passkeys for. Concentration is not automatically weakness. Concentration without a matching increase in enforcement is. The platform account is often still protected by the same password and one-time-code scheme passkeys were meant to retire, so the attack surface shrank in one place and got denser in another.

The recovery path exposes the same mechanism from a different angle. A control that can be bypassed is not the control that governs the account. If a service accepts a passkey but also accepts an SMS reset, the SMS reset is the real authentication boundary, because it is the weakest accepted path and the attacker picks the path. The passkey does not enforce anything the recovery flow is permitted to override. Enforcement that any fallback can undo is not enforcement. It is a preference.

The mechanism is not the passkey. It is the set of paths a service accepts as proof of identity. A service that accepts a passkey and also accepts an email reset, an SMS code, a security question, a recovery email, a support-driven reset, or the original password has not defined one authentication boundary. It has defined several, running in parallel, joined by OR. The account admits you if any single path succeeds. The strength of that logic is the strength of its weakest term, and the passkey is never the weakest term. Nothing in the added control changes the terms that were already present.

This is observable without access to the service internals. Present a passkey and you are admitted. Trigger a recovery flow and you are also admitted, through a path the passkey does not touch. Both routes end at the same account. The passkey does not gate the recovery route and the recovery route does not require the passkey. Two doors, one room. Adding a stronger lock to one door is not a statement about the other door. It is a statement about one door.

The sync fabric extends the same logic to the key material itself. A synced passkey is present wherever the platform account can place it. Access to the platform account yields access to the key. The platform account therefore becomes a second parallel path to every service the passkey serves, and that account is protected by a password and a second factor, which returns the failure to the model passkeys were sold to replace. The private key described as bound to your device is, by the default configuration most users receive, reachable through a vendor account. That is the design, not a defect in it.

The pattern is additive security. A new control is placed on top of an existing stack, the old paths are left in place, and the posture is reported as the strength of the new control while the system still runs at the strength of the old ones. The floor does not move when you add a ceiling. Adding a passkey to an account that still accepts SMS recovery raises the best case and leaves the worst case exactly where it was. The attacker operates in the worst case. He always has.

The same mechanism produces the concentration problem from a different direction. Collapsing many credentials into one platform account is presented as simplification. It is simplification. It is also aggregation of failure. One account now stands in front of every service that trusts a synced passkey. Concentration is only safe when enforcement rises to match it, and the facts describe the concentration without the matching enforcement. The platform account carries more value than any single service credential and is defended by the same scheme as before. Value went up. The lock did not.

Both instances share one property. The strong control is real and the weak path is retained, so the weak path defines the outcome. This is the shape of every authentication system that adds without removing. The passkey is a clean example because the messaging is precise about the strength of the thing it added and silent about the paths it did not close. Read any deployment by what it still accepts, not by what it now offers.

So state it plainly. A passkey is the authentication boundary only when every other accepted path is removed or raised to equal strength. Until then the boundary is the weakest path the service still accepts, and the passkey sits on top of it without governing it. This is measurable. List every way into the account. The strength of the account is the strength of the weakest item on that list. The passkey does not change the list. You do, or the service does, or no one does and the number stays where it was.

For a synced passkey the platform account is the account. Whoever holds the Apple or Google account holds every passkey inside it. That account must be treated as the highest-value credential the user holds, because it now is, and it must be defended above the services beneath it, not at parity with them. Whether a given user or a given service has done this is not confirmed and cannot be assumed. It has to be verified per account and per service. Absence of that verification is not evidence of safety. It is absence of data.

The cryptography was never the question. Passkeys close phishing and credential stuffing, and they close them well. That is the part the vendors are right about. The part they leave out is that closing one path does not close an account, and an account is only as closed as its most open door. Controls that any fallback can override are not controls. They are preferences the attacker is free to decline. Treat the passkey as one lock among several, find the weakest one, and understand that until it is gone, it is the only one that describes your risk.