Passkeys are failing to replace passwords

That is the passkey paradox. Google reported more than 1 billion passkey authentications across over 400 million accounts by early 2024, with passkeys achieving a 93% login success rate compared with 63% for traditional authentication methods. Yet 87% of organizations still keep passwords active in their authentication stack. Only 13% say they have deployed passkeys at scale, despite 93% being somewhere on the adoption path.

The technology is not failing in the cryptographic sense. The rollout is failing in the commercial, operational, and human sense. Those are different things, although vendors prefer to blur them together.

The cleanest passkeys vs passwords security comparison makes passkeys look like the obvious winner. In actual deployments, the contest is not between two isolated login methods. It is between a polished new authentication layer and the sprawling mess of recovery processes, old devices, third-party systems, support desks, and mid-tier websites that keep passwords alive.

Passkeys win the technical argument. Passwords keep winning the infrastructure argument.

The adoption gap: enterprise ambition versus reality

The headline adoption rate is flattering because it measures intention. The deployment rate is less flattering because it measures reality.

According to research from the FIDO Alliance and HID, 93% of surveyed organizations are somewhere on the passkey adoption path. That sounds like a market tipping point until you look at the other number: only 13% have deployed passkeys at scale.

The gap between those figures is where most technology strategies go to die.

An organization can pilot passkeys for employees, enable them for a narrow group of customers, or add a passkey option beside the existing password field and still describe itself as adopting passwordless authentication. This is not necessarily dishonest. It is simply how enterprise reporting works when nobody wants to explain that the old system remains fully operational underneath the new one.

The result is a hybrid authentication stack:

• Passkeys handle some logins, usually on supported devices and platforms.
• Passwords remain available for users who have not enrolled.
• Email or SMS recovery restores access when a user loses a device.
• Help desks override the process when account recovery becomes inconvenient.
• Older applications continue to depend on passwords because rewriting them is expensive.
• Administrators maintain exceptions for contractors, subsidiaries, legacy hardware, and users outside the preferred ecosystem.

Every exception adds friction. Every fallback creates leverage for attackers.

The business case for passkeys is straightforward. Passwords create credential reuse, phishing exposure, reset costs, and a large operational burden. Only 2% of organizations rate passwords as effective, yet 87% continue to use them. That is not a vote of confidence in passwords. It is a bill for the cost of replacing them.

I have watched enough technology rollouts to know what happens next. Executives approve the security upgrade. The engineering team implements the clean path. Customer support discovers the edge cases. Compliance asks for recovery procedures. Finance asks what the migration will cost. Product teams worry about conversion rates. Within months, the supposedly obsolete password becomes the emergency exit, and emergency exits have a habit of becoming the main entrance.

Passkeys are not losing because passwords are better. They are losing because legacy systems are very good at surviving the strategy that was meant to kill them.

There is also a measurement problem. A passkey can be available without being used. It can be used without being the default. It can be the default without being the only secure route. Each stage produces a more impressive presentation than the last, while the attacker still looks for the weakest active credential flow.

That is why the phrase “passwordless” deserves suspicion. In many organizations, it means “passkeys are now available, provided the user has the right device, the service supports enrollment, the account can recover safely, and nobody encounters an exception.” Passwordless in the brochure. Password-compatible in production.

The tiered support problem: the long tail of the web is not ready

Passkey adoption is heavily concentrated at the top of the internet.

Approximately 50% to 60% of the top 100 websites support passkey authentication. That number drops to roughly 20% to 25% among the top 1,000 sites and to just 5% to 10% among the top 10,000.

This is not a minor implementation detail. It explains why users remain confused.

A person may create a passkey for a major email provider, financial platform, or device ecosystem and then encounter passwords everywhere else. The user does not experience a coherent replacement for passwords. The user experiences an irregular patchwork in which every website has its own enrollment prompt, recovery logic, and terminology.

The largest platforms have the leverage to invest in identity infrastructure, device compatibility, customer education, and support. A smaller retailer, specialist publisher, regional bank, or business software provider may not. It has to integrate passkeys into an existing identity stack while preserving every old route that customers, employees, and auditors still expect to work.

The economics are unkind. Passkeys reduce some forms of fraud and account takeover, but the benefit arrives across the ecosystem while the implementation cost lands on each individual company. A large platform can absorb that cost. A smaller site sees a migration project, uncertain enrollment, possible login disruption, and a support queue full of users asking where their password went.

Here is the market reality in plain terms:

The support gap also creates a network problem. Passkeys become more convenient as more services support them, more devices synchronize them cleanly, and more users understand how recovery works. Until that network reaches a certain density, the user still needs password habits for most of the internet.

Why would someone rebuild their mental model for authentication when the reward applies to only a minority of accounts?

This is one reason why passkeys are not popular despite their technical advantages. Users do not evaluate cryptographic resistance in isolation. They evaluate whether the new method works on the device they have today, whether it survives a lost phone, whether it works in a private browser window, whether a family member can access the account, and whether customer support understands the same vocabulary.

