Start with accounts that face phishing or password reuse risk, then standardise registration, backup authenticator enrolment, and recovery policy. FIDO2 works best when it is part of a defined human authentication standard rather than an optional feature left to individual users or teams.
What a FIDO2 rollout should standardise first
Implement FIDO2 as a controlled authentication programme, not as an end-user preference. The first design decision is where passwordless materially reduces risk: accounts exposed to phishing, password reuse, push fatigue, or help desk resets. From there, standardise registration, supported authenticator types, backup factors, and the conditions under which recovery is allowed.
That means users should not be free to self-select a weaker path for convenience. A workable rollout defines which authenticators are approved, how devices are enrolled, how lost-device cases are handled, and when a user can be re-bound to a new authenticator after verification.
FIDO2 also changes how organisations think about sign-in assurance. The control objective is not just to remove passwords, but to bind authentication to a phishing-resistant, origin-bound factor that can be governed consistently across browsers, devices, and applications.
How to design registration, backup, and recovery without weakening the control
Registration is where most rollouts either become durable or fragile. Require a verified initial identity-proofing or trusted session step before a user can add a passkey, then record which device, platform, or security key was enrolled. For a practical baseline, align the login standard with NIST SP 800-63 Digital Identity Guidelines so authentication strength, assurance level, and recovery handling are treated as part of one policy.
Backup authenticator enrolment should be mandatory for most workforce use cases. If users have only one device-bound authenticator and no recovery path, the result is often a support burden or a reversion to a weaker fallback. Make the backup method explicit, limited, and recoverable under policy, not improvised by service desk staff during an urgent reset.
Recovery deserves the same control discipline as sign-in. If a lost device, a factory reset, or a new phone can silently replace the primary authenticator, the passwordless programme becomes easier to abuse than the password system it replaced. Document who can approve recovery, what evidence is required, and which events trigger step-up verification or temporary access restrictions.
Where implementation usually fails in practice
FIDO2 fails when organisations treat it as a feature toggle instead of an operating model. Common mistakes include allowing multiple exception paths, leaving legacy password fallback enabled indefinitely, and letting help desk teams bypass enrolment policy under pressure. A rollout also becomes inconsistent when some applications require passkeys, some allow passwords, and some still depend on unmanaged MFA choices.
Phishing resistance only holds when the user journey is uniform enough that attackers cannot steer people into older paths. Published guidance on Passwordless and Passkeys Guide is useful here because it frames passkeys, WebAuthn, and recovery as one control set rather than separate projects.
Rollouts also fail when the organisation does not plan for different user populations. Employees with managed devices, contractors on shared endpoints, and executives using multiple devices often need different enrolment patterns, but those differences should be deliberate. The objective is consistent policy with controlled variants, not an ad hoc exception culture.
Risk and Threat Considerations
Weak rollout choices can reintroduce the very risks FIDO2 is meant to reduce. The main exposure is not the authenticator itself, but the fallback layer: passwords, SMS, help desk resets, and poorly governed recovery are the paths attackers target once a passwordless control exists.
Failure mechanism: If a user can be re-enrolled through a weak support process, an attacker may bypass the phishing-resistant factor by attacking recovery, social engineering, or an older secondary login path.
Impact: The organisation ends up with uneven assurance, where “passwordless” is strong only for some sessions and accounts, while account takeover remains possible through the weakest enrolled path.
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, OWASP ASVS, 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 | FIDO2 rollout depends on authenticator assurance and recovery policy. |
| Recommendation — Align authentication strength and recovery rules to the required assurance level. | ||
| OWASP ASVS | V6 — Authentication | Passkey rollout is an authentication design and verification problem. |
| Recommendation — Verify that login flows enforce phishing-resistant authentication and controlled fallback. | ||
| NIST CSF 2.0 | PR.AA-05 — Protective Technology | Passwordless login is a protective authentication control for human users. |
| Recommendation — Implement phishing-resistant authentication for workforce sign-in. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | FIDO2 programmes require governed enrolment, replacement, and recovery of authenticators. |
| Recommendation — Manage authenticator lifecycle and recovery under explicit policy. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Rollout requires controlled identities, enrolment, and authentication governance. |
| Recommendation — Define identity and authentication rules for passwordless enrolment and recovery. | ||
Practitioner Guidance
What to prioritise: Start with high-risk human accounts, then require a single approved enrolment pattern with a defined recovery path. If the business cannot describe how a user is recovered after device loss, the rollout is not ready for broad expansion.
What to verify: Check that password fallback is intentionally limited, that support staff cannot bypass policy casually, and that recovery requires stronger proof than ordinary sign-in. Also verify that applications use the same authentication standard rather than mixed trust rules.
Common mistake: Treating passkeys as a user convenience feature. For workforce identity, the decision is operational and security-led: the control must be enforceable, supportable, and recoverable at scale, or it will quietly degrade into exception handling.
Practitioner takeaway: A successful FIDO2 programme is defined less by the authenticator technology than by the governance around enrolment, fallback, and recovery.
Related resources from NHI Mgmt Group
- How should teams implement FIDO2 passwordless login without weakening account recovery?
- How should security teams implement Client ID Metadata Documents?
- Should organisations treat non-human identities differently from human users in governance?
- What should organisations prioritise after adopting passwordless login?