Passkeys Were Supposed to End Lockouts. We Tested What Happens When the Phone Disappears

Passkeys arrived with an unusually clean sales pitch: nothing to remember, nothing to type, nothing for a phishing site to harvest. Two years into mainstream deployment across US banks, retailers, and all three major mobile platforms, that pitch mostly holds up. Sign-in on a phone you already own is faster and safer than the password it replaced.

The friction shows up somewhere else. It appears the moment the device holding the credential is gone — lost, stolen, wiped, sold, or simply replaced by a phone from a different manufacturer. We spent several weeks this fall running the most common passkey flows end to end, including the unhappy paths that marketing pages rarely illustrate. What follows is what we found, and how to adopt passkeys without betting your entire digital life on one piece of glass.

Two kinds of passkey, one very different failure mode

The single most useful thing to understand is that not all passkeys behave alike.

A synced passkey lives in a cloud keychain — iCloud Keychain on Apple devices, Google Password Manager on Android and Chrome, or a third-party password manager that supports the standard. Because it syncs, losing a phone is inconvenient rather than catastrophic: the credential reappears on the replacement device once you sign back into the same account.

A device-bound passkey lives in a secure element and does not travel. Hardware security keys work this way, and so do some platform implementations and most enterprise-managed credentials. These are arguably more secure — there is no cloud copy to phish or subpoena — but they put the burden of redundancy squarely on you.

Most consumer services quietly default to synced passkeys and never tell you which model you received. That ambiguity is the root of nearly every lockout story we encountered.

Scenario one: the phone is gone

We deregistered a test iPhone from its Apple Account and attempted to sign in to a sample of twelve accounts that had been enrolled with passkeys.

Results split cleanly along the synced-versus-bound line. Accounts using synced passkeys recovered in minutes once the account credentials were re-entered on a new device. Accounts where we had registered a hardware key as the only passkey required that physical key — and where no backup key existed, the recovery route ran through the provider's support desk, which in two cases meant identity verification by ID upload and a wait measured in days.

The lesson is unglamorous but decisive: a passkey is only as recoverable as the second enrollment you bothered to create.

Scenario two: switching ecosystems

Moving from iPhone to Android, or the reverse, is where passkey portability gets genuinely murky. Cross-platform sign-in generally works through a QR code plus a short Bluetooth proximity check — you scan with the old phone, approve, and the new device gets a credential. That flow is elegant when both devices are present and both are working.

It is far less elegant when the old device is broken, sold, or already wiped. In those cases the account holder typically falls back to the provider's legacy recovery path: an email link, a one-time code, or a support ticket. Some services still allow a password fallback for exactly this reason. Others, in the name of security, have removed it — which means the recovery desk becomes the only door.

Our practical finding: before you trade in or sell a phone, enroll the new device first, verify sign-in from it, and only then retire the old one. The order matters more than most setup guides admit.

Scenario three: the shared, work, or hand-me-down device

Household tablets, shared laptops, and hand-me-down phones create a subtler problem. A passkey registered on a family iPad may be the only credential for an account, and the person who set it up may not be the person who needs it later. Enterprise-managed devices add another layer, because company policy can revoke credentials remotely and without warning.

Keep personal accounts on personally controlled devices. It sounds obvious. In practice, a surprising number of lockouts trace back to a credential that was created on a device someone else now owns.

The recovery gap nobody advertises

Every provider publishes an enrollment guide. Very few publish a recovery guide with the same clarity, and fewer still let you rehearse it. That gap carries a security cost as well: when legitimate recovery gets harder, customers lean on support staff, and support staff become the soft target for social engineering. The safest account is one whose owner never needs to call in.

A practical adoption checklist

1. Enroll two devices per critical account. A phone and a laptop, or a phone and a hardware key. Redundancy is the whole ballgame.
2. Keep one hardware security key offline. For email, banking, and your password manager, a $50 key in a drawer is cheap insurance against a lost phone.
3. Test recovery before you need it. Sign out of one non-critical account and walk the recovery flow deliberately. You will learn more in ten minutes than in an hour of documentation.
4. Record which accounts use which method. A simple list — synced, bound, or still password-based — prevents guesswork during a crisis.
5. Store recovery codes offline. Printed, in a locked drawer, not in the same cloud account you are trying to recover.
6. Retire devices in the right order. Add the new device, verify, then remove the old one.
7. Watch for downgrade attacks. If someone claiming to be you can talk a support agent into adding a new passkey, your security is only as strong as that agent's training.

The bottom line

Passkeys are a real improvement, and the phishing resistance they offer is not marketing. But the technology has moved the risk from something you remember to something you hold — and anything you hold can be lost, broken, or left behind. Treat enrollment as a two-device minimum, rehearse one recovery, and the paradox dissolves. Skip those steps, and the most secure sign-in method you have ever used becomes the most inconvenient one.