Are Passkeys a Trap? How to Back Them Up So a Lost Phone Can't Lock You Out

The usual argument that passkeys are a trap goes like this: Apple, Google and Microsoft want your logins stuck in their ecosystems. In October 2026 that argument is a year out of date. You can now move passkeys out of Apple Passwords and Google Password Manager into a third-party manager with an official, encrypted transfer.

The thing that will actually lock you out of your accounts is much less interesting. You have one phone, every passkey lives on it, and it ends up at the bottom of a lake. Further down is how I back them up so that can't happen: one synced manager you picked yourself, plus two hardware keys.

Scott Helme published Passkeys are not a trap this week as a reply to a viral "Passkeys are a trap. Do not use them" post, and the Hacker News thread turned into the usual brawl. I'm with Helme on the lock-in question. But the HN skeptics are right about a different problem, and he barely touches it.

The "passkeys are a trap" argument, briefly

The anti-passkey post rests on attestation. A WebAuthn site can ask for cryptographic proof of what created the credential. The worry is that sites will slowly turn that dial up until only "approved" phones on "approved" operating systems can log in. Rooted Android and LineageOS users would be locked out, and so would anyone who doesn't run stock iOS.

Helme's rebuttal is short:

• Synced passkeys in iCloud Keychain, Google Password Manager, 1Password and Bitwarden return an attestation of none. He maintains an open-source passkeys library, so he has seen this firsthand.
• A consumer site that required attestation would lock out most of its own users on day one. For years the guidance to consumer sites has been not to request it.
• When attestation is present, it identifies the authenticator's make and model through its AAGUID. It says nothing about your OS, browser, extensions or root status.
• The original post recommends a YubiKey instead. YubiKeys do attestation, and enterprise attestation exists so companies can require specific keys.

The worst part is the alternative it pushes: passwords plus TOTP. Phishing kits like Evilginx relay a password and a six-digit code in real time. A passkey is bound to the domain it was created for, so a lookalike site gets nothing. Giving up phishing resistance to avoid a hypothetical attestation ratchet is, in Helme's words, "a really bad trade." A slippery slope is not a trap you're already in, and if consumer sites start demanding attestation, you can complain loudly then.

Lock-in was a fair complaint in 2024, until export actually shipped

dfabulich repeated the classic complaint in the thread: "Most password managers don't even allow you to export/backup the passkeys yourself." For a long time that was simply true, and your passkeys belonged to whichever vendor made your phone.

Then the FIDO Alliance published two specs: the Credential Exchange Format (CXF), a standard JSON schema for credentials, and the Credential Exchange Protocol (CXP), an HPKE-encrypted transport for moving them between managers. 1Password, Apple, Bitwarden, Google and others co-wrote them. And then the vendors put them in their apps:

There are caveats. CXP was still a working draft as of May 2026, so for now transfers are on-device migrations between two apps on the same phone or Mac. Google Play services updates roll out gradually, so your phone may not have it yet. Reports in the HN thread are mixed: watermelon0 says moving between Apple Passwords and Bitwarden "worked without issues, in both directions", while kmac_ still sees Bitwarden's import and export as "a promise or 'coming soon.'" It's rough, but you can leave. You couldn't really leave a password manager that only exported CSV either.

One device, zero backups

The best comment in the thread came from jwitthuhn: "So the solution to my iDevice dying is that I have to buy a new one to maintain access to my accounts and have no option to move to non-Apple hardware?"

That's the failure people actually run into, and you set it up yourself. A site asked "Save a passkey?" at login, you tapped yes, and your phone became a single point of failure.

Two more complaints from the thread make it worse:

• Some sites allow only one passkey. kccqzy points out that "Many sites don't even allow multiple passkeys", so a backup key is out.
• Some sites remove other ways in. chaboud: "Some sites, once connected via passkey, make it all but impossible to connect in another way."

As jasomill pointed out in the thread, account recovery usually runs through the same mechanisms used to reset a forgotten password. On most consumer sites that means email. So your email account is the root of everything, and it's where you start.

How to switch to passkeys without locking yourself out

1. Pick one manager on purpose

Don't let the browser decide. bonzog described a passkey that "could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother." Choose one that syncs across every OS you use and supports Credential Exchange, so you can leave later. Helme's advice is the same: if you want to move credentials around, "pick a provider that supports that."

2. Buy two hardware keys

One key isn't a backup. A YubiKey 5 on firmware 5.7 or newer stores up to 100 passkeys. YubiKey firmware can't be updated, so check the version before you buy secondhand. Register both keys on your critical accounts and keep one in a drawer somewhere other than your house. With ykman from Yubico you can check what's on a key:

ykman info                      # firmware version
ykman fido credentials list     # resident passkeys (asks for your FIDO PIN)

3. Turn on passkeys in this order

1. Primary email account. It's your recovery root. Add the synced passkey and both hardware keys.
2. Apple / Google / Microsoft account. It holds the synced passkeys themselves. Set recovery contacts or recovery keys while you're there.
3. Password manager, if it supports passkey or hardware-key unlock.
4. GitHub, domain registrar, cloud console. These are the accounts phishing crews target for developers. GitHub lets you register several security keys.
5. Everything else when it prompts you. Leave banks and other sites with weird one-passkey limits until last.

4. Test the backup before you need it

Sign out, then sign back in with only the drawer key. If that fails, you have no backup.

5. Write down recovery codes

Do it for anything that issues them, and store them offline. Old advice, still good.

Where the critics are still right

The UX is genuinely bad in places. Prompts show up at login, which Klathmon called "the absolute worst time to ask anything." The cross-device QR flow needs Bluetooth, so it breaks on VMs and remote desktops, and on Linux some users report Firefox never offering the phone option and PayPal refusing to create a passkey at all. As compiler-guy put it: "if the implementation sucks, the standard sucks." Fair enough.

Still, uneven implementations are a reason to keep a backup plan. They don't turn passkeys into a lock-in scheme. If you're a developer shipping WebAuthn, the fix is on you: allow several passkeys per account, don't request attestation on consumer flows, and don't silently remove the password fallback.

So have you moved your accounts to passkeys yet, or are you holding out? If you're holding out, is it attestation, recovery, or the fact that half your passkeys ended up in a manager you never chose? Tell me in the comments.

Sources

• Scott Helme, Passkeys are not a trap
• Hacker News discussion
• Google system services release notes (Play services v26.21)
• 9to5Mac, iOS 26 passkey transfer
• Strongbox issue #867 on CXP/CXF support status
• 1Password, Portability without compromise
• Yubico, firmware 5.7 announcement