Practical guide · verified against the real thing
Passkeys explained: what they actually stop, what they don't, and when to keep a password anyway
In one line: A passkey is a per-site key pair, not a secret you type. That kills phishing and reuse - and leaves a different set of problems you should plan for before you switch.
A passkey replaces "something you know" with "something you have, plus something you are." When you create a passkey for a site, your device generates a key pair: the private key never leaves your device's secure storage, and the site keeps only the public half. At login, the site sends a challenge your device signs with the private key, unlocked by your fingerprint, face or device PIN. There is no shared secret for a breached database to leak, and nothing to type into a lookalike page.
What passkeys genuinely stop
- Phishing, structurally. The signature is bound to the site's real origin. A fake page on a fake domain cannot get a valid signature from your real passkey, so the attack that beats passwords simply does not compute. This is the big one.
- Credential-stuffing and reuse. Each site gets its own key pair, so one breach compromises nothing elsewhere. The reuse problem from the migration guide disappears by construction.
- Leaked-password databases. The site never stores a secret that can be stolen; a breached verifier list of public keys is useless to log in.
What they don't stop
Passkeys authenticate the device and its unlock, not your judgement. They do nothing about malware on an already-compromised device that acts as you while you are logged in. They do not protect a session after login - cookie theft is still cookie theft. And they do not help if the site's own account-recovery flow is lax: an attacker who can convince support to move your account to their device bypasses the cryptography entirely, which is why recovery hygiene matters more, not less, with passkeys.
The real problem: losing the thing that holds your keys
A passkey lives in a device or a synced ecosystem. Lose the phone with no backup and no fallback, and you can be locked out of an account you provably own. So the discipline inverts from "remember many secrets" to "protect the few recovery paths": keep a password-manager fallback or a printed backup code on high-value accounts until you have confirmed the passkey syncs where you expect.
When to keep a password anyway
Keep a traditional password plus two-factor on accounts where you cannot tolerate a single-device dependency, on shared-family accounts, and anywhere you sign in from borrowed or public machines - a passkey is least comfortable on hardware you do not control. The honest reading is that passkeys and a good manager are complements, not rivals: passkeys where supported and low-risk to recover, manager-generated passwords everywhere else. For the broader picture of what each layer stops, see the safety table.
Sources
Next