How do teams decide where to use FIDO versus certificates?

Why This Matters for Security Teams

The FIDO versus certificate decision is really a question of where phishing-resistant authentication can be enforced end to end. FIDO works best where modern browsers, devices, and applications can support passkeys without fallback paths that quietly weaken assurance. Certificates remain necessary where enterprise workflows, device posture, platform coverage, or machine-to-machine trust still depend on cryptographic identity. NIST SP 800-63 Digital Identity Guidelines treat phishing resistance as an outcome, not a brand preference, which is the right frame for this choice.

Security teams get into trouble when they treat FIDO as a universal replacement for certificates or certificates as a default just because they are familiar. The right control depends on whether the identity is human, workload, or device, and whether the access path can sustain strong assurance at every step. NHI Management Group’s Ultimate Guide to NHIs shows how often weak ownership and long-lived credentials create persistent exposure, which is one reason certificate-heavy environments still need disciplined lifecycle control. In practice, many security teams encounter authentication drift only after a legacy app, mobile constraint, or service integration has already created an exception path.

How It Works in Practice

Teams usually start by mapping access paths, then separating user authentication from workload and device identity. FIDO, especially passkeys, is the preferred path for interactive sign-in where the application stack supports modern WebAuthn flows and there is no silent fallback to SMS, OTP, or reusable passwords. That is where phishing resistance is most valuable. Certificates, by contrast, are more common where the subject is a device, service, API client, or legacy enterprise application that needs mutual TLS, client authentication, or cryptographic trust outside a browser session.

For human access, the policy question is whether the application can enforce modern authentication consistently. For machine access, the policy question is whether certificate-based workload identity is still the cleanest primitive. NIST’s identity guidance emphasizes assurance and authenticator strength, while implementation guidance from sources such as NIST SP 800-63 Digital Identity Guidelines helps teams align authenticator choice with threat model rather than convenience. In machine identity environments, the operational burden is real: SailPoint’s research notes that certificate expiry is the leading cause of outages for 45% of organisations in The Critical Gaps in Machine Identity Management report, which is why rotation, visibility, and automation matter as much as the certificate itself.

• Use FIDO when the user journey is interactive, modern, and fully passkey-capable.
• Use certificates when the workload, device, or legacy application needs cryptographic identity outside browser login.
• Avoid fallback mechanisms that undermine phishing resistance or create separate weak paths.
• Automate certificate issuance, renewal, and revocation so expiry does not become a reliability event.

These controls tend to break down in hybrid estates where a modern identity provider fronts older applications that cannot consume FIDO directly and still depend on long-lived certificates or proxy-mediated trust.

Common Variations and Edge Cases

Tighter authentication policy often increases rollout complexity, requiring organisations to balance stronger phishing resistance against application compatibility and support overhead. That tradeoff is especially visible during migrations, because FIDO can be ideal for employees while certificates remain unavoidable for contractors, shared devices, VDI, OT systems, or headless services. There is no universal standard for this yet across every platform, so current guidance suggests choosing the strongest method each access path can truly sustain rather than forcing one mechanism everywhere.

One common edge case is environments that need both human and workload authentication in the same workflow. In those cases, FIDO can secure the human step while certificates secure device or service trust behind the scenes. Another is regulated environments where device attestation, mutual TLS, or non-browser access makes certificates the more practical control. NHI Management Group’s research consistently shows that unmanaged secrets and weak ownership amplify risk, so the real decision is often about lifecycle control as much as authentication method. JetBrains GitHub plugin token exposure is a reminder that long-lived credentials remain attractive targets when coverage is incomplete, while the Sisense breach shows how exposed credentials can quickly become a broader access problem.

In practice, the best answer is often mixed-mode: FIDO for interactive users, certificates for devices and services, and a migration plan that steadily removes fallback paths.

Related resources from NHI Mgmt Group

• How should security teams decide where to use secretless authentication versus secrets management?
• How should security teams decide when to use copilots versus AI that owns IAM workflows?
• How do teams decide when to use a reasoning model versus a faster model?
• How should security teams choose between passwords, tokens, certificates, and biometrics?