Keep them during transition periods, for customer segments that are not yet passkey-ready, and wherever recovery assurance is still being proven. Hybrid access is a bridge, not the destination, but it prevents avoidable lockout and abandonment.
Why passwords and MFA still have a role alongside passkeys
Hybrid authentication is appropriate when the passkey rollout is incomplete, when certain customer segments cannot yet use passkeys reliably, or when recovery paths are still being tested. In those cases, passwords and MFA act as continuity controls. They reduce login failure, preserve account access during migration, and give support teams a fallback while passkey adoption matures.
That bridge matters because authentication change is not only a technology decision, it is a user-experience and operational-assurance decision. Organisations need to know who can sign in, how they recover access after device loss, and whether they can support mixed populations without creating avoidable abandonment or help-desk load.
Passkeys are strongest when the full journey, sign-in, device trust, and recovery, is ready for them. Until then, a mixed model can be safer than forcing a premature cutover that strands legitimate users. The key is to treat passwords and MFA as transitional controls with a clear retirement plan, not as an indefinite parallel path.
Where the hybrid model becomes a necessary bridge
The most common reason to keep passwords and MFA is population diversity. Some customers will still be on devices, browsers, or account recovery flows that are not ready for passkeys, and some environments still need step-up access patterns that support more than one authenticator type.
Recovery is the other pressure point. If a passkey is lost, untrusted, or locked to an unavailable device, the organisation needs a proven way to re-establish access without weakening the account. That usually means maintaining alternate sign-in or recovery methods until the passkey recovery process has enough operational evidence behind it.
Passkey rollout also tends to be uneven across channels. Web, mobile, support desk, and federated sign-in can mature at different speeds, so the right answer is often to keep a fallback where the user journey is still incomplete rather than force a single authenticator everywhere at once. For implementation guidance, Workforce Identity Security Guide covers the surrounding sign-in and recovery controls that make a staged transition workable.
What changes once passkeys are the default
Once passkeys are broadly available and recovery is reliable, passwords should stop being the primary path because they restore the risks passkeys are meant to reduce: reuse, phishing, credential stuffing, and support-driven reset abuse. At that stage, keeping passwords alive by default usually creates more exposure than value.
Hybrid access should therefore be time-bound and segment-specific. Use it where it protects real users during migration, then narrow it as passkey enrollment, device coverage, and recovery success improve. The objective is not to keep every old method available forever, but to move users onto the strongest method they can actually sustain.
That is why implementation should track whether the fallback is still serving a genuine operational need or simply persisting by inertia. If the majority of a segment can use passkeys and the remaining exceptions are supportable through controlled recovery, the fallback should start to shrink, not expand.
Risk and Threat Considerations
Keeping passwords and MFA alongside passkeys extends the attack surface if the fallback methods are poorly governed. The main risk is that a transitional control becomes a permanent bypass, especially where recovery, support overrides, or legacy enrolment paths are easier to attack than the passkey flow itself.
Failure mechanism: Attackers target the weakest available sign-in path, such as password reuse, phishing, mfa fatigue, or help-desk-assisted reset, and then use that path to bypass the stronger passkey control. If fallback methods are not tightly scoped, the organisation can unintentionally preserve the very abuse patterns passkeys were meant to remove.
Impact: Account takeover risk remains materially higher than it should be, and the organisation may also create false confidence in the passkey programme. At scale, that can translate into support fraud, wider user lockout during migration mistakes, and a longer-lived mixed environment than leadership expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys, phishing resistance, and AAL-based migration choices are central to sign-in assurance. |
| Recommendation — Use phishing-resistant authenticators and recovery aligned to the required assurance level. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Retained passwords and MFA are authenticator lifecycle controls during transition and recovery. |
| IA-2 — Identification and Authentication (Organizational Users) | The question concerns how users authenticate while the organisation transitions methods. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Customer and external-user sign-in segments may need hybrid methods during rollout. | |
| Recommendation — Manage fallback authenticators with tight lifecycle controls and timely revocation. Require stronger authentication for users as passkey coverage expands. Apply authentication controls proportionate to external-user rollout readiness. | ||
Practitioner Guidance
What to verify: Confirm that every retained password or MFA path exists for a specific user segment, recovery need, or migration dependency. If you cannot name the segment or the recovery condition, the fallback is probably legacy debt rather than a necessary bridge.
Decision rule: If a user can complete sign-in and recovery with passkeys, remove the fallback from that population first. If recovery is not yet proven, keep the fallback, but place it behind stronger controls, tighter monitoring, and a defined retirement date.
What good looks like: Most users sign in with passkeys, exceptions are small and explainable, and support has a tested recovery process that does not depend on weak manual overrides. The hybrid state should shrink as assurance improves, not drift into a permanent exception model.
Practitioner takeaway: Keep passwords and MFA only where they materially reduce migration or recovery risk, and remove them as soon as passkey coverage and recovery assurance are genuinely dependable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org