A system that is secure but unpredictable feels broken. Consumers are not irrational for noticing that distinction.

Industry disparities: fintech moves first, media drifts behind

Adoption does not move uniformly across industries because the cost of weak authentication does not land uniformly either.

Fintech leads with roughly 60% active passkey usage among supported users. E-commerce follows at 35%, B2B software at 28%, and media and streaming at 18%.

The pattern makes sense. Financial services have a clear economic incentive to reduce account takeover, credential stuffing, and expensive fraud operations. They also have a regulatory and reputational incentive to demonstrate stronger authentication. A compromised banking account produces a different boardroom conversation from a compromised streaming profile, even though both may begin with the same stolen password.

E-commerce sits in the middle. Retailers have substantial fraud exposure, but they also fear anything that adds friction to checkout or account access. The customer may tolerate a new authentication step when moving money. The same customer may abandon a shopping cart if the login process becomes confusing.

B2B software has a different obstacle: organizational complexity. A software provider may support passkeys for a modern employee population while still dealing with contractors, service accounts, identity providers, older browsers, and customers whose internal policies prohibit biometric authentication. The passkey itself is rarely the hard part. The permissions architecture around it is.

Media and streaming trail at roughly 18% active usage among supported users. That is hardly surprising. Many of these services optimize for low-friction access across televisions, game consoles, shared households, and devices that are awkward places to complete a modern authentication ceremony. The commercial pressure is to keep the viewer watching, not to make identity architecture elegant.

This distinction matters when someone asks, are passkeys safer than passwords? In the narrow security comparison, yes. Passkeys are designed to resist phishing because the cryptographic credential is bound to the legitimate website or application. The private key does not get typed into a fake login page. The server receives proof rather than a reusable secret.

But security value depends on where the credential is offered, how it is recovered, and whether the organization has actually removed the weaker options.

A bank that supports passkeys but permits account takeover through a lightly protected email reset has not eliminated the risk. It has created a hardened front door and left a side window open.

The security paradox: a strong login with a weak escape hatch

Passkeys address one of the oldest problems in digital security: users cannot reliably protect reusable secrets at scale.

Passwords get reused. They get phished. They appear in breached databases. They are copied into notes applications, shared with colleagues, and reset through support channels. A 2025 DBIR analysis cited in the research places stolen credentials in 88% of breaches. The exact proportion is less important than the direction of travel: attackers continue to prefer credentials because credentials are portable, cheap, and easy to monetize.

Passkeys change the economics. An attacker cannot simply collect a passkey in a phishing form because the credential is not a string that the user can reveal. The authentication ceremony checks the origin, and the cryptographic design prevents the same credential from being replayed across a different site.

That is a meaningful improvement. It is also where the industry starts congratulating itself too early.

The fallback flow can bypass the very property that made passkeys attractive. If a user loses a device and can recover the account through email or SMS, an attacker can target the email account or telephone number instead. If customer support can reset the account after a few questions, social engineering remains in play. If an administrator can disable the passkey requirement through a weak recovery process, the strongest factor becomes optional at the moment it matters most.

This is not a flaw in the FIDO2 protocol. It is a flaw in the surrounding system.

A secure authentication system must answer at least four separate questions:

1. How does the user authenticate during normal access?

Passkeys perform strongly here because they avoid reusable secrets and provide resistance to conventional phishing.

2. How does the user enroll a new device?

If enrollment relies on an already compromised session, the attacker may attach a new credential before the legitimate user notices.

3. How does the user recover the account after losing access?

Email and SMS can be useful, but they are not automatically equivalent to a phishing-resistant passkey.

4. Who can override the process?

A support agent, administrator, or identity provider may possess more practical power than the authentication factor itself.

Most adoption discussions focus on the first question because it produces the best demo. Attackers tend to focus on the other three because those are where the leverage sits.

A passkey is only as strong as the least protected route to the account. The attacker does not care which login method the product team prefers.

Organizations also face a governance problem. Eliminating passwords requires confidence that recovery, device migration, shared access, and exceptional cases will work without creating a larger support and fraud burden. Many businesses do not have that confidence. So they retain passwords as insurance.

It is expensive insurance. It is also familiar insurance, which is how bad systems become permanent.

User friction and the stubborn appeal of the familiar

The phrase “friction” is usually used by product teams to describe an extra tap. In authentication, friction means something more serious: uncertainty about whether access will survive the next device change.

A passkey may be easy to use once it exists. The trouble begins before and after that moment.

Users have to understand where the passkey is stored, whether it synchronizes across devices, how it moves from one platform to another, and what happens if the original device disappears. They may encounter different interfaces from operating systems, browsers, password managers, and websites. The terminology is not uniform. The recovery instructions are rarely written for a person who is already locked out and slightly furious.

