Notifications
Clear all
Topic starter
12/06/2026 10:08 pm
TL;DR: Enterprises and government agencies do not need to choose between FIDO and certificate-based authentication, because each covers different gaps in phishing-resistant identity assurance and device or workload use cases, according to Axiad. The practical question is not replacement but placement: which authenticator fits which identity, device, and operating context.
NHIMG editorial — based on content published by Axiad: CBA and FIDO: one, other, or both?
Questions worth separating out
Q: How should security teams decide between FIDO and certificate-based authentication?
A: Choose by identity type and access context.
Q: Why do organisations still need certificate-based authentication when FIDO exists?
A: Because FIDO is not designed to cover every identity context.
Q: What breaks when one authentication method is forced across all identity types?
A: You create blind spots in either user assurance or machine trust.
Practitioner guidance
- Map authentication controls by identity type Separate human user sign-in, device authentication, and workload authentication into distinct policy lanes.
- Use FIDO where phishing resistance is the priority Prioritise FIDO for interactive user access where passwordless sign-in and phishing resistance are the main goals, especially in modern browser-based flows.
- Use certificates where device binding matters Deploy certificate-based authentication for endpoints, managed devices, and workload identities that need stronger trust than browser-based login alone can provide.
What's in the full article
Axiad's full blog post covers the implementation detail this post intentionally leaves for the source:
- How Axiad positions FIDO and CBA across different authentication use cases and platform constraints
- Examples of where CBA is preferred for Azure AD and where FIDO fits better for end-user sign-in
- The vendor's explanation of its pragmatic FIDO approach across multiple IAM systems
- The product context behind supporting both authentication methods in one platform
👉 Read Axiad's analysis of FIDO and certificate-based authentication →
FIDO vs CBA: what IAM teams should do now?
Explore further
13/06/2026 12:41 am
FIDO and certificate-based authentication solve different assurance problems, so treating them as substitutes creates governance blind spots. FIDO is strongest for modern human sign-in, while CBA extends trust into device and workload contexts where certificates and PKI provide a better fit. The identity programme risk is not lack of authentication sophistication, but forcing one control to cover incompatible use cases. Practitioners should build policy around identity context, not technology preference.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why authentication choice alone cannot close governance gaps.
A question worth separating out:
Q: How do teams know whether their authentication programme is balanced?
A: Look for coverage across user, device, and workload scenarios, not just login success rates. A balanced programme has phishing-resistant sign-in for people, certificate trust where needed for devices and workloads, and explicit lifecycle control for certificates and authenticators. If one method is carrying every scenario, the design is probably brittle.
👉 Read our full editorial: FIDO and certificate-based authentication are complementary controls
