Certificate-based authentication in Entra ID: bindings, affinity and revocation

Use cases

Entra ID certificate-based authentication (CBA) validates an X.509 certificate presented by the user, on a smart card, a PIV-compatible hardware key or in a certificate store, directly with Entra ID. We mostly see it in the following situations:

• organisations that already run a smart card infrastructure, particularly in the public sector and defence;
• moving off AD FS, when smart cards were one of the last reasons to keep federation;
• a need for a phishing-resistant method for populations where FIDO2 keys are not suitable;
• shared workstations or constrained environments where the certificate is already the identification tool.

Declaring certificate authorities

Entra ID needs to know the certificate authorities that issue user certificates: roots and intermediates are uploaded to the tenant, each with the address of its certificate revocation list (CRL). Microsoft is changing how this store is managed, so check the current interface in your tenant. Every declared authority becomes a source of trust for authentication: the list should be kept to the strict minimum and reviewed regularly.

Username binding rules

Once the certificate has been validated, Entra ID must work out which user it belongs to. That is the job of binding rules, which map a certificate field to a user attribute:

• on the certificate side: the principal name (UPN) in the SAN extension, the RFC822 address, issuer and subject, the subject key identifier (SKI), the SHA1 hash of the public key, issuer and serial number;
• on the user side: userPrincipalName, onPremisesUserPrincipalName or certificateUserIds, a multi-valued attribute designed for these bindings.

Low affinity and high affinity

This is the most important setting. Bindings based on the principal name, the RFC822 address or issuer and subject are low affinity: they rely on values that a certificate authority can put in any certificate. Bindings based on the SKI, the public key hash or issuer and serial number are high affinity: they point to one specific certificate.

The policy lets you set the default affinity required, plus specific rules per authority or per policy identifier (OID). Aiming for high affinity, at least for privileged accounts, by populating certificateUserIds, is the target we recommend.

Revocation and protection level

Entra ID downloads the CRLs of the declared authorities to check that a certificate has not been revoked. Points to check:

1. CRL addresses must be reachable from the internet and the lists must stay a reasonable size;
2. the option requiring CRL validation must be enabled, otherwise a revoked certificate may still be accepted when the list is unavailable;
3. revoking a certificate does not invalidate sessions that are already open: when a card is lost, the user's sessions must be revoked too.

Finally, each protection rule decides whether the certificate counts as a single factor or as multifactor authentication. Configured as multifactor, for example for a PIN-protected smart card, CBA is recognised as phishing-resistant and can satisfy the corresponding authentication strength in Conditional Access.

What an audit checks

• The list of trusted certificate authorities and their justification.
• Username binding rules and the affinity level required, especially for administrators.
• Population of the certificateUserIds attribute.
• CRL reachability and whether CRL validation is required.
• Protection rules (single factor or multifactor) per authority or OID.
• The security of certificate templates on the issuing AD CS.