Passkeys replace a shared secret with a key pair, which removes an entire category of attack at a stroke. They also move the hard problem from remembering to recovery, and the recovery story is where the differences between implementations actually live.
The problem with a shared secret
A password is known by both sides. That single property produces the three failures every password mitigation exists to patch.
It can be stolen from the service, in which case the attacker holds exactly what you hold. It can be stolen from you, by malware or by somebody convincing. And it gets reused, because people cannot hold dozens of distinct strings in their heads, so a compromise somewhere trivial becomes a compromise somewhere that matters.
Complexity rules, expiry policies and second factors are all attempts to contain those three without changing the thing that causes them.
What a passkey is
A key pair. The private half is generated on your device and stays there. The service keeps only the public half.
Signing in means the service sends a challenge, your device signs it with the private key, and the service checks the signature against the public key it holds. The private key is never transmitted, so there is no moment at which it could be captured in flight.
The consequence worth understanding: a breach of the service leaks public keys, and public keys are not secrets. There is nothing in that database to reuse, sell, or try against another site.
Why phishing stops working
This is the mechanical part, and it is the reason passkeys matter more than their convenience suggests.
A passkey is bound to the site's domain. The browser will not offer it to a different one — not because the user is warned, but because the lookalike domain is not the domain the key belongs to, and the software declines to produce it.
The user cannot be talked into handing it over, because handing it over is not an available action. Compare a one-time code, which is a shared secret that a person can be persuaded to read aloud to somebody polite and plausible on the telephone. The code depends on judgement. The passkey removes the judgement from the loop.
The part nobody mentions
Recovery. Where the private key lives, and what happens when the device does not.
Synced. The key is encrypted and kept in a platform account, so a new device can retrieve it. Convenient, and it makes that platform account the real credential — everything now rests on whatever protects it.
Device-bound. The key never leaves the hardware. Stronger, and the loss of the device is final unless you registered another one.
The advice that follows is dull and is the whole thing: register a second device before you need it. Almost nobody does, because it takes ten minutes on a day when nothing is wrong.
Questions worth asking of any implementation
Is the key synced or device-bound, and if synced, what protects the account it syncs to?
What is the recovery path when the device is gone? If it falls back to a password or an emailed link, the implementation has quietly reintroduced everything passkeys removed, and the weakest path is the one an attacker will use.
Can you register more than one device, and does the interface make that discoverable rather than buried?
Is it worth doing
For accounts that matter, yes — with the second device registered first.
Honestly, though: a password manager generating unique passwords, plus a hardware second factor, gets most people to a similar place. The gap in raw security is not enormous.
The real gain is different. That setup requires discipline, sustained for years, by a person who is sometimes tired. Passkeys make the correct behaviour the default and the incorrect behaviour unavailable. That is a better property than strength, because it does not decay.
Close
The security improvements that survive contact with real life are the ones that stop depending on the user being careful. Judged that way, this is a genuine advance — and the recovery step is the part where it still asks something of you, which is exactly why it is the part to do first.