Not usually at the beginning. Most organisations will operate a hybrid model for a long period, especially where legacy applications, device constraints, or risk-sensitive recovery flows still depend on passwords or other fallback methods. The practical goal is controlled reduction of password dependence, not an abrupt cutover.
Why This Matters for Security Teams
Passkeys are a strong step forward for customer identity because they reduce phishing, replay, and credential stuffing risk, but they do not automatically solve every login, recovery, or account-linking problem. The real decision is whether the organisation can replace password reliance without breaking sign-up conversion, supportability, or high-risk recovery journeys. Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward risk-based identity controls rather than single-control purity.
That matters because many customer IAM stacks include legacy web apps, mobile devices with uneven platform support, shared family devices, and regulated flows that still need fallback verification. When password retirement is rushed, teams often reintroduce weak recovery paths, duplicate identities, or account-lockout friction that support teams then bypass informally. NHIMG research on secrets exposure also shows how quickly weak operational practices create broader security debt when controls are introduced without end-to-end governance. In practice, many security teams encounter the weakest part of “passwordless” not at primary login, but after a recovery incident has already forced exceptions.
How It Works in Practice
The practical model is usually staged: first add passkeys as the preferred sign-in method, then reduce password dependence for normal login, and only later decide whether passwords can be removed for specific user cohorts. A customer IAM program should treat passkeys as one authentication factor in a broader assurance design, not as a universal replacement on day one. That means pairing them with strong recovery, device binding where appropriate, session risk checks, and clear fallback rules. The NIST Cybersecurity Framework 2.0 is useful here because it encourages identity controls to be tied to governance, recovery, and continuous monitoring, not just initial enrollment.
Implementation usually works best when organisations separate user segments and use different policies for each:
- New customers: offer passkeys first, with a password optional only during transition.
- Existing customers: add passkeys without forcing immediate password deletion.
- High-risk accounts: require stronger step-up checks for recovery and sensitive actions.
- Legacy channels: keep passwords only where platform or application support makes removal unsafe.
NHIMG’s guidance on secrets handling is a reminder that weak fallback design can undermine even modern authentication, because operational shortcuts often persist longer than intended. The principle is similar to the risks highlighted in Azure Key Vault privilege escalation exposure: if access pathways are not deliberately constrained, the control that was meant to reduce risk can become a new route to it. These controls tend to break down when legacy recovery flows, shared devices, or customer support override processes make it impossible to enforce a single authentication standard consistently.
Common Variations and Edge Cases
Tighter password removal often increases account-recovery complexity, requiring organisations to balance phishing resistance against support cost, accessibility, and migration risk. There is no universal standard for this yet, so best practice is evolving rather than settled.
Some businesses can move faster than others. Consumer apps with modern browser and mobile usage may eventually approach passkey-first or passwordless-by-default, while banks, healthcare portals, and multi-brand ecosystems often need hybrid support for much longer. Cross-device enrollment, passkey sync across ecosystems, and account recovery after device loss remain the main pressure points. If a platform depends on shared devices, kiosk usage, embedded webviews, or older browsers, the answer is usually not immediate password retirement but controlled reduction and segmentation.
NHIMG’s own research into secret exposure shows why change management matters: once insecure workarounds become normal, they tend to survive long after the intended control is live. For teams deciding whether to retire passwords entirely, the question is not whether passkeys are better, but whether the business can prove that enrollment, recovery, support, and fraud response are mature enough to absorb the cutover. Where that maturity is missing, the safer path is a phased hybrid model backed by policy, telemetry, and explicit exception handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and authentication are central to passkey adoption. |
| NIST SP 800-63 | AAL2 | Passkeys map well to phishing-resistant authentication assurance goals. |
| NIST AI RMF | Risk governance helps decide where passkeys can replace passwords safely. |
Target phishing-resistant sign-in for eligible users and reserve weaker methods for constrained edge cases.
