A post titled "I don't like passkeys" spent a day near the top of Hacker News recently, pulling in hundreds of comments. The author, Ethan Hawksley, is not a password-hating contrarian. He concedes that passkeys are a fantastic technology, phishing-proof and breach-resistant. His complaint is narrower and more damaging: for an individual person, passkeys trade a rare risk (getting phished) for a common one (losing access to your own account).
That argument deserved the attention it got, because it exposes a real gap between what passkeys promise and what the ecosystem delivers. So instead of another "passkeys are the future" take, this is a straight comparison: passkeys vs passwords, scored on the things that actually decide whether your accounts survive the next five years.
Full disclosure up front: everything below comes from vendor documentation, the FIDO Alliance specs, and public discussions, not from a personal month-long migration project. Where a claim depends on vendor docs, I link the source.
Round 1: Phishing resistance. Passkeys win, and it is not close
A password can be typed into any login form, including a fake one. A passkey cannot leave the site it was created for. The credential is bound to the site's domain, so a phishing page for your-bank.com simply cannot trigger a signature for your real bank. This is structural, not behavioral. It works even when you are tired, distracted, or in a hurry.
What the password side looks like: hardware keys and TOTP apps raise the bar, but both still fail against a real-time adversary-in-the-middle proxy, where the attacker relays your one-time code to the real site while it is still valid. Microsoft has documented these campaigns in detail.
Score: passkeys 1, passwords 0. On the primary login path, passkeys are strictly better.
Round 2: Portability. Passwords win by a mile
Here is the part the passkey marketing skips. A password is a string. You can write it on paper, export it to a CSV, memorize it, or retype it on a borrowed laptop. A passkey is a private key that, by design, resists being copied. That is great against thieves and terrible when the owner is the one who wants to move.
The industry knew this was a problem. The FIDO Alliance published draft specifications in late 2024, the Credential Exchange Protocol (CXP) and the Credential Exchange Format (CXF), designed to let you move passkeys between managers without ever writing private keys to a plaintext file. Apple, Google, Microsoft, 1Password, Bitwarden, Dashlane, and NordPass all sat in the working group.
So how much of that promise is live right now? I went through the current support matrix, and it is genuinely patchy:
- Apple Passwords shipped CXP first, in iOS 26. You export from the Passwords app via "Export Data to Another App," and Bitwarden was the first third-party manager to accept it.
- Google Password Manager supports the protocol on Android 14 and up, but only with Google Play Services 26.21 or newer. On Android the flow is reversed: the target app initiates an import request, not an export from Google.
- Bitwarden has the strongest exit path overall. Its JSON export includes passkeys, its mobile apps speak the protocol on both iOS and Android, and passkeys work on the free plan.
- 1Password exports passkeys from its mobile apps only. A desktop export leaves them behind. As of September 2026, importing passkeys into 1Password on Android was still not working, because the app asks for a CSV and Google will not put passkeys in a CSV.
- Microsoft Password Manager is the worst offender: as of mid 2026 there is no way at all to export a passkey out of it.
- NordPass and Proton Pass document no passkey import or export route.
Compare that with the password path: every manager on earth exports passwords to CSV in about four clicks. Flawed format, yes, but universally portable.
Score: passwords 1, passkeys 0. The escape hatch exists on paper and works only in specific device-and-version combinations.
Round 3: Recovery and lockout. Passwords win again
This is the core of the "I don't like passkeys" argument, and it holds up. Your account's real security is set by its weakest recovery method, not its strongest login. If a site still offers SMS recovery or email magic links, an attacker goes around the passkey entirely. Meanwhile, the passkey raises a new risk for you: if you lose the device and the synced vault behind it, you may lose the account.
The nightmare scenario is platform-level. Both Apple and Google anchor their passkey sync to your Apple ID or Google account. Automated moderation on those platforms is imperfect, and there are documented cases of users losing everything. The New York Times covered a father whose Google account, holding years of family photos, was permanently banned after automated CSAM flagging of toddler photos, with no human review and no appeal path. Now imagine your passkeys for email, banking, and work all living behind that same kill switch. A password does not have this failure mode. No corporation can ban you out of a string you wrote down.
Score: passwords 1, passkeys 0, and the stakes here are higher than in any other round.
Round 4: Hardware keys and shared devices. Hidden costs on the passkey side
Passkey advocates often suggest hardware keys as the answer to lockout risk. The math gets ugly fast. Passkeys on a hardware key cannot be backed up at all; they can only be created or deleted. So the real setup is two or three keys, each enrolled separately on every site. And keys have capacity limits: Yubico's own documentation puts discoverable credentials at 25 to 100 per key, with top-of-the-line models reaching about 300. If you have more accounts than slots, you are buying more keys or deleting credentials.
Then there is the borrowed-computer problem. Passwords: you type your vault's master password on a machine you do not fully trust and change nothing. Passkeys on someone else's laptop means a QR code plus a simultaneous Bluetooth connection (the "hybrid transport"), which is secure in theory and famously flaky in hotel rooms and offices with locked-down Bluetooth.
Score: passwords 1, passkeys 0. Passkeys assume you control the device in front of you. Life does not always cooperate.
Final score: 3 to 1 for passwords, with one enormous asterisk
That scoreline is misleading if you read it as "passwords are safer." They are not. The one round passkeys win is the round where people actually lose money at scale, because phishing is an industrial operation and device loss is a personal accident. The honest summary:
- Passkeys are a step up if you currently reuse one password everywhere. Almost anything is.
- Passkeys are a step sideways or back if you already use a password manager with unique random passwords plus a TOTP app. You would trade portability and recovery control for phishing resistance you mostly get anyway from a good password manager's phishing-aware autofill.
What I would actually do: a practical decision checklist
If you are deciding today, here is the takeaway I would save:
- Keep a password manager as your base, not a platform vault. Bitwarden currently has the best documented exit path for passkeys (JSON export plus protocol support on iOS and Android). 1Password is fine if you stay inside it, but check its export limits first.
- Use passkeys selectively for high-value, low-recovery-risk sites. Sites where you have another working recovery path, or that matter enough to justify two enrolled credentials.
- Never let a passkey be the only key to an account that matters. Enroll a second factor, keep working recovery codes offline, and confirm the recovery path actually works before you rely on it.
- Skip passkeys entirely on sites where recovery is SMS-only. You get none of the security benefit and all of the lockout risk.
- Do not migrate passkeys between platforms yet unless you have verified both ends support it. Microsoft Password Manager cannot export them at all, NordPass and Proton Pass have no route, and several flows silently fail on version mismatches.
- If you use hardware keys, budget for the capacity math. Two to three keys, enrolled per site, within the credential limits of the model you buy.
The bigger picture
The telling thing about this debate is that the industry needed a brand-new protocol pair, years of committee work, and an iOS release just to restore an ability password users never lost: the ability to leave. When a technology's portability requires a dedicated Diffie-Hellman handshake between two apps, that is not a feature gap, it is a design tension. The same property that makes a passkey unstealable makes it unownable by you in any practical sense. Hawksley's conclusion matches what the support matrix shows: passkeys are ready for enterprises with IT departments and spare hardware keys, and not quite ready for individuals who are the sole custodians of their own access.
The ecosystem is moving in the right direction, and 2026's protocol rollouts are real progress. But "check back in a year" is a legitimate answer to "should I switch," and it is the one the HN crowd overwhelmingly gave.
I write about developer tools, security, and the gap between tech promises and tech reality every week. Subscribe, it is free.
Have you migrated to passkeys yet, or did you hit a wall trying to move one between platforms? I would like to hear which vault you landed on.
Top comments (0)