Passkeys Won on Awareness. Account Recovery Is Still the Unsolved Problem.
Passkeys have had the marketing win nearly every security technology dreams of: broad, fast consumer awareness. According to the FIDO Alliance's 2026 State of Passkeys report, as summarized by Descope, consumer awareness jumped from 75% in 2025 to 90% in 2026 — a remarkable shift for a technology that barely had mainstream name recognition three years earlier. Apple, Google, and Microsoft have all pushed passkey prompts into their core sign-in flows, and major sites from banks to social platforms now offer them as a default option.
And yet enterprise rollouts keep stalling on the same problem: what happens when someone loses the device their passkey lives on. In surveys of organizations citing specific blockers to passkey adoption, concerns about device loss and account recovery rank among the top barriers, cited by roughly a third of organizations. The technology that was supposed to kill the password has a recovery process that, in most real-world deployments, still quietly depends on one.
Why recovery is structurally different from login
A passkey is a cryptographic key pair bound to a device (or synced across a user's device ecosystem via iCloud Keychain, Google Password Manager, or similar). That binding is exactly what makes passkeys phishing-resistant — there's no shared secret to steal, because the private key never leaves the device. But it also means losing every device that held the key, or never having synced it, locks you out through no fault of bad security hygiene.
The honest industry answer, per the UK's National Cyber Security Centre, is that the FIDO Alliance and the broader industry are actively working the recovery problem, but it "isn't yet effectively accepted and established" as a solved issue. In practice, most services fall back to exactly the mechanisms passkeys exist to replace: a password reset, an SMS code, a knowledge-based question, or a support agent manually verifying identity. Every one of those fallback paths reopens the attack surface passkeys closed on the login side.
Attackers have already pivoted
This isn't theoretical. The NCSC specifically flags that attackers are shifting focus toward weaknesses in account recovery and reset requests, including phishing campaigns targeting recovery codes rather than login credentials directly. It's a predictable move: if the front door got dramatically harder to pick, attackers go looking for the spare key hidden under the mat — and right now, the recovery flow is usually exactly that. A help-desk social engineering call that convinces a support agent to reset account access, or a phished recovery code, bypasses passkey protection entirely without ever touching a passkey.
What good recovery actually looks like
The deployments that are working best share a common pattern, rather than relying on a single fallback path: multiple passkeys registered across multiple devices from the start (so losing one device doesn't mean losing access), a physical hardware security key kept as an explicit backup rather than an afterthought, and for enterprises, an administrator-mediated recovery workflow that requires out-of-band verification rather than a quick password reset email. Consumer platforms that sync passkeys across a device ecosystem — iCloud Keychain and Google Password Manager being the two largest — reduce single-device risk substantially, but they also mean your recovery posture is only as strong as your Apple ID or Google account security, which creates its own single point of failure if that account itself isn't hardened.
If you've enabled passkeys anywhere in the last year, the one concrete thing worth doing this week is registering a second passkey on a separate device, or adding a hardware security key as a backup, rather than discovering during an actual device loss that your only recovery option is a password reset flow you thought you'd retired. For IT and security teams rolling passkeys out at scale, the recovery workflow deserves the same threat-modeling attention as the login flow — right now, in most deployments, it's getting a fraction of it.