That last condition is not theoretical. Account recovery is the point at which users stop behaving like security diagrams. They borrow a phone, use a work laptop, switch browsers, reinstall an application, or ask a family member to help. Any process that assumes a single user, a single device, and a stable ecosystem will eventually meet reality and lose.

Cross-device synchronization remains one of the central sources of friction. Users want a passkey to follow them without thinking about where it lives. Security teams want control over storage, device binding, and recovery. Platform providers want their own ecosystems to feel seamless. Those incentives overlap, but they do not align perfectly.

Migration creates another problem. Passwords are terrible security technology, but they are portable in a crude and familiar way. A user can type one into almost anything. Passkeys are safer precisely because they are less portable as plain information. That security advantage can feel like a limitation when the person is moving between devices, browsers, or account ecosystems.

The industry has not yet settled the user experience around these transitions. It has settled the cryptography. That is not the same achievement.

The practical result is a hybrid arrangement that satisfies nobody completely:

• Security teams dislike the password fallback because it preserves phishing and credential-stuffing exposure.
• Product teams dislike mandatory passkey enrollment because it can disrupt sign-in and conversion.
• Support teams dislike recovery flows that require explaining unfamiliar device behavior.
• Users dislike being told that the new secure method is easy, right before it asks them to solve an identity puzzle.
• Executives dislike paying for two systems at once, although that is exactly what the organization now operates.

This is why the passkey adoption rate in 2024 could rise sharply without producing a passwordless web. Adoption is not a binary event. It is a sequence of partial commitments, and the final commitment—removing passwords and weak recovery routes—carries the most operational risk.

What a serious rollout would have to do differently

The answer is not to abandon passkeys and return to password evangelism. That would be like rejecting modern fire suppression because the building still has a broken emergency exit.

The answer is to stop treating passkey availability as the finish line.

A credible rollout would begin with the accounts and workflows where phishing resistance has the clearest economic value. Privileged administrators, finance teams, developers with production access, and high-risk customer accounts should not be treated as interchangeable with low-impact logins. The organization should identify where stolen credentials create the greatest blast radius, then apply the strongest authentication there first.

The migration also needs explicit ownership of the fallback layer. That means mapping every route that can restore access:

• Email reset links and the security of the mailbox behind them.
• SMS recovery and the exposure created by number takeover.
• Help-desk verification procedures.
• Administrator overrides.
• Device enrollment and credential replacement.
• Sessions that remain active after a passkey is revoked.
• Third-party identity providers and federated login paths.

If a company cannot describe these routes clearly, it does not yet control its authentication system. It merely controls the happy path.

Organizations should also measure the right outcomes. Counting enrolled passkeys is useful, but insufficient. A more honest dashboard would distinguish between:

• Passkeys created and passkeys actively used.
• Accounts with passkeys and accounts with passwords fully disabled.
• Successful normal logins and successful recovery events.
• Recovery events completed without human intervention.
• Fallback methods that retain phishing exposure.
• Login failures by device, browser, and operating system.
• Support contacts caused by enrollment or migration.

The difference between enrollment and actual protection is substantial. A passkey sitting unused beside an active password does not deliver the same benefit as a passkey that replaces the password and sits behind a sound recovery process.

Product teams also need to stop pretending that every user wants the same identity architecture. A technically elegant passkey flow may work beautifully for a single-device professional and poorly for a household sharing a streaming account across a television, tablet, and phone. That does not mean the less convenient user should receive weaker security by default. It means the product has to confront the access model it actually sells.

Finally, companies need to accept that the migration will be uneven. The top 100 websites can move faster than the long tail because they have money, engineering capacity, and more control over the customer journey. Smaller sites may need managed identity providers, better platform tooling, and clearer standards before passkeys become economically routine.

The market will not be transformed by a press release claiming that passwords are obsolete. It will change when the cost of keeping passwords exceeds the cost of removing them, including the cost of fixing every recovery path that currently depends on them.

The passkey paradox is a systems problem, not a cryptography problem

Passkeys are safer than passwords in the way that a properly designed vault is safer than a note taped to a monitor. The comparison is not difficult. Passkeys offer stronger phishing resistance, eliminate reusable secrets, and deliver a markedly higher login success rate in the data cited here: 93% versus 63% for traditional authentication methods.

But the web is not a collection of isolated login screens. It is a federation of old applications, new platforms, support procedures, account migrations, device changes, and commercial compromises. Passwords persist because they are embedded in that machinery. Remove the visible password field and the underlying dependency often remains in recovery, administration, or legacy integration.

That is why 93% organizational interest has translated into only 13% deployment at scale. It is why 87% of organizations still retain passwords despite rating them effective in almost no cases. It is why passkey support falls from 50%–60% among the top 100 websites to 5%–10% among the top 10,000.

The technology is ready enough. The incentives are not. The user experience is uneven. The fallback architecture is frequently weaker than the login it protects.

Passkeys are not failing to replace passwords because they are a mirage. They are failing because the industry keeps trying to install a new lock without rebuilding the door.

And the old key is still under the mat.