Teams should govern the transition as a lifecycle issue, with explicit ownership for exceptions, recovery methods, offboarding, and review of any remaining passwords. The goal is to control the mixed state until passwordless becomes the default, not to treat coexistence as an end state.
Why mixed password and passkey access has to be governed as one transition state
Mixed authentication is not just a UX problem, it is an access-governance problem. When passkeys and passwords coexist, teams need one policy for enrollment, recovery, exception handling, and retirement of legacy methods. Otherwise the weaker path becomes the durable one, and the organisation loses visibility into which accounts are truly phishing-resistant.
The practical question is not whether passkeys are better, but how to keep the remaining password path from becoming an uncontrolled back door. A mixed estate is normal during rollout, but it needs active ownership, clear review cadence, and a defined exit condition so coexistence does not quietly become permanent.
Teams should treat the transition as a controlled identity lifecycle, not a feature toggle. That means deciding who can still use passwords, who can approve exceptions, which recovery methods are acceptable, and when a password fallback must be removed after a user is passkey-ready.
What must be governed while passkeys and passwords coexist
The key control point is the set of journeys around sign-in, recovery, and deprovisioning. A user may be passkey-enabled on one device but still rely on a password for account recovery, temporary access, or a legacy app. Those paths need to be inventoried and reviewed because they often carry different risk than the primary sign-in method.
Recovery deserves particular scrutiny because it is where mixed estates most often fail. If help desk reset processes, email fallback, SMS codes, or long-lived recovery options remain open indefinitely, the organisation has not really adopted passwordless, it has only added another route that attackers can target. NIST’s digital identity guidance is useful here for thinking about authenticator strength and recovery requirements, and the NIST SP 800-63 Digital Identity Guidelines give teams a well-known baseline for that discussion.
Good governance also distinguishes primary authentication from exception handling. If a password is retained for a small set of users, the exception should be explicit, time-bound, and reviewed like any other access exception. The mixed state should be visible in access reviews so owners can see which accounts still have password-based access and why.
How to keep the remaining password path from undermining passwordless
The fastest way to weaken a passkey rollout is to leave legacy credentials in place without tighter rules. Password reuse, shared fallback channels, and broad recovery permissions can all reintroduce phishing and replay risk even when the primary login is strong. That is why passwordless programs should remove passwords from the default path as soon as the user can authenticate safely without them.
Implementation detail matters. Some users will need staged migration because of device compatibility, role constraints, or limited recovery options, so teams should define which apps, populations, and recovery channels are still allowed to depend on passwords. The transition is healthier when the policy says what must be true before a password can be removed, not just when a passkey can be added.
For many organisations, a practical control set is to make passkeys the normal method, limit password fallback to temporary exception status, and require review of every password-bearing account. That is consistent with the broader identity governance model described in the IAM and IGA Basics guide and the Access Reviews and Certification Guide, which both emphasise ownership, entitlement review, and closing the loop on lingering access.
What good governance looks like during the transition
At minimum, teams should be able to answer four operational questions: who still has a password, why they still need it, when that exception will be removed, and what recovery path replaces it. If those answers are not available in review-ready form, the programme is still in a deployment phase rather than a governed state.
Ownership is especially important for offboarding and recovery. A passkey rollout can create false confidence if users are migrated but old recovery paths, dormant passwords, or unreviewed backup methods remain live. The governance standard should therefore include explicit lifecycle events, enrollment checks, exception expiry, and periodic reassessment of residual passwords.
Where organisations need a practical benchmark for phasing out legacy sign-in methods, the passkey rollout should be tied to measurable outcomes such as the percentage of accounts with password fallback still enabled, the number of active exceptions, and the share of recovery events that still depend on legacy methods. The Passwordless and Passkeys Guide is a useful companion for understanding rollout, recovery, and authenticator strength.
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, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers authenticator strength and recovery requirements for mixed sign-in states. |
| Recommendation — Use AAL and phishing-resistant guidance to retire passwords once passkeys are established. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Mixed authentication needs explicit transition ownership and risk acceptance. |
| Recommendation — Define a time-bound migration policy for password fallback and exceptions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passwords, passkeys, and recovery credentials require controlled lifecycle management. |
| Recommendation — Track, rotate, and revoke legacy authenticators as users move to passkeys. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access rules must govern who may still use passwords during migration. |
| A.5.16 — Identity management | Mixed estates require clear identity ownership and lifecycle accountability. | |
| Recommendation — Document and enforce access rules for residual password use. Assign owners for exceptions, recovery methods, and password retirement. | ||
Practitioner Guidance
What to prioritise: Prioritise the recovery path before you celebrate passkey enrollment. If a password can still be reset, replayed, or recovered through a weaker channel, the strongest authenticator in the estate is not yet the one that matters most.
Decision rule: If a user can authenticate with a passkey and has no hard business dependency on a password, treat the password as a retireable exception, not a parallel option. If a password must remain, assign an owner, an expiry condition, and a review date.
What to verify: Verify that access reviews, offboarding checks, and help desk procedures all surface residual password use. Teams often migrate the login method but forget to remove the fallback mechanics that keep the old risk alive.
Practitioner takeaway: The mixed state is safe only when it is intentionally temporary, observable, and owned. If coexistence has no expiry, you do not have a passkey program, you have a passwordless label on top of legacy access.
Related resources from NHI Mgmt Group
- How should teams structure authorization for application resources when some users need full control and others only need ownership-based access?
- How should IT teams troubleshoot when some users cannot access an on-site server while others can?
- How should MSPs incorporate password management into a broader IAM offering when users still rely on passwords for some apps and workflows?
- How should teams govern AI agent access when downstream systems still require secrets?
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 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org