Authentication becomes stronger, but authorization and lifecycle governance remain unresolved. A valid FIDO2 assertion only proves the user or device completed the ceremony, not that the account should have the requested access, so RBAC and ABAC still need independent enforcement.
What FIDO2 Actually Solves, and What It Does Not
FIDO2 strengthens the sign-in ceremony by replacing reusable secrets with phishing-resistant authenticators, but it does not decide whether the authenticated user should reach a specific application, dataset, or privileged function. That separation matters because access control still has to be enforced by the application, directory, policy engine, or platform after the assertion is accepted.
In practice, FIDO2 is an authentication control, not a complete access decision system. It answers “who or what proved possession of the authenticator” rather than “what should this principal be allowed to do now.” When organisations blur that boundary, they often overestimate the protection they have against misuse of valid accounts.
Why Authorization Still Needs Its Own Control Plane
The most common failure is assuming that a strong login method makes downstream permissions trustworthy by default. A valid FIDO2 assertion can confirm a user or device completed the ceremony, but it does not enforce role membership, attribute checks, separation of duties, or business-context restrictions. Those decisions still need independent policy enforcement, often through authorisation models such as RBAC or ABAC, and sometimes through step-up or conditional access.
This is also where identity governance matters. Authentication can be perfect while access remains stale, excessive, or poorly reviewed. If an account keeps long-lived entitlements after a role change, FIDO2 only makes the login safer, not the authorisation outcome more correct. Organisations still need provisioning, deprovisioning, access reviews, and policy exceptions to be handled separately.
For teams rolling out passwordless sign-in, a useful mental model is to treat FIDO2 as a stronger front door, not as the building’s internal zoning system. Passwordless and passkeys guidance is most useful when it is paired with explicit permission design, because phishing resistance does not remove privilege creep, toxic combinations, or overbroad application scopes.
Where Governance, Recovery, and Account Boundaries Still Break
FIDO2 also leaves lifecycle questions open. Enrollment, recovery, device replacement, lost authenticator handling, offboarding, and shared-account practices all sit outside the core assertion itself. If those processes are weak, attackers and insiders can still gain access through recovery channels, inherited sessions, or orphaned accounts even when the primary authenticator is strong.
That is why IAM and IGA basics remain relevant after FIDO2 is deployed. The organisation still needs to know who owns the account, when access should end, which entitlements are justified, and how exceptions are approved. FIDO2 does not remove the need for joiner-mover-leaver discipline or for a clean boundary between authentication events and authorisation state.
The same is true for privileged and shared workflows. If administrators, service desks, or support teams can reset access without strong approval and auditability, an attacker may bypass the FIDO2 barrier by targeting the recovery process instead of the authenticator. Strong sign-in is useful, but only if the surrounding lifecycle and recovery controls are equally deliberate.
Risk and Threat Considerations
When organisations treat FIDO2 as complete access control, the residual risk shifts to the policy and recovery layers. Attackers do not need to defeat the authenticator if they can exploit excessive permissions, stale entitlements, weak account recovery, or delegated administration paths. The control then fails by overconfidence, not by cryptographic weakness.
Failure mechanism: A valid FIDO2 assertion is accepted as proof of access entitlement, so downstream policy checks, entitlement review, and recovery governance become under-enforced or effectively bypassed.
Impact: Compromised but valid accounts can still reach sensitive systems, and revoked or overprivileged access can persist longer than defenders expect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | FIDO2 strengthens user authentication but not access decisions. |
| AC-6 — Least Privilege | The question hinges on permissions remaining separate from sign-in strength. | |
| IA-5 — Authenticator Management | FIDO2 depends on authenticators whose enrollment, rotation, and recovery must be governed. | |
| Recommendation — Use IA-2 to require strong user authentication before access is granted. Enforce AC-6 so authenticated users receive only the access they need. Manage authenticators through IA-5 to control enrollment, use, and recovery. | ||
Practitioner Guidance
What to verify: Confirm that every FIDO2-protected login is followed by an independent authorisation decision at the application or resource layer. If the same assertion unlocks different privilege levels without additional policy, the design is over-trusting authentication.
What to prioritise: Review recovery, offboarding, and privilege review first, because those are the most common places where FIDO2 deployments are undermined. The strongest sign-in method in the world will not compensate for weak account lifecycle governance.
Common mistake: Treating “we use passkeys” as evidence that RBAC, ABAC, entitlements, and admin approval flows are already covered. They are separate controls and should be tested separately.
Practitioner takeaway: FIDO2 should reduce authentication compromise, not become a substitute for access design; if authorisation and lifecycle controls are not explicit, the organisation has only moved the weakness to a different layer.
Related resources from NHI Mgmt Group
- What breaks when organisations treat SSO as complete access governance?
- What breaks when organisations treat MFA as optional instead of baseline access control?
- What breaks when organisations treat multi-factor authentication as a complete identity solution?
- What breaks when organisations treat privileged access as a one-time project instead of an ongoing control?