The Password Is Dying. The Passkey Is Not Winning.

Every year for the last 10 years has been the year the password was going to die. The year has not arrived. The password is still the dominant authentication mechanism. The passkey, the technology that was supposed to replace it,…

A single old steel key lying abandoned on cracked dark concrete, dim cold blue moonlight from above, deep black shadows with a single warm orange highlight catching the worn steel teeth, deep blacks and charcoal with cold blue rim light, no people no text no logos.



Every year for the last 10 years has been the year the password was going to die. The year has not arrived. The password is still the dominant authentication mechanism, the dominant cause of breaches, and the dominant friction in the user experience. The passkey, the technology that was supposed to replace the password, has been available for years, has been adopted by all the major identity providers, and is still stuck. The reasons for the stuck migration are real and structural. The fix is not a new technology. The fix becomes the work the identity industry has not done.

Passkeys are, technically, a complete success. The WebAuthn standard is solid. The FIDO2 specification is interoperable. The major platforms, Apple, Google, Microsoft, all support passkeys natively. The major identity providers, Okta, Auth0, Microsoft Entra, Ping, all support passkeys as a primary or secondary factor. The major consumer services, Google, Apple, Microsoft, PayPal, eBay, GitHub, all offer passkey sign in. The technology works. The migration is stuck for reasons that have nothing to do with the technology.

The migration is stuck because the user experience is fragmented, because the enterprise rollout is hard, because the recovery flow is unsolved, and because the password is, in many cases, good enough for the threat model the user actually has. The migration is stuck because the work that would unstick it becomes the work the identity industry has been avoiding.

The 10 year death of the password

The password was declared dead in 2014, after the 2013 Target breach and the 2014 Home Depot breach. The password was declared dead again in 2017, after the 2017 Equifax breach. The password was declared dead again in 2019, after the 2019 Collection #1 credential dump. The password was declared dead again in 2021, after the 2021 Facebook, LinkedIn, and Clubhouse credential dumps. The password was declared dead again in 2023, after the 2023 LastPass breach. The password is, in 2026, the most common authentication mechanism on the internet. The password is, in 2026, the cause of the majority of successful breaches. The password has been declared dead 5 times in 10 years and is, by every measurable metric, still alive.

The reason the password survives is that the password works, in a way the alternatives do not. The password is universal. The password is portable. The password is recoverable. The password is, in most cases, good enough for the threat model the user actually has, which is “I do not want my bank account emptied by someone who guessed my password.” The password, with a password manager, with a unique password per site, with two factor authentication, is a reasonable authentication mechanism for the threat model the user has.

What passkeys actually are

A worn bakelite telephone receiver lying off-hook on a dark steel desk, beside it a small dark glass plate showing a glowing cyan fingerprint sensor graphic, a few small scattered paper scraps in shadow, single cold blue overhead light, deep blacks with a single cold cyan accent, no people no text no logos.
The cryptographic key is bound to the device and the origin. It cannot be reused on a phishing site.

A passkey is a cryptographic key pair, generated by the device, stored in the device’s secure enclave, presented to a website through the WebAuthn API. The private key never leaves the device. The public key is registered with the website. The website, on subsequent sign in, sends a challenge to the device, the device signs the challenge with the private key, the website verifies the signature against the public key. The user authenticates with a biometric or a hardware key, the browser mediates, the user is signed in. No password is exchanged. No credential is in the page’s DOM. The cryptographic key is bound to the origin, so a phishing site cannot reuse it.

Passkeys are, in other words, the right answer to the password problem. Passkeys are phishing resistant. Passkeys are not reusable across sites. Passkeys do not leak in data breaches. Passkeys do not require memorisation. Passkeys are, by every technical measure, superior to passwords. The migration is stuck for reasons that are not technical.

Why passkeys are better

Passkeys are better than passwords in three ways. The first is phishing resistance. A password can be phished. A passkey cannot, because the passkey is bound to the origin. The phishing site cannot present a passkey challenge that the legitimate site’s passkey will sign. The user, on a phishing site, will not be prompted for the passkey. The phishing fails, by design.

The second is breach resistance. A password database can be breached. A passkey database, on the server, is a list of public keys. The public keys are not sensitive. The private keys are on the user’s device. The breach, when it happens, yields nothing the attacker can use.

The third is user experience. The user does not type a password. The user does not remember a password. The user authenticates with a biometric or a hardware key, the device does the rest. The experience is faster, easier, more secure.

The advantages are real. The advantages are not enough.

Why the migration is stuck

The migration is stuck for four reasons. The first amounts to the cross device sync problem. The passkey is generated on the device. The passkey works on the device. The passkey does not, by default, work on the user’s other devices. The user has to enrol the passkey on each device. The enrolment is a friction event. The friction, in 2026, is being addressed by the platform vendors (Apple, Google, Microsoft all sync passkeys through their account systems), but the sync is not universal, and the user, in many cases, does not trust the sync. The passkey is, in the user’s mind, the same as a password. The passkey should be on the device, not in the cloud. The mental model conflicts with the implementation.

The second amounts to the recovery problem. The user forgets the password. The user clicks “forgot password”, gets an email, resets the password. The flow is familiar, it is universal, it works. The passkey does not have a familiar recovery flow. The passkey is, in the user’s mind, the same as a device. The device breaks, the user loses the device, the user is locked out. The recovery is a support ticket. The support ticket is, in the user’s mind, worse than the email reset. The mental model is wrong, but the mental model is what the user has.

