Should organisations replace passwords everywhere with passkeys immediately?

No. Organisations should prioritise high-volume, high-friction consumer flows first, then expand where device support and recovery controls are mature. Immediate replacement can create support gaps if the fallback model is weak. A staged rollout lets teams verify assurance, usability, and operational readiness before eliminating passwords more broadly.

Why This Matters for Security Teams

Passwords and passkeys solve different problems, and replacing one with the other is not a universal security upgrade. Passkeys can reduce phishing, credential stuffing, and help desk burden, but a rushed cutoff can weaken recovery, create lockout risk, and expose gaps in device trust. Current guidance suggests prioritising high-friction journeys first, then expanding where assurance, device posture, and recovery are strong enough to sustain the change.

This is especially important for organisations that already struggle with identity sprawl, inconsistent authentication policies, and weak offboarding. NHI Mgmt Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, a reminder that identity controls fail most often at lifecycle boundaries, not at login alone. The same operational reality applies to user authentication. If fallback methods are unmanaged, the weakest path becomes the real control.

Teams should align rollout decisions with NIST Cybersecurity Framework 2.0 and the identity assurance principles in NIST Cybersecurity Framework 2.0, then test recovery flows as carefully as primary sign-in. In practice, many security teams discover their real authentication risk only after a lockout, fraud event, or support surge exposes how brittle the fallback model was.

How It Works in Practice

A staged passkey rollout usually starts with consumer-facing, high-volume journeys where phishing resistance and reduced password resets deliver immediate value. That means sign-in, checkout, account recovery, and other flows with mature device coverage and relatively simple recovery rules. Internal and privileged workflows should generally follow later, after the organisation has validated device enrollment, session assurance, and exception handling.

Security teams should treat passkeys as part of a broader identity architecture, not a one-line replacement for passwords. A practical deployment checks three things first: device support across operating systems and browsers, recovery methods that do not reintroduce weak secrets, and policy controls that distinguish managed devices from unmanaged ones. Where authentication is tied to NIST Cybersecurity Framework 2.0, the focus should be on access assurance, response readiness, and continuous improvement rather than a single control swap.

For organisations that also operate machine identities, the lesson is familiar. NHI Mgmt Group’s New York Times breach analysis shows how identity failures often become operational failures when the fallback or recovery path is weaker than the primary control. The same dynamic can affect passkeys if password recovery remains broad, manual, or inconsistent. Teams should also review their New York Times breach lessons alongside their user support model, because help desk processes often become the hidden bypass.

• Start with accounts that generate the most password resets or phishing exposure.
• Use step-up checks for sensitive actions rather than assuming passkeys alone are enough.
• Set recovery rules that preserve assurance, including device re-enrollment and identity proofing.
• Measure lockouts, support calls, and fallback usage before scaling to broader populations.

These controls tend to break down when organisations support large BYOD populations with inconsistent device posture, because recovery paths and local platform features vary too widely.

Common Variations and Edge Cases

Tighter authentication controls often increase recovery overhead, requiring organisations to balance phishing resistance against support complexity and user access continuity. That tradeoff is manageable in well-controlled environments, but it becomes harder in mixed fleets, regulated environments, and globally distributed workforces.

Best practice is evolving for accounts that cannot tolerate lockout, such as emergency access, executive access, shared operational roles, or externally managed contractors. In those cases, current guidance suggests retaining a limited fallback path with strong governance rather than forcing immediate password removal. The fallback should be narrower than the primary path, not broader, and should be monitored as a privileged action.

There is also no universal standard for when passwords should be eliminated entirely. Some organisations will keep them as a transitional recovery method; others will remove them from everyday use but retain them for exceptional break-glass scenarios. The right choice depends on device assurance, identity proofing maturity, and whether the organisation can revoke or re-bind credentials quickly after a compromise. When recovery depends on weak knowledge factors, the programme is only partially passkey-enabled.

For a useful analogy, NHI teams have learned from the New York Times breach that the control is only as strong as the recovery path around it. Security leaders should apply the same discipline to user authentication, while keeping one eye on policy models such as NIST Cybersecurity Framework 2.0 and the operational realities of migration. The most common failure mode is not the passkey itself, but the organisation’s inability to retire passwords without creating an unsafe exception path.

Related resources from NHI Mgmt Group

• Should organisations still use one-time passwords for MFA?
• Why do passkeys reduce phishing risk compared with passwords?
• When should organisations require step-up verification for access?
• How can organisations reduce authentication risk for both users and NHIs?