Passkeys, the FIDO2/WebAuthn credentials that replace passwords with public key cryptography, are the right answer to the password problem. The industry has agreed. Apple, Google, Microsoft, the password manager vendors, and the major relying parties have all committed. The migration, however, is a mess. The reason is not the cryptography. The reason is the edge cases the FIDO Alliance did not think through, the credential portability that turns out to matter, and the recovery flow that nobody wants to be the first to ship.
What is actually broken
Three categories, in roughly that order of severity. The first is cross device portability. A passkey is, by design, bound to a device or to a sync provider (Apple iCloud Keychain, Google Password Manager, Microsoft Account). A user who wants to move from iPhone to Android has to either trust the cross platform QR code handoff protocol (which works but is awkward), or re enroll their passkeys from scratch (which is friction the user will not tolerate). The second category is recovery. The user loses their phone. The user loses access to their iCloud or Google account. The passkey is gone. The recovery flow, when there is one, requires the user to remember which accounts they had passkeys on and walk through a recovery dance per account. Most users do not. The third category is the relying party implementation. Some sites ship passkeys that do not work cross browser. Some sites ship passkeys that fail silently and let the user fall back to a password. Some sites ship passkeys that work, but the user has no way to tell, because the UX is the same as for a password.
The FIDO Alliance is aware of all three. The alliance is working on cross platform credential portability through the credential exchange spec. The alliance is working on recovery through a separate workstream. The alliance is not, and will not, mandate how relying parties implement the UX. That part is on the sites.
What the realistic path forward looks like
For the user, the answer mirrors the password answer: use a password manager that supports passkeys. Bitwarden, 1Password, and Dashlane all support passkey storage in 2026. The user adds the passkey once, to the password manager, and the password manager handles the cross device and cross platform handoff. The user no longer cares that the passkey was created on iPhone. The user logs into the password manager on any device, and the password manager fills the passkey. This pattern works. The friction sits in the user having to trust the password manager, which amounts to the same trust model a password manager already requires, and which the user either has or does not.
For the relying party, the answer is harder. The site has to implement passkey registration, passkey authentication, and passkey recovery, alongside the existing password flow for the next several years. The site has to handle the case where the user has a passkey on device A but is logging in on device B. The site has to handle the case where the user has lost their passkey. The site has to communicate to the user, in language a non technical person can understand, that the passkey is the better option and the password is the legacy option. The implementation work is not negligible. The libraries (SimpleWebAuthn, Corbado) make it tractable. The UX is where the work is.
For the enterprise, the answer is to require passkeys for the highest value accounts (admin, finance, executive) and allow passwords for the rest during the transition. The passkey requirement dramatically reduces the credential phishing risk for the accounts that matter. The cost is the help desk load for the users who lose their passkey, which is non trivial in the first six months and tapers off after that.
The bottom line
Passkeys are the right answer. The migration has three edge cases that need solving. The user path: use a password manager. The site path: ship the recovery flow. The enterprise path: require passkeys for the accounts that matter. The mess is real, and it is solvable.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
