Passkeys actually work. Then, why is adoption still terrible?

The cryptography is elegant, the UX is mostly fine, the standard is finalized — and rollout is still crawling. The reasons are more interesting than "people resist change."

Passkeys are, technically, the best answer we currently have to the phishing and credential-theft problem. And, i don't say this often, but it's not marketing. It's a structural property of how they work. And yet if you look at actual adoption across the services you use daily, most of them either don't offer passkeys or bury the option somewhere you'd only find on purpose. I want to talk about why, because the reasons are genuinely more interesting than the usual hand-wave about user resistance.

First, the part that's actually elegant

A passkey is a public-private key pair. The private key never leaves your device. When you log in, the service sends a challenge, your device signs it with the private key, and the service verifies the signature with the public key it stored at registration.

Notice what's absent from that flow: there is no shared secret. Nothing transmitted that an attacker could capture and replay. Nothing stored on the server that's worth stealing — a database of public keys is not a breach payload in any meaningful sense, because public keys are, by definition, fine to be public.

And the property that matters most: the signature, is cryptographically bound to the origin, meaning the actual domain.

A phishing site on a lookalike domain cannot produce a valid signature no matter how perfect its clone of the login page is, because the browser won't sign a challenge for the wrong origin. This is what "phishing-resistant" actually means, and it's why passkeys break the adversary-in-the-middle proxy attacks that walk straight past traditional MFA. The human doesn't have to notice the domain is wrong. The cryptography notices for them.

That's genuinely lovely engineering. So why is rollout so slow?

Reason one: account recovery is the actual hard problem

This is the big one and it gets nowhere near enough discussion. If your authentication is a private key on your device, what happens when you lose the device?

Every answer to that question reintroduces risk.

Sync passkeys across a cloud provider's keychain — now your provider account is a single point of failure. Fall back to email or SMS recovery — congratulations, your phishing-resistant authentication now has a phishing-vulnerable back door, and attackers will simply target the recovery path, because attackers always target the weakest available path. Require a second registered device — better security, meaningfully worse usability, and a support burden for anyone who doesn't have a spare device.

There is no clean answer here. Every deployment picks a tradeoff.

Reason two: the enterprise migration is genuinely expensive

For an organization with an established identity stack, adding passkeys isn't a toggle. It's touching the identity provider, every application integrated with it, the account recovery workflow, the help desk runbooks, the onboarding process, and the device management policy — because passkeys live on devices, which means device lifecycle and authentication lifecycle become coupled in ways they previously weren't.

Then there's the long tail: the legacy application that only speaks SAML in a specific way, the vendor portal that hasn't updated its auth in six years, the machine-to-machine flows that don't have a human to present a passkey at all. You end up running both systems in parallel for a long transition period, and during that period your security posture is defined by the weaker path, because attackers get to choose which path to attack.

Reason three: the UX is fine, but "fine" isn't the bar for a change this fundamental

Passkey UX has improved a lot. It's still inconsistent across platforms, browsers, and password managers in ways that produce exactly the kind of small confusion that kills adoption. The terminology hasn't settled — users encounter "passkey," "security key," "device sign-in," and "biometric login" and reasonably assume these are four things. Cross-ecosystem flows still have rough edges.

None of these are fatal. Collectively they're enough friction that a user who hits one confusing prompt clicks "use password instead," and that fallback option existing at all — which it must, during transition — means the friction is optional in exactly the way that makes it lose.

What this means practically

If you're deciding for an organization: prioritize passkeys for high-value accounts first — admins, anyone with production access, finance. That's where the phishing-resistance property pays for the migration cost most clearly, and it's a small enough population that the recovery-process problem is manageable to handle carefully.

Design the recovery path with the same seriousness as the authentication path, because it is an authentication path and it will be the one attacked. An SMS fallback on an otherwise phishing-resistant account is a phishing-vulnerable account with extra steps.

And be honest in the rollout messaging about what changes. "It's easier" is a weak pitch that sets up disappointment at the first rough prompt. "This one specifically cannot be phished, which is why we're doing it" is truer and lands better with people who've sat through five years of security training.

The part that's a people problem wearing a technical costume

Passkey adoption isn't blocked on cryptography, which was solved. It's blocked on recovery design, migration budget, and getting a large number of humans to change a habit they've had since they got their first email address. Those are organizational problems, and organizational problems don't get fixed by the standard being good. They get fixed by someone specific deciding it's worth the cost and owning the rollout, which is a much less exciting sentence than "the cryptography is elegant" but a considerably more predictive one.