Passkeys vs passwords: a calm explanation of why we are moving on
Passkeys are not a marketing reframe of passwords with extra steps. They are a different cryptographic primitive that makes most credential-stuffing, most phishing, and most password reuse simply inapplicable. Here is the actual model, the migration playbook, and the genuine weaknesses nobody at the launch event will tell you about.
Passwords have one redeeming property: they are universal. They have roughly forty disqualifying ones. They are reused, leaked, phished, brute-forced, written on sticky notes, mistyped, expired, rotated into worse versions of themselves, and recovered through email links that are themselves protected by a password. The replacement is finally arriving in earnest, and it is genuinely better.
As of early 2026, roughly 87% of enterprises are deploying or piloting FIDO2 passkeys. More than fifteen billion accounts across Apple, Google, Microsoft, Amazon, GitHub, and PayPal are passkey-eligible. Public success rates run around 98% versus a sign-in failure rate for passwords that is, depending on which study, somewhere near the same number on the wrong side. After rollout, support tickets for sign-in issues drop 60–80%. None of this is hype; it is what happens when you replace a guessable secret with a cryptographic key.
What a passkey actually is
A passkey is a public/private keypair tied to a specific website. The private key is generated on your device and never leaves it (or, if it does, only as encrypted blobs to a vendor cloud — more on that below). When a website asks you to sign in, it sends a random challenge. Your device asks you to confirm with a fingerprint, face, or PIN, then signs the challenge with the private key. The site verifies the signature with the public key it stored at registration. No shared secret was ever transmitted, ever stored on the server, or ever typed into a form.
Three properties fall out of this:
- Phishing-resistant by construction. The signature includes the origin (the real domain). A phishing site at a similar URL gets a signature it cannot use. Pixel-perfect fake pages stop working.
- Server breaches do not leak credentials. The server stores public keys. Public keys are public. There is nothing to crack.
- Reuse becomes meaningless. Each site has its own keypair. There is no shared secret to reuse across sites, so a leak at one site does not affect any other.
The migration playbook for individuals
Do not try to passkey-ify everything in one weekend. The pattern that works:
- 1Pick one critical account — email or your password manager. The email account is usually the better choice because it is the recovery channel for everything else.
- 2Add a passkey while keeping the password and the existing 2FA in place as fallbacks. Test sign-in from a second device.
- 3Use a password manager that supports passkey sync — 1Password, Bitwarden, Apple Keychain, Google Password Manager, Dashlane all do as of 2026. This avoids the "lost device, lost passkey" failure mode for most people.
- 4Add passkeys to the next five most-used accounts: bank, work SSO, GitHub, primary social, primary cloud storage. Stop there for a week and observe.
- 5Once you have lived with it for a fortnight without a recovery scare, expand to everything else passkey-eligible. Leave the password set on each as a fallback for now.
For organisations
The single biggest enterprise win is removing SMS MFA. SIM-swap and real-time phishing of OTP codes account for a meaningful share of account takeovers, and SMS as a fallback undermines passkeys you have already deployed. Replace SMS with platform passkeys plus a hardware security key as the recovery method for high-value accounts. The CFO does not need a YubiKey for Slack, but they probably do for the wire-transfer system.
The honest weaknesses
Account recovery. If a passkey lives only on one device and the device drowns, recovery falls back to whatever the site offers — usually email, a phone number, or a recovery code. That fallback channel is now the weakest link, and it deserves its own passkey or hardware key. If you do not harden the recovery channel, you have not raised the floor; you have moved it.
Vendor lock-in on sync. iCloud Keychain syncs Apple-to-Apple. Google Password Manager syncs across Android and Chrome. Cross-ecosystem sync (work iPhone, personal Android, Linux desktop) still works best through a third-party password manager that explicitly supports passkey sync. If you live across two ecosystems, pick a third-party manager from day one and skip the platform-default trap.
Shared accounts. Family Netflix, the office Twitter, a small-team AWS root — passkeys do not love multi-person accounts. Workarounds exist (a vault that holds the passkey and re-prompts each user, or a hardware key passed around), but the experience is rougher than a shared password.
Passkey UX is not yet uniform. Some sites surface passkey prompts beautifully; others bury the option three settings menus deep and revert to password by default. This is improving fast but it is still uneven.
What we use
Passkeys are mandatory for staff access to production systems; SMS MFA was retired in 2024. Customer accounts on planet-proxy.com support passkeys alongside passwords today, and we will turn off passwords for new accounts once recovery flows for the lock-out edge cases are unambiguous. We are not in a hurry to be cute about it. Most of the win comes from getting the high-value accounts onto passkeys; the long tail can wait until the recovery story is boring.
The short version: this is the rare security upgrade where the user experience is also better. Most upgrades ask people to suffer a little for safety. This one mostly does not.
Frequently asked
If I lose my phone, do I lose all my passkeys?+
Only if your passkeys were device-bound and not synced. Most modern setups (iCloud Keychain, Google Password Manager, 1Password, Bitwarden) sync passkeys to a cloud vault encrypted with a key only you hold, so a new device can recover them. For high-value accounts, also register a hardware security key as a backup.
Are passkeys safer than my password manager with strong unique passwords?+
Yes, against phishing and server breaches. A password manager with unique passwords removes reuse risk, but a perfect phishing site can still capture and replay the password in real time. A passkey signature is bound to the real domain and will not authenticate to a fake one, regardless of how convincing the page is.
Run PlanetProxy for seven days, on us.
Same purple tile cards you see on this page, plus the green lock and a 50 ms hop to wherever you want to be.
Start the trial →More from the dispatch
SecurityPP · DispatchHow to read a no-logs audit (without the marketing gloss)Security · 8 minHow to read a no-logs audit (without the marketing gloss)
Every VPN claims "no logs". A small fraction back the claim with an audit. An even smaller fraction publish the audit. Here's how to actually read one.
SecurityPP · DispatchThe kill switch: the small detail that decides whether a VPN actually protects youSecurity · 6 minThe kill switch: the small detail that decides whether a VPN actually protects you
A VPN is only as good as the moment its tunnel drops. Here is what the kill switch is, why most implementations are weak, and how to verify yours actually works.
- SecurityPP · DispatchPost-quantum cryptography: why "harvest now, decrypt later" is the threat that mattersSecurity · 8 min
Post-quantum cryptography: why "harvest now, decrypt later" is the threat that matters
A large quantum computer is probably still years away. The recordings of your traffic from this afternoon are not. Here is what HNDL actually means, what NIST finalised in 2024, and what "post-quantum ready" looks like for a VPN that is not just selling a sticker.