Why Passkeys Won't Eliminate Passwords Any Time Soon

I want to be clear about where I'm standing before I start listing problems: passkeys are the most significant improvement in consumer authentication in twenty years. Phishing resistance as a structural property rather than a training exercise. No shared secret to breach. No reuse across sites. If you can deploy them, deploy them.

And the password field will still be on your login page in 2032.

Not because the technology is deficient, and not because enterprises are slow. Because the set of situations that authentication has to cover is much wider than the set of situations passkeys cover well, and the gap is populated by real people in real jobs. The honest version of the passkey roadmap isn't "eliminate passwords." It's "make passwords irrelevant for 90% of logins while keeping a functioning fallback for the other 10%" — and being clear-eyed about that changes what you build.

Here's the 10%.

The shared workstation

A hospital ward has four computers and thirty-eight nurses across three shifts. A factory floor has a terminal at each station and a hundred workers on rotation. A retail store has two point-of-sale machines and a staff roster that changes weekly.

Passkeys are designed around a device belonging to a person. The credential lives in the platform keychain of this laptop or this phone. In these environments the machine belongs to the location, and the people are transient.

The workarounds each have a real problem:

Phone-based passkey with cross-device authentication (the QR/hybrid flow). Works technically. But nurses in many wards can't carry personal phones onto the floor; factory floors often prohibit them for safety; and the flow takes 15–20 seconds versus about 4 seconds for a badge tap. When you're logging in forty times a shift, that difference is an hour a week, and the staff will find a way around it — including leaving a session open on the shared machine, which is a worse outcome than the password.

A hardware key per person. Genuinely good security. It's another physical object to issue, track, and replace, at maybe $25–50 each plus lifecycle cost, and the loss rate in a high-turnover, physically demanding environment is not small.

Passkeys on the shared device itself. Now the credential is available to whoever is standing there, which defeats the point.

What these environments actually converge on is badge-plus-PIN, or a fast-user-switching model with a short PIN — which is to say, something in the password family, chosen because the constraint is seconds per login on hardware shared by dozens of people, and that constraint isn't going away.

The call centre and the assisted channel

An agent takes a call. The customer needs to be verified. The customer is on a landline, or a mobile they can't use simultaneously, or is elderly, or is calling precisely because they've lost the device their passkey was on.

Passkeys require the user to interact with an authenticator. In an assisted channel, there is often no channel to the authenticator at all. The agent's tools are: knowledge-based verification, a one-time code to a registered channel, or an identity document check. Every one of those is either password-family or falls back to the recovery problem.

This isn't a passkey deficiency; it's a mismatch. Passkeys authenticate a user to a service, and the call centre needs to authenticate a user to a human intermediary. The latter is a different problem, and it's one that a great many regulated industries are legally required to solve.

The legacy application nobody can touch

An enterprise runs an application built in 2009. It authenticates against LDAP with a bind operation. The vendor that made it was acquired twice and no longer supports it. The source is in a repository nobody has credentials to. It processes something load-bearing — payroll, claims, dispatch.

Passkeys require a WebAuthn-capable client and a relying party that implements the ceremonies. This application can do neither, and modifying it isn't on the table.

The bridges exist and each is partial. Put the app behind an identity-aware proxy that authenticates with passkeys and forwards a header — works if the app can be taught to trust a header, which many can't. Front it with a modern IdP and use a password vault to inject credentials — a real, widely-deployed pattern, and note what's inside it: a password, stored, injected. The user experience is passwordless; the system still has a password in it. Federate via a protocol the app understands — fine if it speaks SAML or Kerberos, and many speak neither.

Every large enterprise has dozens of these. Their aggregate weight is the single biggest reason "we're going passwordless" means "for the 200 applications behind our IdP, not the 700 in the estate."

The bootstrap problem

A new employee, day one, no corporate device yet, no credential enrolled. Or a consumer signing up on a borrowed laptop. Or someone whose phone is being replaced.

To register a passkey, the user must already be authenticated — otherwise anyone could enrol a credential against any account. So enrolment requires a pre-existing credential, and the very first one has to come from somewhere.

That somewhere is an enrolment secret: a one-time code, an activation link, a temporary password, an in-person verification. Which means the security of your passkey deployment is capped by the security of your enrolment channel, and that channel is almost always email or a temporary password. An attacker who intercepts a new employee's activation link enrols their own passkey and now holds a phishing-resistant credential for someone else's account — with the added irony that it's harder to detect and harder to revoke than a stolen password would have been.

