Configure Entra certificate-based authentication with smart cards and PKI

Microsoft Entra certificate-based authentication (CBA) lets users sign in directly to Microsoft Entra ID with an X.509 certificate from your own PKI, on a smart card or on the device, with no AD FS in the path. To set it up, upload your root and issuing CAs to the PKI-based trust store with internet-reachable CRL URLs, enable the Certificate-based authentication method for a group of users who already hold certificates, set the authentication binding so your smart card certificates count as multifactor, map certificate fields to user accounts, and then require the Phishing-resistant MFA authentication strength in Conditional Access.

Who this is for and what you will have at the end

This guide is for identity and PKI administrators who already issue user certificates, typically from Active Directory Certificate Services (AD CS) onto smart cards, and want them to work for Microsoft 365 and other Entra-integrated apps, often as part of retiring AD FS.

At the end you will have your CA hierarchy in the Entra trust store with CRL checking enforced, CBA enabled for a pilot group with clear single-factor and multifactor rules, high-affinity username bindings, a Conditional Access policy that accepts CBA as phishing-resistant MFA, and Windows smart card sign-in against Entra ID.

How Entra CBA works

When the user selects Use a certificate or smart card, the client goes to the certificate authentication endpoint (certauth.login.microsoftonline.com in the public cloud), which requests the certificate during a TLS mutual authentication handshake. Entra ID then:

1. Builds the chain to a CA in your trust store.
2. Checks the CRLs for each CA in the chain.
3. Finds the user with the username binding policy.
4. Decides whether the certificate is single-factor or multifactor with the authentication binding policy.
5. Applies Conditional Access. If MFA is required and the certificate is only single-factor, registered users are offered passwordless sign-in or FIDO2 as the second factor.

Two settings matter throughout:

Prerequisites

• A working, well-protected PKI. If an attacker can issue certificates from a CA you trust, they can sign in as any user mapped by your bindings.
• User certificates intended for client authentication, issued from that PKI and present on the user's smart card or device.
• A CRL for every CA, published to an internet-facing HTTP URL. Entra ID supports one CRL distribution point per CA, HTTP or HTTPS (Microsoft recommends HTTP); OCSP and LDAP aren't supported.
• Roles: Privileged Authentication Administrator to manage the PKI-based trust store; Authentication Policy Administrator to configure the CBA method; Conditional Access Administrator for policies.
• Licensing: CBA itself is free. Bulk PKI upload needs Microsoft Entra ID P1 or P2. Conditional Access needs P1.
• Network: allow *.certauth.login.microsoftonline.com alongside login.microsoftonline.com, and turn off TLS inspection for the certificate endpoint, or the client certificate request fails.

Step 1: Prepare the CRLs

CRL availability is the most common cause of CBA failures, so fix it first.

Find each CA's CRL distribution point. On a Windows Server CA you can read it from the CA properties or run:

certutil -cainfo cdp

Then check the limits Entra ID applies during interactive sign-in:

Microsoft's guidance:

• Publish a base CRL valid for days to weeks and a delta CRL valid for around 24 hours. If you configure both, both must be reachable and valid.
• Each new CRL must have a higher CRL Number than the last.
• Entra ID builds chains with the Subject Key Identifier, so the CA certificate's SKI must match the CRL's Authority Key Identifier.
• Host CRLs on highly available web servers or a CDN. An unreachable CRL blocks every sign-in that uses certificates from that CA.

Step 2: Create the PKI trust store and upload your CAs

1. Sign in to the Microsoft Entra admin center as a Privileged Authentication Administrator.
2. Open Public key infrastructure. Microsoft's current instructions place it under Entra ID > Identity Secure Score > Public key infrastructure.
3. Select Create PKI, enter a display name such as Contoso PKI, and select Create.
4. Open the PKI and add CAs in one of two ways:
   • Add certificate authority for each CA: upload the file, select Yes for a root or No for an intermediate, and enter the Certificate Revocation List URL and, if you publish one, the Delta Certificate Revocation List URL.
   • Upload PKI (P1 or P2): enter the internet-facing URL of a .p7b file containing the chain and its SHA-256 checksum. The upload is asynchronous and can take up to 30 minutes. Each CA's CRL endpoint is filled from the first HTTP CDP in the CA certificate; check and correct these afterwards.

