Entra certificate-based authentication: bindings, affinity and deployment pitfalls
Entra ID certificate-based authentication lets you use smart cards or software certificates directly against the cloud service, with no federation. It is a phishing-resistant method, provided the mapping between certificate and user is robust and the PKI itself deserves trust.
How it works
At sign-in, the user presents a client certificate. Entra ID checks that the chain leads to a certificate authority declared in the tenant's trust store, checks revocation, then looks up the matching user through username bindings. The method is enabled in the authentication methods policy, ideally for a pilot group before a wider rollout.
PKI trust
Root and intermediate authorities are declared in the Entra ID PKI trust store, along with the URL of their revocation list. Two points to watch:
- Revocation: if no revocation list is published or reachable, a revoked certificate may remain usable. An option lets you require revocation list validation; turn it on as soon as your PKI supports it;
- Scope of trust: any declared authority can authenticate users. Declaring an enterprise authority that also issues server or device certificates with loose templates widens the attack surface.
Username bindings and affinity
A binding maps a certificate field to a user attribute: userPrincipalName, onPremisesUserPrincipalName or certificateUserIds. Microsoft classifies these bindings by affinity:
| Affinity | Certificate fields | Risk |
|---|---|---|
| Low | Principal name (SAN), RFC822Name, Subject, IssuerAndSubject | Anyone able to obtain a certificate with the right name can impersonate the user. |
| High | Subject key identifier (SKI), SHA1PublicKey, IssuerAndSerialNumber | The specific certificate is tied to the user; another certificate with the same name is not enough. |
The exact classification may change, so check the current Microsoft documentation. High-affinity binding can be required tenant-wide or per rule.
The AD CS connection. With a low-affinity binding on the principal name, an Active Directory certificate authority vulnerable to a scenario where the requester chooses the subject alternative name lets an attacker obtain a certificate in an administrator's name, then sign in to the cloud. Your PKI's security becomes your Entra ID administrators' security.
Protection level and phishing resistance
Authentication binding rules decide whether a certificate counts as single-factor or multifactor, based on the issuer or the certificate policy identifier. Only multifactor certificate-based authentication satisfies authentication strengths that require phishing-resistant MFA. Keep the multifactor level for certificates whose key is protected, for instance on a smart card or in a hardware module with a PIN.
Common deployment pitfalls
- Enabling the method for all users before populating
certificateUserIdsfor high-affinity bindings; - Forgetting to rotate intermediate authorities and update the trust store;
- Treating every certificate as multifactor, including exportable software certificates;
- Not testing the experience on mobile devices and browsers, where certificate selection varies.
In the tenants we audit, binding on the principal name alone is still the most common configuration.
What an audit checks
- The authorities declared in the trust store and whether their revocation lists are published.
- Whether revocation validation is required.
- The username bindings in use and whether high affinity is required.
- Protection level rules and which certificates count as multifactor.
- The security of certificate templates on the issuing PKI.