This is why enrolment deserves at least as much design attention as authentication, and why "we're passwordless" is not true of a system whose credentials are bootstrapped by emailed links.

Recovery, which is the whole problem

If the passkey is the credential and the device is gone, every recovery path you build becomes the real security boundary — and the paths available are: email a link, SMS a code, use a second passkey (which most users don't have), use printed codes (which most users lose), verify an identity document (which costs money and excludes people), or talk to a human (which is socially engineerable).

Look at that list and notice that the two most-used options are email and SMS, both of which are exactly the phishable, interceptable channels that passkeys were adopted to escape. Your account's security is min(passkey, recovery), and for most consumer deployments the second term is an emailed link.

This deserves its own treatment and has it. The relevance here is narrower: the most common answer to passkey recovery is a password reset, because a password is a credential you can re-establish over a channel, and a private key in a Secure Enclave is not. As long as recovery is the unsolved half, the password stays in the schema.

Regulatory and contractual inertia

A compliance framework says "passwords must be rotated every 90 days." A customer's security questionnaire asks about your password complexity policy. A regulation names specific authentication factors. A contract signed in 2021 specifies controls in terms that assume a password exists.

None of this is a technical constraint and all of it is real. Auditors work from control frameworks that update on multi-year cycles, and a control that says "N/A, we use passkeys" requires an auditor comfortable making that judgment. Some are. Many will ask you to demonstrate an equivalent control, and the cheapest way to satisfy them is to keep the password infrastructure alive and configured strictly.

This is the least intellectually satisfying item on the list and one of the most decisive in practice.

Ecosystem dependency and the parts still settling

The remaining friction is mundane but persistent:

Synced passkeys live in someone else's account. iCloud Keychain, Google Password Manager, or a third-party manager. That's mostly good — those platforms have invested heavily in security and recovery — but it means your users' access to your service depends on a vendor relationship you can't see into, and a user locked out of their Google account is locked out of you, arriving at your support queue with a problem whose cause is invisible to you.

Cross-ecosystem movement is still awkward. A user with an iPhone and a Windows desktop has a genuinely worse experience than a user inside one ecosystem. Credential Exchange Protocol work is addressing portability between managers, and it's improving, but "improving" is the operative word for the next few years.

Enterprise management is immature. An organization wants to know which credentials exist, on which devices, to require device-bound credentials for privileged roles, and to revoke on offboarding. The primitives for this — attestation, BE/BS flags, device-bound requirements — exist but the management tooling around them is thinner than the equivalent for certificates or passwords, and syncable-by-default credentials are in tension with "we need to know where the credential is."

Browser and platform inconsistency at the margins. The common path is solid now. Conditional mediation, cross-device flows, credential management UIs, and error reporting still differ enough that support teams need per-platform playbooks.

What to actually build

If the password isn't going away, the productive question is what to do about it. Four things, and they're a different plan than "migrate to passkeys."

Make passkeys the primary path and measure their share. Not an option buried in settings — the default, promoted at the right moments, with conditional mediation so it's the fastest way in. The number to report is the percentage of authentications that used a passkey, and driving that from 0% to 85% is a large security win even with the password still present.

Keep the password infrastructure and keep it good. Since it's staying, it should be strong: modern hashing with sane parameters, breach-corpus checking, no forced rotation, no composition rules, generous length limits. A well-run password fallback is a completely different risk than a neglected one — and the neglect is the actual danger, because the fallback is the path an attacker will choose.

Treat the fallback as the security boundary and instrument it accordingly. If most users have passkeys, then a password login for a passkey-enrolled account is anomalous — a strong risk signal that deserves a challenge, a notification, or a constrained session. This is the highest-leverage idea in this article: the presence of a strong credential makes use of the weak one informative, and almost nobody exploits that.

Segment by population rather than migrating uniformly. Office workers with company laptops: passkeys, aggressively. Privileged administrators: device-bound passkeys or hardware keys, mandatory. Shared-workstation staff: badge-and-PIN, and stop trying to force the passkey. Assisted channels: a designed verification process that doesn't pretend to be authentication. Legacy applications: an inventory, a proxy where possible, and an honest note about the rest.

The reframe

"Passwordless" as a destination sets up a binary that produces bad decisions — either declaring victory while an emailed reset link remains the real credential, or deferring passkeys because they can't cover every case.

The useful goal is narrower and achievable: make the password unnecessary for the overwhelming majority of authentications, and make its use rare enough to be a signal. That's worth a great deal, it's available now, and it's honest about the ward with four computers and thirty-eight nurses — where the answer isn't a passkey, and pretending otherwise just means the session stays logged in all shift.