Passkeys prove the device. They do not prove the person.

Passkeys are the best thing to happen to consumer authentication in twenty years and I would encourage almost every organisation to adopt them. I also think the industry has started claiming something for them that they do not do, and the gap is going to matter.

The numbers are no longer speculative. Around ninety per cent of consumers are familiar with passkeys and roughly three quarters have enabled one on at least some accounts. More than fifteen billion online accounts can use them, though the number actually in active use is closer to five billion, and the gap between those two figures is the real state of adoption. Regulators are moving too: the UAE and the Philippines have both acted to phase out SMS one-time codes in specified banking uses, while India has broadened the permitted methods without removing SMS. The direction is a floor rising rather than a preference.

All of that is good. Phishing resistance is real, credential stuffing stops working, and the password reuse catastrophe that has driven a decade of breaches finally has an exit. None of what follows is an argument against deploying them.

What a passkey actually asserts

Strip away the branding and a passkey is a key pair. The private half lives in an authenticator, a phone, a laptop, a hardware key or a password manager. The public half sits with the service. Signing a challenge with the private half proves that the authenticator holding it participated.

That is the assertion. This authenticator, which was registered to this account, is present and was unlocked.

Notice what is not in that sentence. It does not say a particular human is present. It says the authenticator was unlocked, and the unlocking is a local matter between the person and the device. Your face or fingerprint never leaves the device and is never seen by the service. The service is trusting the device's word that somebody satisfactory unlocked it.

For most consumer purposes that is a completely reasonable trade, and the alternative, sending biometrics to a server, would be far worse. But it means the chain terminates in a local policy you do not control. If the device is configured with a four digit PIN as a fallback, the assertion the service receives is indistinguishable from the one produced by a face check. It is the same signature.

Sync moved the problem

The change that made passkeys usable is the same change that redefined their threat model. Device-bound passkeys were secure and unforgiving: lose the device, lose the account. That is unacceptable at consumer scale, so passkeys now sync through Apple, Google and cross-platform managers.

Sync solves recovery. It also means the private key is no longer confined to a single piece of hardware, and the security of the account inherits the security of the sync account and its recovery flow.

Which relocates the attack rather than removing it. Compromise the platform account, or socially engineer the recovery process behind it, and the passkeys follow. The phishing page is gone and the help desk call is not. Every account protected by a synced passkey is, in the last resort, protected by whatever stands behind that platform account, and for a very large number of people that is still an email address and a support agent's judgement.

I do not think that makes sync wrong. Device-bound credentials at consumer scale produce mass lockout, and lockout is a harm too. But the honest description of a synced passkey is that it is excellent against remote attackers and only as good as the recovery process against a determined one.

The fallback nobody removes

Adoption is stalling, and the reasons given are ecosystem fragmentation, confusing flows and persistent password fallbacks. The third is the one that undoes the other two.

Almost every deployment keeps the password. It has to, at first, because not every user has a passkey and not every device supports the flow. So the account has a strong new front door and the old door is still there, unlocked, behind a link that says "having trouble signing in".

An attacker does not have to defeat the passkey. They pick the weakest enabled path, and the weakest enabled path is generally the one you kept for compatibility. Until the password is genuinely removed rather than de-emphasised, the account's security is the maximum of its methods rather than the strength of the best one, and that arithmetic is the wrong way round.

The question passkeys were never designed to answer

Here is where this connects to everything else I work on.

A passkey answers: is the registered authenticator present? That is an excellent answer to the login question and a poor answer to a different question that is becoming more important.

Is the person who is supposed to be doing this actually the one doing it, right now, for this specific action?

Those diverge the moment consequence enters. Signing in is low stakes. Approving a payment, changing bank details, authorising a transfer, releasing goods, signing a document: these are the moments where fraud actually lands, and in nearly every system they inherit their authority from a login that happened earlier. The passkey was checked at the door. The action happens in the building.

This is the same structural problem I keep running into. Biometric checks that verify at enrolment and inherit afterwards. Age checks that verify once and carry a cookie. Agents that act on a delegation granted long before the action. In every case the check is sound and the inheritance is where the loss occurs.

A stolen unlocked phone is the everyday version. The passkey works perfectly. It is the right device, genuinely present, correctly unlocked. Everything the protocol was designed to prove is true, and the wrong person is holding it.

What I would build on top

Use passkeys for authentication. Do not use them as evidence of intent.

Separate the two. Signing in is one decision. Authorising something consequential is another, and it deserves a fresh check tied to the specific action, showing the user what they are approving, at the moment they approve it. If your architecture cannot distinguish "this session is authenticated" from "this human confirmed this transaction", it will eventually pay for the difference.

Then be honest about your recovery path, because that is your real security level. It is worth writing down the cheapest route into an account and looking at it directly. It is almost never the passkey.

And set a date to remove the password rather than an intention to. A fallback with no removal date is a permanent feature.

Passkeys have made the front door dramatically harder to force. That is a genuine achievement. It also means attackers have already moved on to the windows, and the windows are recovery flows, help desks and the long unguarded stretch between logging in and doing something that matters.