How can organisations run FIDO and CBA together without creating access sprawl?

Use a policy model that assigns each method to the identity populations and applications it supports, then govern certificate lifecycle and recovery paths as first-class controls. The goal is not to unify everything under one method, but to keep each trust path visible, accountable, and removable when no longer needed.

Why This Matters for Security Teams

Running FIDO and certificate-based authentication together is often a sensible transition strategy, but it becomes dangerous when both methods are granted broadly without clear population boundaries, lifecycle ownership, and revocation discipline. That is how access sprawl starts: one method is added for workforce users, another for legacy apps or machine workflows, and neither is retired when the original need disappears. Guidance from NIST SP 800-63 Digital Identity Guidelines and the OWASP Non-Human Identity Top 10 both point toward the same operational truth: authentication methods must be governed by assurance level, scope, and recoverability, not convenience alone.

NHI Management Group’s research shows why this matters. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes. That same pattern appears in mixed FIDO and CBA estates when certificate issuance, device trust, and fallback access are treated as separate problems instead of one governance model. In practice, many security teams discover overbroad fallback paths only after a certificate lifecycle failure or application outage has already forced an emergency exception.

How It Works in Practice

The safest pattern is to assign each authentication method to the identity populations and applications it truly supports, then make the control plane explicit. FIDO should usually anchor interactive human access where phishing resistance and strong local authenticator proof are the goal. CBA should remain reserved for applications, devices, and regulated workflows that genuinely require certificate-backed trust. The key is to prevent either method from becoming a universal fallback.

At implementation level, that means documenting three things for every relying party: who can use it, which method is permitted, and what happens when the method fails. Certificate lifecycle controls must include issuance authority, expiry, renewal, revocation, and emergency recovery. FIDO controls must include registration, device replacement, recovery, and deprovisioning. Where both are available, the policy should define primary and secondary paths so help desk staff cannot silently create permanent exceptions.

• Use NIST SP 800-63 Digital Identity Guidelines to separate assurance requirements from implementation convenience.
• Treat certificate issuance and revocation as a governed lifecycle, not a one-time onboarding task.
• Keep FIDO registrations tied to named users and known authenticators, with recovery steps that are logged and time-bound.
• Use the 52 NHI Breaches Analysis to stress-test whether shared secrets, stale certificates, or unmanaged exceptions are expanding access.

Current guidance suggests organisations should also review fallback paths as part of access governance, because the real sprawl risk is not the presence of two methods, but the uncontrolled addition of backup routes that nobody owns end to end. These controls tend to break down in hybrid environments with legacy VPNs, long-lived service accounts, or fragmented certificate authorities because recovery logic gets implemented differently in each platform.

Common Variations and Edge Cases

Tighter authentication control often increases operational overhead, requiring organisations to balance resilience against administrative complexity. That tradeoff is real: if certificate recovery is too rigid, users will create shadow access paths; if FIDO recovery is too permissive, phishing resistance is weakened by exception handling. Best practice is evolving, and there is no universal standard for recovery design yet, so policy clarity matters more than method purity.

Some environments need both methods for legitimate reasons. For example, contractors may use FIDO for workforce portals while managed servers use CBA for mutual trust. In those cases, keep the trust domains separate and avoid mixing human and machine recovery processes. Also be careful with break-glass access: it should be short-lived, monitored, and explicitly excluded from routine login flows. The Ultimate Guide to NHIs – Key Challenges and Risks is useful here because the same excessive-privilege and offboarding failures that affect NHIs often appear in certificate estates once exceptions accumulate.

Where organisations get into trouble is assuming that “multiple methods” automatically means “more secure.” Without method-specific scoping, attestable ownership, and documented retirement criteria, dual authentication simply becomes dual sprawl.

Related resources from NHI Mgmt Group

• How should organisations run ISO 27001 user access reviews without creating audit noise?
• How should security teams run access reviews for non-human identities?
• How should organisations automate user access reviews without creating more noise?
• How should teams design policy-based access reviews without creating workflow sprawl?