TL;DR: Enterprises are increasingly treating FIDO and certificate-based authentication as complementary rather than competing methods, because FIDO remains uneven across environments while CBA already fits user and machine identity use cases today, according to Axiad. The practical issue is not choosing one standard but aligning each to the authentication problem it solves without creating governance gaps.
At a glance
What this is: This article argues that identity teams should use FIDO and certificate-based authentication together, not as substitutes, because each covers different authentication conditions.
Why it matters: It matters because IAM programmes that force a single authentication standard across users, devices, and workloads can leave practical gaps in coverage, governance, and rollout.
Context
FIDO and certificate-based authentication solve related but different identity problems. FIDO is a phishing-resistant, passwordless method that is strong for interactive user authentication, while certificate-based authentication relies on PKI and X.509 certificates for users, devices, and workloads.
The governance issue is not which method wins a standards debate. It is whether identity teams can align authentication controls to the actual subject being authenticated, including human users, managed devices, and machine identities, without forcing one control model into every use case.
Key questions
Q: How should security teams choose between FIDO and certificate-based authentication?
A: Security teams should choose by identity type, environment maturity, and lifecycle control. FIDO fits phishing-resistant human login, while certificate-based authentication fits environments that already rely on PKI for users, devices, or workloads. The right answer is often both, with each method mapped to the use case it governs best.
Q: Why do organisations still need certificate-based authentication when FIDO exists?
A: Because FIDO is not designed to cover every identity context. Certificate-based authentication still matters for device identity, workload authentication, and environments that depend on PKI and certificate lifecycle control. In practice, CBA fills gaps where user-centric passwordless methods do not reach, especially across managed endpoints and integrated enterprise platforms.
Q: What are the signs that a single authentication standard is not enough?
A: The clearest signs are inconsistent support across operating systems, exceptions for managed devices, and separate processes for users versus workloads. If teams keep building workarounds for the same access journey, the standard is not covering the real environment. That is usually a governance problem, not just a tooling problem.
Q: What should teams do when FIDO does not cover a required use case?
A: Use the method that fits the use case and document why. In many environments, that means keeping certificate-based authentication for device or workload scenarios while adopting FIDO for human sign-in. The goal is consistent assurance, not uniformity for its own sake.
Technical breakdown
FIDO and CBA solve different authentication paths
FIDO2 uses public-key cryptography and user presence or biometrics to authenticate a person without sending reusable secrets across the network. That makes it strong against phishing and credential replay in interactive sessions. Certificate-based authentication uses X.509 certificates and trusted public key infrastructure to prove possession of a private key, which fits managed endpoints and non-human identities that need machine-verifiable trust. The two methods are not equivalent substitutes because their control assumptions differ at enrolment, device binding, and lifecycle management.
Practical implication: Map interactive human sign-in to FIDO where possible, and reserve certificate-based authentication for managed devices, workloads, and environments that need PKI-backed trust.
Why CBA remains operationally useful today
Certificate-based authentication already works across user and machine identity use cases, which is why it remains relevant while FIDO coverage matures. It can also simplify certain identity architectures by reducing dependence on federated directories for every flow. In practice, CBA is less about replacing modern authentication than about providing a dependable trust layer where device-bound certificates, platform support, or legacy integration requirements make FIDO incomplete. The operational question is coverage, not ideology.
Practical implication: Inventory the authentication journeys that FIDO does not yet cover and use CBA to close those gaps rather than deferring the project.
Pragmatic FIDO is an architecture choice, not a slogan
A pragmatic authentication mix means choosing the method that matches the use case instead of forcing one standard to serve every identity type. For example, FIDO may be appropriate for Office 365 access, while CBA can support MacOS device authentication or unify multiple IAM systems in a non-disruptive way. This is an architecture decision because it changes onboarding, recovery, policy enforcement, and support operations. The value is in reducing friction without weakening assurance.
Practical implication: Design authentication policy by use case and identity type, then document where each method is authoritative.
NHI Mgmt Group analysis
Authentication standardisation fails when teams confuse coverage with control quality. The article's core point is that FIDO and certificate-based authentication solve different identity problems, so a single-method policy can create blind spots. Human sign-in, managed endpoints, and machine identities do not all share the same trust mechanics. The practitioner conclusion is to govern authentication by identity type and use case, not by technology preference.
Certificate-based authentication remains a structural bridge for mixed environments. Where FIDO coverage is uneven, CBA gives identity teams a standards-based way to authenticate users, devices, and workloads today. That matters because migration programmes often stall when one method is treated as mandatory across every platform. The practitioner conclusion is that CBA should be evaluated as a coverage and interoperability control, not as a temporary compromise.
Phishing resistance is a use-case property, not a universal endpoint state. FIDO is valuable where interactive user authentication is the threat, but that does not make it the right control for every workload or managed device. The article shows that assurance depends on the relationship between the authenticator and the subject, which is why identity governance has to be use-case specific. The practitioner conclusion is to stop asking which standard wins and start asking which trust problem each one solves.
Cross-IAM authentication design is now an identity governance issue, not only a technical one. A unified platform that supports both methods changes enrolment, recovery, policy consistency, and operational support across the identity estate. That means authentication architecture now sits inside broader IAM governance, including lifecycle, assurance, and user experience. The practitioner conclusion is to treat mixed-method authentication as a programme design decision with policy and support consequences.
Pragmatic FIDO: a named operating model for mixed authentication estates. This article describes an approach in which FIDO and CBA are assigned by use case rather than ideology. The concept is useful because it captures the real constraint identity teams face: no single authenticator covers every person, device, and workload with equal assurance. The practitioner conclusion is to formalise a mixed-authentication operating model instead of waiting for one standard to cover all environments.
What this signals
Mixed authentication is now a governance pattern, not a transitional exception. Identity teams increasingly have to support different authenticators for different subjects, which means policy, recovery, and support models need to be explicit rather than assumed. The programme risk is not that multiple methods exist, but that ownership of each method is undefined.
Authentication architecture should follow the trust problem, not the product roadmap. Where phishing-resistant user sign-in is the issue, FIDO is the right lens. Where managed device or workload trust is the issue, certificate-based authentication remains the more operationally grounded control. Treating them as separate governance domains avoids forcing one control into every access path.
For practitioners
- Define authentication by identity type Separate human interactive sign-in, managed device access, and workload authentication before choosing a control. That prevents one method from being forced into roles it does not cover well.
- Use FIDO where phishing resistance matters Prioritise FIDO for user sign-in flows that are internet-facing and high risk for credential replay or phishing. Keep recovery and exception handling in scope so the deployment does not become brittle.
- Retain CBA for managed endpoints and workloads Use certificate-based authentication where PKI-backed trust, device binding, or workload identity support is the operational requirement. This is especially relevant when platform coverage or legacy integration still blocks FIDO-only designs.
- Document the authoritative method per journey Record which authenticator is primary for each application, device class, and access path. That reduces policy drift when teams support both modern passwordless flows and certificate-based trust.
- Test recovery and enrolment paths together Validate what happens when a user, device, or workload cannot use the preferred authenticator. Mixed authentication fails when recovery logic is improvised after rollout.
Key takeaways
- FIDO and certificate-based authentication address different identity subjects, so IAM teams should not treat them as interchangeable controls.
- Mixed estates need explicit governance for enrolment, recovery, and method selection, or gaps will appear in the exceptions.
- A pragmatic authentication model is use-case driven: FIDO for interactive human sign-in, CBA for device and workload trust where PKI is the better fit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article is about choosing authentication methods for human, device, and workload identities. |
| NHI-05 — Overprivileged NHI | CBA use cases here depend on limiting auth paths to the identities and devices that need them. | |
| Recommendation — Apply NHI-04 to assess whether each identity type uses an authentication method it can actually support. Constrain certificate-authenticated identities to the minimum access path required for the use case. | ||
| NIST SP 800-63 | SP 800-63B — Authentication | The article compares modern authentication methods and their assurance properties. |
| Recommendation — Use SP 800-63B to align authenticator choice with assurance level and phishing resistance requirements. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Mixed FIDO and CBA estates depend on credential and authenticator lifecycle management. |
| Recommendation — Apply IA-5 to govern enrolment, replacement, and revocation for every authenticator in scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about matching authentication controls to access paths and subjects. |
| Recommendation — Use PR.AA-05 to ensure authentication policy matches the identities and systems being granted access. | ||
Key terms
- Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
- FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
- Pragmatic Authentication Architecture: An identity design approach that assigns each authentication method to the use case it handles best. It avoids forced standardisation and instead aligns human, device, and workload identity flows with the trust model, lifecycle controls, and operational maturity each one requires.
- Public Key Infrastructure: Public Key Infrastructure is the trust system that issues, manages, and revokes digital certificates used to prove identity. In practice it binds keys to entities and policies, making authentication, encryption, and non-repudiation possible across users, devices, and services.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org