The rule is that a passkey cannot be phished. This is not a marketing claim. It is a property of how the thing is built, it holds under adversarial conditions, and it is the reason five billion of them are now in use.
The exception is that nobody has to phish it. An attacker who cannot take your passkey can simply arrange for you not to use it, and the industry has spent the whole rollout building the door that makes this possible.
How it actually works
When you create a passkey, your device generates a pair of mathematically linked keys. The private one never leaves the device, and on most modern hardware never leaves a dedicated security chip that the rest of the machine cannot read from directly. The public one goes to the website, which stores it.
When you sign in, the site sends a random challenge, essentially a large number it has never sent before. Your device asks you to prove you are there, with a fingerprint, a face or a device PIN, then signs that challenge with the private key. The site checks the signature against the public key it holds. If it verifies, you are in.
Two consequences fall out of this, and they are the whole value proposition.
The first is that a breach of the site yields nothing worth stealing. The server holds public keys, which are public by design. There is no password file, no hashes to crack at leisure, no credential to reuse against the other places you have used it.
The second is the phishing resistance, and it is more elegant than most people realize. The signature is bound to the origin, meaning the actual domain in the address bar. Your browser tells the authenticator which site is asking, and the authenticator will only sign for the site that credential was created for. A convincing replica on a lookalike domain does not get a weak signature or a partial one. It gets nothing, because no credential exists there. The user cannot be talked into overriding this, because the user is never asked.
Which is why the attack moved
Attackers did not spend the intervening years trying to break that. They went around it, and the route is the one every organization left open on purpose.
Almost nobody who deploys passkeys removes what came before. Passkeys get added alongside the password, the SMS code, the authenticator app, the emailed link and the help desk. That is a sensible transitional decision, because a hard cutover locks out anyone whose phone is broken or lost. It also means every account with a passkey has other doors, and the attacker chooses which one to knock on.
The documented version of this is a downgrade. Proofpoint researchers demonstrated one against Microsoft Entra ID in which a phishing proxy presents itself as an unsupported browser configuration, Entra responds by not offering passkey sign-in, and the user is guided to a weaker method instead. Nothing is broken. The system behaves exactly as designed for a genuinely unsupported browser. The attacker has only chosen which capability the server believes the client has.
Recovery is the actual control point
The deeper problem is not sign-in at all. It is what happens when sign-in fails.
Every account needs an answer to a lost device, and that answer is the account’s real security level regardless of what the front door is made of. If the recovery path ends at an emailed link, then the account is as strong as that mailbox. If it ends at an SMS code, it is as strong as the phone carrier’s resistance to a port-out request. If it ends at a support agent with the authority to make an exception for a frustrated customer, it is as strong as that person’s afternoon.
This is why the interesting number in the FIDO Alliance’s 2026 adoption report is not the five billion passkeys, the ninety percent consumer awareness or the ninety-three percent login success rate against sixty-three for passwords. It is that account recovery remains the stated barrier for sixteen percent of organizations that have not gone fully passwordless. They have looked at the problem, understood it, and stopped there, which is the correct order to do things in.
Synced and device-bound are different products
The distinction gets flattened in most coverage and it changes your threat model entirely.
A synced passkey is backed up to a platform account, an Apple, Google or Microsoft keychain, and appears on your other devices. Convenient, and the reason adoption moved at all. It also means the passkey is exactly as secure as that platform account, and inherits whatever recovery that account permits.
A device-bound passkey, including a physical security key, exists in one place. It cannot be silently copied to a machine you do not control. It also cannot be recovered if you lose it, which is why anyone deploying them registers a second one on day one and why the ones who did not have learned something expensive.
Researchers published work in August showing malware on an already-compromised endpoint abusing onboarding and device-trust flows to extract synced private keys and authenticate without user interaction. Read that carefully before drawing the wrong conclusion. It requires the attacker to already be running code on your machine, which is a bad day by any measure. But it does establish that a synced passkey is not equivalent to a hardware key, and anyone treating the two as interchangeable in a risk register is filing a comfortable fiction.
What this means if you are the one deploying it
Passkeys are worth doing, and the UK’s National Cyber Security Centre reaches the same conclusion in the same qualified terms. The phishing resistance is real, the breach exposure genuinely improves, and the login success numbers say users prefer them. None of that is in question.
What is in question is whether you have moved your risk or removed it. Adding a phishing-resistant method while leaving four phishable ones enabled has not removed phishing from your organization. It has added an option that motivated attackers will route around, and left you with a slide saying you are phishing resistant.
The work is unglamorous and it is all in the fallbacks. Audit every path to an authenticated session, not only the one on the login page. Decide which of them you can switch off and when. Make the recovery process at least as strong as the front door, which usually means something slower and more annoying than anyone wants to sign off.
Your organization employs somebody authorized to restore access to an account over the phone, to a caller who sounds upset and is in a hurry. Everything above is a description of the cryptography protecting your users. That person is the security of your system.
