Passkeys Have Won the Argument and Are Still Losing the Rollout

Passkeys — the consumer-facing name for FIDO2/WebAuthn credentials — resolved the technical argument about password replacement some time ago. The credential never leaves the authenticator, there is no shared secret for a server breach to leak, and because the browser enforces the origin binding, a convincing phishing page cannot collect anything usable. Every major operating system, browser, and password manager now supports them, and large consumer platforms have rolled them out to hundreds of millions of accounts. On the security merits the case is closed. Adoption tells a more complicated story, because the industry replaced a mechanism users understood badly with one they understand differently. A password is portable, shareable, and writable on paper — properties that are security failures and usability features simultaneously. A passkey is bound to an authenticator and synced through a platform account, which means the user's mental model has to shift from "I know my password" to "my devices hold my identity." Support desks report that the resulting confusion concentrates in exactly two places: users who have credentials in multiple ecosystems and cannot remember which one holds the passkey for a given site, and users who change platforms and expect their credentials to follow. Account recovery remains the genuinely unsolved problem, and it is where most of the residual risk now sits. If phishing the credential is impossible, the attacker's rational move is to attack the recovery path instead — and for most services that path still terminates in an SMS code, an email link, or a human support agent who can be socially engineered. A service that deploys passkeys without hardening recovery has not removed the vulnerability; it has relocated it to the weakest remaining channel, which is often the one with the least engineering attention. Security researchers have been consistent on this point: passkey rollouts should be evaluated on their recovery design, not their login flow. The migration pattern that appears to work is not replacement but staged removal of the fallback. Services add passkeys alongside passwords, wait for a substantial share of active users to enroll, then begin restricting the password path — first by requiring step-up verification, eventually by removing it for enrolled accounts. It is slower than a clean cutover and it means running both systems for years. It also avoids the failure mode that has stalled other authentication transitions, where a hard cutover locks out the segment of users least able to complete the migration and the resulting support load forces a rollback.