Notifications
Clear all
Topic starter
12/06/2026 10:18 pm
TL;DR: Certificate-based authentication uses digital certificates and public key cryptography to verify users, devices, and servers while reducing reliance on passwords and phishing-prone credentials, according to Axiad. It strengthens authentication, but it also shifts the governance burden to certificate lifecycle, access scope, and credential management at scale.
NHIMG editorial — based on content published by Axiad: Why is CBA Hot Right Now?
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern certificate-based authentication beyond the login step?
A: Treat certificate-based authentication as one control in a broader identity programme.
Q: Why do certificates create governance issues for non-human identities?
A: Because certificates are often attached to devices, servers, APIs, and service accounts that do not behave like people.
Q: What do teams get wrong when they treat CBA as a complete security solution?
A: They confuse strong authentication with complete access control.
Practitioner guidance
- Inventory every certificate-backed identity Map users, devices, servers, service accounts, and partner access that rely on certificates so ownership and renewal obligations are explicit.
- Separate authentication from authorization reviews Validate that a successful certificate login does not automatically confer broad privilege.
- Build revocation into lifecycle controls Define renewal, expiry, and emergency revocation processes for certificates the same way you would for other sensitive credentials.
What's in the full article
Axiad's full blog covers the operational detail this post intentionally leaves for the source:
- How CBA maps to Windows, macOS, Azure AD, email, and backend service access in practice
- The certificate management detail behind issuing, storing, and validating digital certificates at scale
- The specific user and device scenarios where certificate-based login replaces or complements passwords
- Axiad's own implementation framing for credential management at scale
👉 Read Axiad's blog on certificate-based authentication and IAM →
Certificate-based authentication: are your IAM controls keeping up?
Explore further
13/06/2026 12:59 am
CBA is an authentication control, not an identity governance programme. The article correctly positions certificates as a stronger way to prove identity, but the governance burden simply moves from passwords to certificates. Issuance, binding, renewal, and revocation still determine whether the control is trustworthy. Practitioners should read CBA as a front door improvement, not as a substitute for lifecycle discipline.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why certificate-backed identities need lifecycle ownership as well as cryptography.
A question worth separating out:
Q: How do organisations decide whether CBA should be used for users, devices, or workloads?
A: Use CBA where cryptographic trust is needed, but apply different governance rules for each actor type. Human users need joiner-mover-leaver controls, devices need managed trust and revocation, and workloads need service ownership and rotation discipline. The deciding factor is not the certificate format, but whether the identity can be governed end to end.
👉 Read our full editorial: Certificate-based authentication and the limits of password replacement
