Notifications
Clear all
Topic starter
12/06/2026 10:07 pm
TL;DR: Azure AD certificate-based authentication replaces password-based sign-in with X.509 certificate validation against Azure AD, reducing reliance on federated AD FS and improving phishing resistance, according to Axiad. The control strengthens human identity assurance, but it still depends on certificate lifecycle governance, revocation, and accurate user binding.
NHIMG editorial — based on content published by Axiad: How Does Azure AD Certificate-Based Authentication Work?
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should organisations govern certificate-based authentication in Azure AD?
A: Treat certificate-based authentication as an identity governance control, not just a login method.
Q: Why can certificate-based sign-in still create risk if passwords are removed?
A: Passwords are only one attack path.
Q: What do security teams get wrong about certificate authentication?
A: They often treat the certificate as the control and ignore the trust relationship behind it.
Practitioner guidance
- Map certificate bindings to named identity owners Document which team owns certificate issuance, renewal, and revocation for each user population, then verify that the mapped user object remains correct after role changes and offboarding.
- Tie certificate expiry to joiner-mover-leaver events Align certificate renewal and revocation with lifecycle events rather than ad hoc requests.
- Audit conditional access for stale sign-in paths Check whether legacy authentication, forgotten federation paths, or exception rules still allow access after CBA is enabled.
What's in the full article
Axiad's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step Azure AD CBA sign-in flow from username entry through certificate selection and mutual TLS.
- Portal configuration details for mapping certificate fields to user attributes and tenant identities.
- Supported MFA combinations, legacy authentication blocking, and browser or mobile sign-in scenarios.
- HTTP-only CDP requirements and validation constraints that affect deployment design.
👉 Read Axiad's guide to how Azure AD certificate-based authentication works →
Azure AD certificate-based authentication: are your controls keeping up?
Explore further
13/06/2026 12:40 am
Passwordless does not mean governance-free. Certificate-based authentication removes password theft from the front line, but it does not remove the identity lifecycle problem. The control still depends on accurate issuance, binding, renewal, and revocation, which are the same governance disciplines that break down across NHI programmes when lifecycle ownership is unclear. Practitioners should treat certificate sign-in as an assurance layer that shifts, rather than eliminates, identity risk.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How do you know if certificate-based authentication is working as intended?
A: Look for accurate certificate-owner mapping, timely revocation after offboarding, and no fallback to weaker sign-in paths. If users can still reach resources through exceptions, stale mappings, or legacy authentication, the control is not operating as a complete assurance model.
👉 Read our full editorial: Azure AD certificate-based authentication and identity risk control