Generate the checksum for the .p7b file:

Get-FileHash .\ContosoPKI.p7b -Algorithm SHA256

The PKI-based trust store supports up to 250 CAs, with 8 KB per CA object and a 2 MB PKI file. Upload every CA in the certification path up to the root; CBA fails if any is missing.

Issuer hints make the certificate picker show only certificates from your trusted CAs. Microsoft recommends setting the issuer hints flag only on CAs that issue user certificates. The feature itself is switched on by an Authentication Policy Administrator with the Issuer Hints checkbox in the CBA method settings, followed by I Acknowledge. With hints on, the endpoint becomes t<tenantId>.certauth.login.microsoftonline.com, so your TLS inspection bypass must match any name under certauth.login.microsoftonline.com. After you add, change or delete CAs, hints can take up to 10 minutes to propagate, and certificates from new CAs fail until they do.

If you used the older classic Certificate authorities store, remove those entries once the sign-in logs show Is Legacy Store Used as 0.

Step 3: Enable CBA for a pilot group

Scope matters more here than for most methods. A user in scope of CBA is considered MFA-capable, so if they don't actually have a certificate they can't use identity proofing to register other methods. Don't target All users.

1. Create a security group, for example CBA Pilot, containing users who already hold valid certificates.
2. Sign in as at least an Authentication Policy Administrator.
3. Go to Entra ID > Authentication methods > Certificate-based authentication.
4. On Enable and Target, select Enable, select I Acknowledge, choose Select groups > Add groups, add the pilot group and Save.

After this, every user sees the certificate option on the sign-in page, but only users in the group can complete CBA.

Step 4: Set the authentication binding

On the CBA method, select Configure.

1. Set the tenant default Protection level. If most of your certificates are PIN-protected smart card certificates, set it to Multifactor authentication. Set the default to whatever applies to most certificates and add rules only for exceptions; redundant rules can exceed the policy size limit.
2. Add rules for exceptions with Add rule. A rule can match on Certificate issuer, Policy OID, or both, and sets the protection level and affinity binding for matching certificates.

Rule precedence when rules overlap:

• Issuer-and-policy-OID rules win over policy-OID rules, which win over issuer rules.
• If a certificate carries two policy OIDs that map to different levels, it is treated as single-factor.
• A rule for a policy OID matches that exact OID; a derived credential with a longer OID doesn't inherit it.

Enter OIDs in dotted format. For example, a certificate showing All Issuance Policies must be entered as 2.5.29.32.0; the display string doesn't work.

Microsoft lists a known issue: rules that use both issuer and policy OID can affect Windows Hello for Business enrollment, FIDO2 security key registration and Windows passwordless phone sign-in. Until it's resolved, use rules based on the issuer or the policy OID alone.

Step 5: Map certificates to users

The default username binding maps the SAN Principal Name in the certificate to userPrincipalName. Entra ID supports seven certificate fields:

High-affinity bindings use identifiers that can't be reused, so only one specific certificate can sign in as the user. With several bindings configured, CBA is only as strong as the weakest one, so prefer a single high-affinity binding. Bindings are evaluated in priority order, which Microsoft Graph shows but the admin center doesn't.

certificateUserIds is multivalued: up to 10 values, each up to 1,024 characters, unique across the tenant. Values use prefixes such as X509:<SKI> and X509:<I>...<SR>..., which are case-sensitive.

• Cloud-only users: a Privileged Authentication Administrator edits them under the user's Authorization info in the admin center (up to four values of 120 characters there), through Microsoft Graph, or with the Microsoft Entra PowerShell module (1.0.6 or later), which reads the values from a certificate file:

Install-Module -Name Microsoft.Entra
Connect-Entra -Scopes 'Directory.ReadWrite.All', 'User.ReadWrite.All'
 
Get-EntraUserCertificateUserIdsFromCertificate -Path 'C:\certs\adele.cer'
 
