Passwords are easy to use and easy to steal. Certificate-based authentication replaces the thing a user types with a key they never see.
It is one of the strongest authentication methods available. It is also one of the easiest to deploy badly.
What Is Certificate-Based Authentication?
CBA proves identity with a digital certificate instead of a password. Three parts do the work.
- The X.509 certificate carries the identity information and the public key
- The private key is used to prove possession and should remain protected on the device or hardware token. Hardware-backed, non-exportable keys provide stronger protection against theft
- The Certificate Authority (CA) issues certificates and vouches for them
The certificate binds an identity or attributes to a public key. Possession of the corresponding private key proves that the client controls that credential. The system managing all of this is Public Key Infrastructure.
How Does It Work?
One common form of CBA is mutual TLS, where certificate authentication occurs during the TLS handshake. Other certificate-based authentication systems, such as smart-card or enterprise identity flows, can use different protocols.
- The client connects to a protected service
- The server presents its certificate and the client validates it
- The server requests the client's certificate
- The client signs a challenge with its private key
- The server verifies the signature, the certificate chain, and the revocation status
When both client and server authenticate with certificates during TLS, it is mutual TLS (mTLS). It is commonly used for APIs, service-to-service traffic, and machine identities.
Why Does It Matter?
Properly configured CBA is phishing-resistant and removes reusable passwords from the authentication flow. However, attackers can still target certificate issuance, exportable private keys, endpoints, or recovery processes. Microsoft classifies CBA as a phishing-resistant authentication method. (Microsoft Learn)
CBA can be configured as single-factor or multifactor authentication. Hardware-backed certificates protected by a PIN can provide a strong possession-plus-knowledge authentication flow. Microsoft Entra explicitly supports CBA as either 1FA or MFA depending on policy. (Microsoft Learn)
Where Does CBA Actually Break?
Issuance. If enrolment is too permissive, an attacker requests a legitimate certificate for someone else. With ESC1, a dangerous template typically combines low-privileged enrollment rights, requester-supplied subject/SAN values, an authentication-capable EKU, and no effective approval requirement. This can let an attacker request a certificate representing another identity, including a privileged account. (Microsoft Learn) CISA reported ESC1 at a critical infrastructure organisation in its 2026 red team advisory.
Key storage. Software-stored private keys may be exportable or easier to steal if the endpoint is compromised. TPMs, smart cards, and HSMs can make extraction significantly harder when keys are configured as non-exportable.
Revocation. Revocation behaviour depends on the platform. For example, Microsoft Entra CBA fails authentication if a configured CRL cannot be retrieved, but if no CRL is configured, certificate revocation is not checked. Revocation therefore needs to be configured and tested explicitly. (Microsoft Learn)
Expiry. Certificates that are not renewed on time can cause authentication outages. Automated renewal and expiry monitoring are therefore important operational controls.
Common Mistakes
- Assuming a certificate equals security. The question is who can obtain one, not whether one exists.
- Manual renewal. Anything tracked in a spreadsheet eventually expires unnoticed.
- Over-trusting the internal CA. A CA is highly privileged identity infrastructure. Compromise of a trusted CA can let an attacker issue certificates that impersonate users, devices, or services, so it should receive protection comparable to other critical identity systems. Microsoft specifically warns that PKI compromise can allow attackers to issue certificates for any tenant user. (Microsoft Learn)
How to Reduce the Risk
- Audit certificate templates and enrolment rights
- For templates that must allow requester-supplied identity information, restrict enrollment tightly and use safeguards such as manager approval or authorized signatures where appropriate. Do not require approval for every client-authentication certificate by default
- Keep trust stores minimal
What Should Security Testing Cover?
Ask your testers to establish:
- Whether an ordinary user can obtain a certificate for another identity
- Whether a revoked certificate is genuinely rejected
- Whether mTLS is enforced on internal APIs or merely available
How OraSec Can Help
Certificate services are a standard part of our Active Directory and internal penetration testing. We test enrolment paths the way attackers do, looking for templates that grant more authority than intended.
Conclusion
CBA removes an entire category of password attacks. It does not remove the need to check who can get a certificate. Cryptography is rarely the weak point. Issuance, key storage, and revocation are.
FAQs
How does CBA compare with FIDO2 and passkeys? Both are passwordless and phishing-resistant. CBA runs on PKI and covers users, devices, services, and mTLS. FIDO2 and passkeys use security keys or platform authenticators and deploy faster for user sign-in. Most organisations use both.
Do we need to act on post-quantum now? Yes, planning should start now. Build a cryptographic inventory, identify systems dependent on RSA or ECC, and design for crypto-agility so migration to post-quantum algorithms can happen without rebuilding the PKI. NIST now explicitly says organizations should begin migrating. (NIST)