The third amounts to the enterprise problem. The enterprise has an identity provider, with thousands of users, with hundreds of applications, with a help desk that handles password resets as the dominant support request. The passkey rollout requires the enterprise to enrol every user, to support the cross device sync, to handle the recovery flow, to retrain the help desk. The enterprise, in 2026, is mostly still in the planning phase. The passkey is, for the enterprise, a multi year project that competes with other multi year projects for budget and attention.

The fourth sits as the good enough problem. The password, with a password manager, with a unique password per site, with two factor authentication, is a reasonable authentication mechanism for most users. The user, in 2026, does not have the threat model that would make the passkey’s advantages decisive. The passkey is better, but the passkey is not 10x better. The user, asked to switch, asks “why.” The answer is “phishing resistance.” The user, who has not been phished, does not feel the urgency.

The cross device sync problem in detail

The cross device sync becomes the user experience problem that the passkey industry has been trying to solve since 2022. The problem is that the passkey is generated on one device, the passkey is bound to that device, and the passkey does not, by default, work on the user’s other devices. The user has a phone, a laptop, a tablet, a work laptop, a personal laptop. The user has passkeys on some of them. The user does not have passkeys on all of them. The user, on the device without the passkey, falls back to the password. The fallback defeats the purpose.

The platform vendors have tried to solve this. Apple syncs passkeys through iCloud Keychain. Google syncs through Google Password Manager. Microsoft syncs through Microsoft Account. The sync is encrypted. The sync is, in theory, secure. The sync is also, in the user’s mind, the same as a password manager in the cloud. The user, who has been trained not to trust cloud password managers, does not trust the cloud passkey sync. The training is wrong, but the training is what the user has.

The honest answer to the cross device problem is hardware keys. A YubiKey or similar, carried on the person, works on any device with a USB port. The honest answer is, however, also expensive, also friction, also unfamiliar. The honest answer is not what the user is going to do.

The recovery problem in detail

The recovery problem runs as the user experience problem that the passkey industry has not solved at all. The user loses the phone. The user gets a new phone. The user wants to sign in to the bank. The passkey is on the lost phone. The new phone has no passkey. The user is locked out.

The recovery flow, in the platforms that have it, is to use another device. The user has a laptop. The laptop has the passkey. The user signs in on the laptop, enrols a new passkey on the new phone. The flow is, in many cases, workable. The flow is, however, also unfamiliar. The user, who has been trained that the recovery sits as the email link, does not know that the recovery stands as the laptop. The user calls the support line. The support line is, in many cases, not trained on the passkey flow. The user is told to reset the password, which means the user is back to the password, which means the passkey rollout is not real.

The enterprise problem in detail

The enterprise problem sits as the organisational problem that the passkey industry has not addressed. The enterprise has an identity provider. The enterprise has thousands of users. The enterprise has hundreds of applications. The enterprise has a help desk. The passkey rollout requires the enterprise to do all of the following. Enrol every user. Support the cross device sync. Handle the recovery flow. Retrain the help desk. Update the help desk knowledge base. Update the user documentation. Update the security awareness training. Update the incident response runbook. Update the audit response. Update the regulator response.

Each of these is, individually, a project. Together, they are a multi year program. The program competes with other multi year programs for budget and attention. The program, in most enterprises in 2026, is in the planning phase. The program, in a small number of enterprises, is in the early rollout phase. The program, in no enterprise, is in the steady state phase.

What would actually unstick the migration

The migration will unstick when the work that unsticks it is done. The work is not technical. The work is organisational. The work is, in the consumer space, the platform vendors making the cross device sync as trusted as the user’s iCloud or Google account. The work is, in the enterprise space, the identity providers making the rollout a turnkey program, with the enrolment, the recovery, the help desk, the documentation, all provided as a service. The work is, in the security awareness space, the industry telling the truth about the password, the passkey, and the threat model, so the user understands why the switch is worth the effort.

The migration will also unstick when the threat model changes. The day the user is phished, the user understands. The day the user’s bank account is emptied, the user understands. The day the user is locked out of the account, the user understands. The migration, in other words, is partly a function of the threat. The threat, in 2026, is real. The threat, in 2026, is not yet at the level that compels the migration.

The migration will also unstick when the password becomes untenable. The day the password is no longer accepted, the user switches. The day the password is not an option, the user has no choice. The major platforms, Apple, Google, Microsoft, are moving in this direction. Apple, in particular, has been the most aggressive, with the 2024 announcement that passkeys would be the default for new Apple ID accounts. The direction is right. The pace is slow.

The bottom line

The password is dying. The password is dying slowly. The passkey amounts to the right answer. The passkey is stuck. The migration is stuck because the user experience is fragmented, because the enterprise rollout is hard, because the recovery flow is unsolved, and because the password is, in many cases, good enough.

The fix serves as the work the identity industry has been avoiding. The fix stands as the cross device sync, made trustworthy. The fix serves as the recovery flow, made familiar. The fix stands as the enterprise rollout, made turnkey. The fix becomes the security awareness, made honest. The fix becomes the work. The work is not technical. The work is organisational. The work is, in other words, the work the industry is least equipped to do. The migration will happen. The migration will be slow. The migration will, in 2026, be one of the largest security projects in the industry, and it will not be finished by the end of the year.


Sources & Further Reading

All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.

Spotted an error? Email the editor. Corrections are issued with a visible correction note.

Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.

Continue reading