Start by mapping where passkeys are supported and where passwords must remain in place, then segment your rollout by application criticality and user population. That prevents a false sense of completion and makes it easier to prioritise high-risk accounts for passwordless migration while keeping fallback access governed.
Where passkeys are missing, start with coverage mapping, not rollout hype
The first job is to understand where the new sign-in path actually exists and where it does not. That means separating applications that can support passkeys today from those that still require passwords, then grouping users by exposure and business criticality. This avoids pretending the estate is “passwordless” before the hard edges have been worked through.
For teams, the useful output is a rollout map that ties each application to its supported authenticators, fallback method, and owner. That gives you a practical view of where password-based access remains unavoidable, where stronger authentication can be switched on first, and where exception handling will be needed during migration.
A phased view is especially important because authentication migration is rarely uniform across web, mobile, legacy, and partner-facing systems. If you treat all accounts the same, you usually end up delaying high-value migrations or allowing weak fallback paths to persist longer than necessary.
How to segment the rollout so the highest-risk accounts move first
Once coverage is mapped, segment by application criticality and user population. High-value administrative accounts, sensitive business workflows, and internet-facing services should usually come before low-impact internal tools, because they gain the most from phishing-resistant sign-in and reduced password exposure. That prioritisation also helps you decide where fallback access deserves the strictest governance.
This is also where user population matters. Employees, contractors, privileged operators, and external users often have different device posture, recovery needs, and support constraints. A single migration policy rarely fits all groups, so the right first move is to separate them into operationally meaningful cohorts and assign a different path where necessary.
If you need a practical baseline for the authentication properties you are trying to reach, NIST’s NIST SP 800-63 Digital Identity Guidelines help frame phishing-resistant authentication and assurance expectations, while NHIMG’s Passwordless and Passkeys Guide and Workforce Identity Security Guide cover rollout and recovery decisions that matter when passwords cannot disappear everywhere at once.
Keep fallback access governed while the transition is incomplete
The main mistake in partial deployments is treating fallback login as temporary and therefore low priority. In practice, password paths, help desk resets, and account recovery flows become the real control surface during migration, because attackers will target whichever route remains easiest. Your rollout is only as strong as the weakest supported path, not the strongest one you have already enabled.
That means the first governance decision is not “Can we deploy passkeys?” but “Which exceptions will still exist, and who approves them?” When passwords must remain, teams should tightly limit where they are allowed, how long they stay in place, and what monitoring or step-up control compensates for the gap. A phased rollout without fallback discipline often creates a false sense of completion.
For teams comparing assurance models, the practical lesson is to treat unsupported applications as a managed exception set, not as a reason to stall the whole programme. NHIMG’s MFA Guide is useful here because it shows why fallback methods and recovery processes need the same scrutiny as the primary authenticator.
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 technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkey rollout hinges on phishing-resistant authentication assurance and recovery choices. |
| Recommendation — Use phishing-resistant authentication and set assurance targets for supported and fallback sign-in paths. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Workforce passkey migration directly affects how organizational users authenticate. |
| IA-5 — Authenticator Management | Partial passkey deployment still depends on governed credential and authenticator lifecycle. | |
| AC-2 — Account Management | Segmenting rollout by user population and application ownership depends on account governance. | |
| Recommendation — Require strong user authentication for the highest-risk accounts and sign-in flows. Control fallback authenticator issuance, rotation, and retirement during migration. Inventory accounts and assign migration priorities by role, privilege, and business criticality. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity lifecycle must cover which users can use passkeys and which remain on fallback methods. |
| A.8.5 — Secure authentication | Passkeys are a secure authentication control, while unsupported paths need compensating measures. | |
| Recommendation — Document identity states and approved authentication methods for each population. Apply secure authentication requirements to supported systems and compensating controls elsewhere. | ||
Practitioner Guidance
What to prioritise: Start with the applications and accounts that combine high privilege, internet exposure, and meaningful business impact. Those are the places where a passwordless step change has the biggest security return and where lingering passwords create the most risk.
What to verify: Before you announce progress, verify which flows still depend on passwords, which user groups cannot yet use passkeys, and whether recovery, help desk, or reset paths quietly reintroduce weaker authentication. If you cannot name the exception paths, you do not yet control them.
Decision rule: If an application cannot support passkeys, do not treat it as a neutral holdout. Classify it by criticality, assign an owner, and require an explicit fallback-control decision so the migration plan reflects real exposure rather than optimistic coverage.
Practitioner takeaway: The first passkey rollout decision is governance, not technology, because partial support only improves security when unsupported systems and fallback access are deliberately segmented and controlled.
Related resources from NHI Mgmt Group
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- What should security teams do first when a widely embedded vulnerability cannot be centrally fixed everywhere at once?
- What should mobile security teams do first when a Linux kernel privilege escalation flaw becomes public but patches are not yet broadly available?