Passkeys mostly work. Almost nobody uses them.

Passkeys are public-key authentication, delivered through your phone, with biometric unlock at the device level. The standard is FIDO2 and the browser side is WebAuthn. Apple shipped polished UX in 2022. Google followed within months. Microsoft was already there. Every major browser supports them. Every major password manager syncs them. The underlying cryptography is unbroken.

Most people still log in with a password and an SMS code.

This is one of those gaps between technical readiness and real use that gets papered over with industry "adoption is growing" press releases. Why is adoption still flat? What would change it?

What passkeys actually are

A passkey is a public-private key pair stored on your device. The public key is registered with the service you're logging into. The private key never leaves the device. When you log in, the service sends a challenge, the device signs it with the private key (after biometric unlock), and the signed challenge is returned. The service verifies the signature against the public key it has on file.

There is no shared secret. There is nothing to phish, because there's nothing to enter into a fake login page. There is no password to reuse across sites, because there is no password.

Apple syncs the private key across your iCloud devices. Google syncs across your Android devices. 1Password and Bitwarden sync across whatever you log into. Cross-ecosystem flow exists too: scan a QR code on your phone from a Windows laptop, the phone authenticates over Bluetooth.

On paper, this is the password replacement the industry has been drafting since the first FIDO specification in 2013.

What is blocking adoption

Five things, in roughly descending order of how often they come up.

No central pressure. No major service has gone passkey-only. As long as users can still log in with a password, they will. Migrations happen when the old option is removed, not when the new option is offered. Banks, governments, healthcare portals all still accept passwords. The market hasn't been pushed.

Account recovery is the failure mode. If you lose your phone and your iCloud account in the same incident, you might lose your passkeys. Most services that support passkeys still maintain a password fallback or a recovery email exactly because of this. The user-facing message is mixed. The new method is also more dependent on a different account that itself has weaker auth. People notice.

The cross-platform handoff is not yet seamless. Logging into a Windows machine using an Android phone via Bluetooth works, but the UX is two steps more friction than typing a password. Each platform's flow assumes you're using the same ecosystem end-to-end. The two-ecosystem case is technically supported and practically unpleasant.

Password muscle memory. Users have entered passwords ten thousand times. The new flow asks them to look at their phone, approve a prompt, and trust that it worked. The cognitive load of the new method is lower in the long run and higher in the moment. People avoid the moment.

The service-side incentive is weak. A site that adds passkey support does not see immediate signup conversion gains. The downstream benefit is fewer support tickets and lower fraud, both invisible to the team building the login flow. So passkey support tends to ship behind other features, and even when it ships it is not the default.

What would actually move the needle

We can think of three things, in order of how much they would change.

One major service goes passkey-first. Not passkey-only. Passkey-first, where the password option is hidden behind a "more options" link, and the default flow is a passkey enrollment. If Google or Apple did this for their own accounts, competitive pressure would push the rest of the consumer web to match. Google and Apple have both published developer guidance encouraging services to adopt passkeys. Neither has made passkeys the default for their own consumer accounts.

Better account recovery. Specifically, multi-device passkey recovery that doesn't depend on a single platform account. The right shape is a recovery key the user prints and stores, plus optional trusted-contact recovery. Apple has a version of the first. The industry needs an interoperable version of both.

Browser-default enrollment. When you create an account anywhere, the browser asks "save a passkey for this site?" the way it already asks "save the password?" today. This is technically possible. The slow part is convincing every browser to ship the prompt the same way. Chrome, dominant on the desktop, has the leverage to move the default. It has also been more cautious about shipping one than Safari or Firefox.

Why the curve stays flat

Passkeys are technically ready. They are not socially ready. Meanwhile press releases will keep counting millions of enrolled passkeys, many of them used once and never again, and users will keep entering SMS codes that NIST SP 800-63B already classifies as a restricted authenticator.

Readers who want to move ahead of the platforms can enrol passkeys on the accounts whose compromise would hurt most: primary email, password manager, the bank app if it supports it, GitHub, the Apple or Google account itself. There is no need to switch everything at once. The rest will come along when the platforms force it.

The technology is ready years before the public is. The public moves when the friction of the old method exceeds the friction of the new one. Three years ago that day was further off than it is now. It is still not here.