Passwords persist because migration is harder than awareness. Legacy systems, limited developer capacity, and the risk of disrupting customer access push organisations toward partial adoption, even when they recognise passwords are weaker and less convenient.
Why passwords linger alongside passkeys
Passwords persist because rollout is not just a product decision, it is an ecosystem migration. Large estates still depend on legacy authentication paths, older applications, and recovery flows built around shared secrets. Even when organisations want to move, they often keep passwords as a fallback to avoid lockouts, support spikes, and customer abandonment.
The friction is operational as much as technical. Passkeys change enrollment, device trust, recovery, and help desk processes, so adoption touches application teams, identity teams, support, and product owners at once. Where one of those pieces is missing, password support remains the cheapest way to preserve continuity.
That is why a Passwordless and Passkeys Guide belongs in any serious rollout plan, because the real work is not explaining the benefit of passkeys but redesigning authentication and recovery so users can actually complete sign-in.
What keeps organisations from deleting passwords cleanly
The main blocker is that passwords are deeply embedded in application compatibility and account recovery. Many systems still assume a password exists for first login, fallback access, or step-up verification, and some third-party integrations are not ready for passkey-only sign-in. In those environments, a hard cutover can be more disruptive than the risk of keeping passwords for a while longer.
Developer capacity also matters. A passkey rollout is not a single toggle if the estate includes multiple apps, federated identity providers, and different user populations. Teams have to update sign-in journeys, test edge cases, and ensure recovery does not quietly reintroduce weaker factors. The most practical path is often incremental adoption, starting with high-value or high-risk populations first.
For workforce environments, the right reference point is the Workforce Identity Security Guide, because it ties passkeys to the surrounding controls that make password reduction sustainable: SSO, federation, account recovery, and help desk workflows.
Why password removal is slower than password criticism
People usually agree that passwords are weak. The harder part is removing the dependency without breaking business processes. Organisations often discover that one unmodernised application, one vendor portal, or one recovery exception forces passwords to remain available for the whole estate, even if most users could already use passkeys.
That creates a transitional state where security improves in some journeys but not others. Passkeys reduce phishing exposure and improve usability, but the residual password path still becomes an attack surface for password spraying, credential stuffing, and account recovery abuse. The result is uneven maturity, not failure, but it means the organisation has only partially retired the old risk.
External guidance has moved in the same direction. NIST SP 800-63 Digital Identity Guidelines is useful because it frames phishing-resistant authenticators and recovery choices as part of an identity assurance model, not just as a convenience upgrade.
Risk and Threat Considerations
Keeping passwords during a passkey transition preserves a legacy compromise path that attackers already know how to exploit. The danger is not that passkeys fail, but that password fallback, reset, and recovery flows remain easier to target than the new primary factor.
Failure mechanism: Attackers focus on the weakest surviving path, such as spraying old passwords, abusing recovery channels, or phishing users who have not yet been migrated, then using that access to bypass stronger authentication elsewhere in the same environment.
Impact: The organisation carries two authentication models at once, which increases user confusion, support burden, and the chance that a single weak exception undermines the security gains of the passkey programme.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Passwords and passkeys are both organizational-user authentication methods. |
| IA-5 — Authenticator Management | The question centers on migrating away from password authenticators and managing fallback paths. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Customer and partner sign-in migrations often keep passwords due to compatibility and recovery constraints. | |
| Recommendation — Adopt phishing-resistant authenticators for user sign-in and reduce password dependence. Control authenticator issuance, rotation, and recovery to retire passwords safely. Use stronger authenticators for external users and phase out password-only access where feasible. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The question is directly about passkeys, phishing-resistant authentication, and migration from passwords. |
| Recommendation — Use phishing-resistant authenticator guidance to design sign-in and recovery for passwordless rollout. | ||
| OWASP ASVS | V6 — Authentication | Passkeys replace password-centric authentication flows and affect fallback and recovery design. |
| Recommendation — Verify authentication and recovery flows support passwordless sign-in without weaker fallback paths. | ||
Practitioner Guidance
What to prioritise: Treat recovery, help desk, and legacy application compatibility as the first migration work, not the cleanup step. If those three areas are not ready, password retirement will stall even if the passkey experience is excellent.
What to verify: Confirm which sign-in paths still depend on passwords, which vendors cannot yet accept passkeys, and whether account recovery can be completed without silently restoring password dependence.
Decision rule: If a user population can be moved to passkeys without creating a high-friction recovery exception, migrate that population first; if not, reduce password exposure around it by tightening reset controls and narrowing fallback use.
Practitioner takeaway: Passkeys fail to displace passwords when organisations treat sign-in as the only change, the real control point is the surrounding recovery and compatibility estate.