Passkeys Fail Because UX Came Last

The signal: A viral HN thread argues passkeys failed to catch on because the engineers who designed them never tested the concept against how normal humans actually think about “logging in.”

Why it matters: If you’re building auth into a product, passkeys are the industry’s official answer to password fatigue and phishing, but adoption is stalling because the mental model doesn’t match reality. Users don’t know what “device syncing” means, don’t understand why a passkey created on their laptop doesn’t work on a friend’s computer, and genuinely panic when they lose a phone with no clear recovery path. That gap isn’t a marketing problem — it’s a design failure with real support-ticket volume and churn attached to it for anyone shipping consumer software. Builders who dismiss this thread as engineer griping will keep watching passkey adoption flatline while quietly blaming users instead of the flow they shipped.

Does this mean I should rip passkeys out of my app?

No — the fix isn’t abandoning passkeys, it’s stopping the habit of treating them as a drop-in password replacement. Passkeys work when they’re framed as “this device remembers you,” not as an abstract cryptographic credential the user is expected to manage across five devices and two operating systems. The failure mode is onboarding copy that talks about “platform authenticators” and “synced credentials” instead of showing, concretely, what happens the moment someone gets a new phone or logs in from a borrowed browser. Teams that ship passkeys successfully treat recovery and cross-device handoff as the primary design problem, not an edge case bolted on after the security review sign-off. Get that flow wrong and you don’t just lose a login — you lose a user who now associates your product with getting locked out.

The pattern I’m watching: This is the same story as 2FA, SSO, and even crypto wallet onboarding — security engineers solve the cryptography and quietly assume the interaction design will sort itself out downstream. It never does, and the cost lands on support teams and conversion funnels months after launch, long after the people who wrote the spec have moved to the next feature.

What I’d do with this: If you’re implementing passkeys, budget real user research time for the “I got a new phone” and “I’m on a shared computer” flows before you write a line of WebAuthn integration code. Write your fallback and account-recovery UX first, then bolt the FIDO2 implementation onto it — not the reverse, which is how most teams currently ship it.

Key takeaways

• Passkeys are cryptographically sound but the consumer mental model for device syncing and recovery was never seriously designed.
• Auth failures in production are almost always UX failures dressed up as security failures.
• Teams shipping passkeys should design the “lost device” and “new device” recovery flows before writing any authentication code.