Set-EntraUserCBACertificateUserId -UserId 'adele@contoso.com' `
    -CertPath 'C:\certs\adele.cer' -CertificateMapping @('SKI')

• Synchronized users: only Microsoft Entra Connect can write certificateUserIds. Populate altSecurityIdentities in Active Directory, add a multivalued alternativeSecurityId metaverse attribute, then create an inbound rule from altSecurityIdentities and an outbound rule to certificateUserIds. Anyone with delegated rights over synced users, or admin rights on the Connect server, can change these values.

To require high affinity, set Required Affinity Binding to High on the method, or create a rule for specific issuers or OIDs. Do this only after every in-scope user has the right certificateUserIds values; a tenant-wide high-affinity setting without them locks users out.

Step 6: Enforce CRL validation and scope CAs

By default, a CA uploaded without a CRL URL is accepted without revocation checking. Turn that off:

1. On the CBA method's Configure page, select Require CRL validation (recommended).
2. If a CA's CRL is temporarily broken, use Add Exemption for that CA only, and remove the exemption once it's fixed.

If several user populations use different CAs, the Certificate issuer scoping policy restricts each CA to a group: Add rule, pick the PKI and CA, Add group, acknowledge and save. You can assign one group per CA and up to 30 rules. A user outside the scoped group fails with error code 500189 even if the certificate is otherwise valid.

Step 7: Require phishing-resistant MFA

Create a Conditional Access policy for the pilot group targeting the apps you want to protect, with Grant > Require authentication strength > Phishing-resistant MFA, in report-only mode first. That built-in strength accepts multifactor CBA, FIDO2 security keys and Windows Hello for Business or platform credentials.

To require a certificate from a specific issuer or with a specific policy OID for a sensitive app, create a custom authentication strength and use its Advanced options for CBA. For how this fits into a broader design, see the zero trust remote access architecture.

Windows smart card sign-in

Users can sign in to Windows with a smart card directly against Entra ID on Microsoft Entra joined or hybrid joined devices, with no special client configuration, as long as the user is on managed authentication or in Staged Rollout; federated users aren't supported. The user gets a primary refresh token that carries the multifactor claim if the certificate is bound to MFA.

On Entra joined devices Windows uses the SAN Principal Name, then RFC822Name; if neither exists, the user must supply a user name hint in UPN format. On hybrid joined devices with a non-routable AD UPN, Entra ID also checks onPremisesUserPrincipalName. CBA isn't supported through the Windows Web sign-in option.

Verify

1. As a pilot user, browse to https://myapps.microsoft.com, enter the UPN, select Use a certificate or smart card, pick the certificate and confirm you're signed in.
2. In Sign-in logs, open the entry with status Interrupted and check Additional Details: User certificate binding, User certificate authentication level (multiFactorAuthentication when the binding works) and User certificate authentication level type (for example PolicyId).
3. Run Microsoft's trust store check from the MSIdentityTools module, Test-MsIdCBATrustStoreConfiguration, which reports common CA and CRL misconfigurations.

Troubleshooting

If CBA fails in a browser, close the browser session before retrying, because browsers cache the certificate choice. In Microsoft Edge, users can instead select the lock icon, Your certificate choices > Reset certificate choices.

Revoking access quickly

Because Entra ID caches CRLs until their next update, a newly revoked certificate isn't detected until the cache refreshes. When a smart card is lost or a user leaves, revoke the certificate and also revoke the user's sessions:

Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "adele@contoso.com"

Users who can't use their certificate, for example a new starter waiting for a card, can be issued a Temporary Access Pass; see the Temporary Access Pass onboarding guide.

Checklist

• CRLs for every CA published to internet-facing HTTP URLs, within size and time limits, with valid SKI and AKI.
• All CAs in the PKI-based trust store; classic store entries removed.
• Issuer hints on only for user-issuing CAs, with TLS inspection bypassed for certauth.login.microsoftonline.com.
• CBA targeted at groups of users who hold certificates, never All users.
• Protection level default and rules match your certificate types; no issuer-plus-OID rules while the known issue stands.
• High-affinity username binding with certificateUserIds populated.
• Require CRL validation on, with no lingering exemptions.
• Phishing-resistant MFA policy tested in report-only mode before enforcement.

References

• Microsoft Entra CBA overview
• Set up Microsoft Entra CBA
• Microsoft Entra CBA technical concepts
• Understand the CBA certificate revocation list
• How to configure certificate authorities for CBA
• Mapping to the certificateUserIds attribute
• Windows smart card sign-in using Microsoft Entra CBA
• Overview of Conditional Access authentication strengths
• user: revokeSignInSessions