Microsoft Entra certificate-based authentication technical concepts

This article describes technical concepts to explain how Microsoft Entra certificate-based authentication (CBA) works. Get the technical background to better know how to set up and manage Microsoft Entra CBA in your tenant.

How does Microsoft Entra certificate-based authentication work?

The following figure depicts what happens when a user tries to sign in to an application in a tenant that has Microsoft Entra CBA configured.

The following steps summarize the Microsoft Entra CBA process:

1. A user tries to access an application, such as the MyApps portal.

2. If the user isn't already signed in, they're redirected to the Microsoft Entra ID user sign-in page at https://login.microsoftonline.com/.

3. They enter their username on the Microsoft Entra sign-in page, and then select Next. Microsoft Entra ID completes home realm discovery by using the tenant name. It uses the username to look up the user in the tenant.

   

4. Microsoft Entra ID checks whether CBA is set up for the tenant. If CBA is set up, the user sees a link to Use a certificate or smart card on the password page. If the user doesn't see the sign-in link, make sure that CBA is set up for the tenant.

   For more information, see How do we turn on Microsoft Entra CBA?.

   Note

   If CBA is set up for the tenant, all users see the Use a certificate or smart card link on the password sign-in page. However, only users who are in scope for CBA can successfully authenticate for an application that uses Microsoft Entra ID as their identity provider.

   

   If you make other authentication methods available, like phone sign-in or security keys, your users might see a different sign-in dialog.

   

5. After the user selects CBA, the client redirects to the certificate authentication endpoint. For public Microsoft Entra ID, the certificate authentication endpoint is https://certauth.login.microsoftonline.com. For Azure Government, the certificate authentication endpoint is https://certauth.login.microsoftonline.us.

   The endpoint performs Transport Layer Security (TLS) mutual authentication and requests the client certificate as part of the TLS handshake. An entry for this request appears in the sign-in log.

   Note

   An administrator should allow access to the user sign-in page and to the *.certauth.login.microsoftonline.com certificate authentication endpoint for your cloud environment. Turn off TLS inspection on the certificate authentication endpoint to ensure that the client certificate request succeeds as part of the TLS handshake.

   Make sure that turning off TLS inspection also works for issuer hints with the new URL. Don't hard-code the URL with the tenant ID. The tenant ID might change for business-to-business (B2B) users. Use a regular expression to allow both the previous URL and the new URL to work when you turn off TLS inspection. For example, depending on the proxy, use *.certauth.login.microsoftonline.com or *certauth.login.microsoftonline.com. In Azure Government, use *.certauth.login.microsoftonline.us or *certauth.login.microsoftonline.us.

   Unless access is allowed, CBA fails if you turn on issuer hints.

6. Microsoft Entra ID requests a client certificate. The user selects the client certificate, and then selects OK.

   

7. Microsoft Entra ID verifies the certificate revocation list (CRL) to make sure that the certificate isn't revoked and that it's valid. Microsoft Entra ID identifies the user by using the username binding configured on the tenant to map the certificate field value to the user attribute value.

8. If a unique user is found via a Microsoft Entra Conditional Access policy that requires multifactor authentication (MFA) and the certificate authentication binding rule satisfies MFA, Microsoft Entra ID signs in the user immediately. If MFA is required but the certificate satisfies only a single factor, if the user is already registered, passwordless sign-in and FIDO2 are offered as second factors.

9. Microsoft Entra ID completes the sign-in process by sending a primary refresh token back to indicate successful sign-in.

If user sign-in is successful, the user can access the application.

Issuer hints (preview)

Issuer hints send back a trusted CA indicator as part of the TLS handshake. The trusted CA list is set to the subject of the CAs that the tenant uploads to the Microsoft Entra trust store. A browser client or native application client can use the hints that the server sends back to filter the certificates shown in the certificate picker. The client shows only the authentication certificates issued by the CAs in the trust store.

Turn on issuer hints

To turn on issuer hints, select the Issuer Hints checkbox. An Authentication Policy Administrator should select I Acknowledge after making sure that the proxy that has TLS inspection set up is updated correctly, and then save the changes.

CA trust store update propagation

After you turn on issuer hints and add, update, or delete CAs from the trust store, a delay of up to 10 minutes might occur while issuer hints propagate back to the client. An Authentication Policy Administrator should sign in with a certificate after issuer hints are made available to initiate propagation.

Users can't authenticate by using certificates that are issued by new CAs until hints are propagated. Users see the following error message when CA trust store updates are being propagated:

MFA with single-factor CBA

Microsoft Entra CBA qualifies for both first-factor authentication and second-factor authentication.

Here are some supported combinations:

• CBA (first factor) and passkeys (second factor)
• CBA (first factor) and passwordless phone sign-in (second factor)
• CBA (first factor) and FIDO2 security keys (second factor)
• Password (first factor) and CBA (second factor) (preview)

Users must have a way to get MFA and register passwordless sign-in or FIDO2 in advance of signing in by using Microsoft Entra CBA.

Options to get MFA capability with single-factor certificates

Microsoft Entra CBA can be either single-factor or multifactor depending on the tenant configuration. Turning on CBA makes a user potentially capable of completing MFA. A user that has a single-factor certificate must use another factor to complete MFA.

We don't allow registration of other methods without first satisfying MFA. If the user doesn't have any other MFA method registered and is in scope for CBA, the user can't use identity proof to register other authentication methods and get MFA.

If the CBA-capable user has only a single-factor certificate and needs to complete MFA, choose one of these options to authenticate the user:

• The user can enter a password and use a single-factor certificate.
• An Authentication Policy Administrator can issue a temporary access pass.
• An Authentication Policy Administrator can add a phone number and allow voice or text message authentication for the user account.

If the CBA-capable user hasn't been issued a certificate and needs to complete MFA, choose one of these options to authenticate the user:

• An Authentication Policy Administrator can issue a temporary access pass.
• An Authentication Policy Administrator can add a phone number and allow voice or text message authentication for the user account.

If the CBA-capable user can't use a multifactor certificate, such as if they're using a mobile device without smart card support but they need to complete MFA, choose one of these options to authenticate the user:

• An Authentication Policy Administrator can issue a temporary access pass.
• The user can register another MFA method (when the user can use a multifactor certificate on a device).
• An Authentication Policy Administrator can add a phone number and allow voice or text message authentication for the user account.

Set up passwordless phone sign-in with CBA

For passwordless phone sign-in to work, first turn off legacy notification through mobile app for the user.

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.

2. Complete the steps described in Enable passwordless phone sign-in authentication.

   Important

   Make sure that you select the Passwordless option. For any groups you add to passwordless phone sign-in, you must change the value for Authentication mode to Passwordless. If you select Any, CBA and passwordless sign-in don't work.

3. Select Entra ID > Multifactor authentication > Additional cloud-based multifactor authentication settings.

   

4. Under Verification options, clear the Notification through mobile app checkbox, and then select Save.

   

MFA authentication flow by using single-factor certificates and passwordless sign-in

Consider an example of a user who has a single-factor certificate and is configured for passwordless sign-in. As the user, you would complete these steps:

1. Enter your user principal name (UPN), and then select Next.

   

2. Select Use a certificate or smart card.

   

   If you make other authentication methods available, like phone sign-in or security keys, your users might see a different sign-in dialog.

   

3. In the client certificate picker, select the correct user certificate, and then select OK.

   

4. Because the certificate is configured to be the strength of single-factor authentication, you need a second factor to meet MFA requirements. Available second factors are shown in the sign-in dialog. In this case, it's passwordless sign-in. Select Approve a request on my Microsoft Authenticator app.

   

5. You get a notification on your phone. Select Approve sign-in?.

6. In Microsoft Authenticator, enter the number you see in the browser or app.

   

7. Select Yes, and you can authenticate and sign in.

Authentication binding policy

The authentication binding policy helps set the strength of authentication as either single-factor or multifactor. An Authentication Policy Administrator can change the default method from single-factor to multifactor. An admin also can set up custom policy configurations either by using IssuerAndSubject, PolicyOID, or Issuer and PolicyOID in the certificate.

Certificate strength

Authentication Policy Administrators can determine whether the certificate strength is single-factor or multifactor. For more information, see the documentation that maps NIST Authentication Assurance Levels to Microsoft Entra auth Methods, which builds upon NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt.

Multifactor certificate authentication

When a user has a multifactor certificate, they can perform MFA only by using certificates. However, an Authentication Policy Administrator should make sure that the certificates are protected by a PIN or biometric to be considered multifactor.

Multiple authentication policy binding rules

You can create multiple custom authentication binding policy rules by using different certificate attributes. An example is using the issuer and the policy OID, or just the policy OID, or just the issuer.

The following sequence determines the authentication protection level when custom rules overlap:

1. Issuer and policy OID rules take precedence over policy OID rules. Policy OID rules take precedence over certificate issuer rules.
2. Issuer and policy OID rules are evaluated first. If you have a custom rule with issuer CA1 and policy OID 1.2.3.4.5 with MFA, only certificate A that satisfies both the issuer value and the policy OID is given MFA.
3. Custom rules that use policy OIDs are evaluated. If you have a certificate A with policy OID of 1.2.3.4.5 and a derived credential B based on that certificate that has a policy OID of 1.2.3.4.5.6, and the custom rule is defined as a policy OID that has the value 1.2.3.4.5 with MFA, only certificate A satisfies MFA. Credential B satisfies only single-factor authentication. If the user used a derived credential during sign-in and was configured for MFA, the user is asked for a second factor for successful authentication.
4. If there's a conflict between multiple policy OIDs (such as when a certificate has two policy OIDs, where one binds to single-factor authentication and the other binds to MFA), then treat the certificate as single-factor authentication.
5. Custom rules that use issuer CAs are evaluated. If a certificate has matching policy OID and issuer rules, the policy OID is always checked first. If no policy rule is found, then the issuer bindings are checked. The policy OID has a higher strong-authentication binding priority than the issuer.
6. If one CA binds to MFA, all user certificates that the CA issues qualify as MFA. The same logic applies to single-factor authentication.
7. If one policy OID binds to MFA, all user certificates that include this policy OID as one of the OIDs qualify as MFA. (A user certificate can have multiple policy OIDs.)
8. One certificate issuer can only have one valid strong-authentication binding (that is, a certificate can't bind to both single-factor authentication and to MFA).

Username binding policy

The username binding policy helps validate the certificate of the user. By default, the subject alternative name (SAN) Principal Name in the certificate is mapped to the userPrincipalName attribute of the user object to identify the user.

Achieve higher security by using certificate bindings

Microsoft Entra support seven methods for using certificate bindings. In general, mapping types are considered high affinity if they're based on identifiers that you can't reuse, such as SubjectKeyIdentifier (SKI) or SHA1PublicKey. These identifiers convey a higher assurance that only a single certificate can be used to authenticate a user.

Mapping types based on usernames and email addresses are considered low affinity. Microsoft Entra ID implements three mappings that are considered low-affinity based on reusable identifiers. The others are considered high-affinity bindings. For more information, see certificateUserIds.

Define and override affinity binding

An Authentication Policy Administrator can configure whether users can authenticate by using low-affinity or high-affinity username binding mapping.

Set Required affinity binding for the tenant, which applies to all users. To override the tenant-wide default value, create custom rules based on the issuer and the policy OID, or just the policy OID, or just the issuer.

Multiple username policy binding rules

To resolve multiple username policy binding rules, Microsoft Entra ID uses the highest priority (lowest number) binding:

1. Looks up the user object by using the username or UPN.
2. Gets the list of all username bindings set up by the Authentication Policy Administrator in the CBA method configuration ordered by the priority attribute. Currently, priority isn't shown in the admin center. Microsoft Graph returns the priority attribute for each binding. Then, priorities are used in the evaluation process.
3. If the tenant has high-affinity binding configured or if the certificate value matches a custom rule that requires high-affinity binding, removes all the low-affinity bindings from the list.
4. Evaluates each binding in the list until a successful authentication occurs.
5. If the X.509 certificate field of the configured binding is on the presented certificate, Microsoft Entra ID matches the value in the certificate field to the user object attribute value.
   • If a match is found, user authentication is successful.
   • If a match isn't found, moves to the next priority binding.
6. If the X.509 certificate field isn't on the presented certificate, moves to the next priority binding.
7. Validates all configured username bindings until one of them results in a match and user authentication is successful.
8. If a match isn't found on any of the configured username bindings, user authentication fails.

Secure Microsoft Entra configuration by using multiple username bindings

Each of the Microsoft Entra user object attributes available to bind certificates to Microsoft Entra user accounts (userPrincipalName, onPremiseUserPrincipalName, and certificateUserIds) has a unique constraint to ensure that a certificate only matches a single Microsoft Entra user account. However, Microsoft Entra CBA supports multiple binding methods in the username binding policy. An Authentication Policy Administrator can accommodate one certificate used in multiple Microsoft Entra user accounts configurations.

For example, you have two username bindings on PrincipalName mapped to UPN, and SubjectKeyIdentifier (SKI) is mapped to certificateUserIds. If you want a certificate to be used for only a single account, an Authentication Policy Administrator must make sure that the account has the UPN that is present in the certificate. Then, the admin implements the SKI mapping in the certificateUserIds attribute of the same account.

Support for multiple certificates with one Microsoft Entra user account (M:1)

In some scenarios, an organization issues multiple certificates for a single identity. It might be a derived credential for a mobile device, but it also might be for a secondary smart card or X.509 credential holder-capable device such as a YubiKey.

Cloud-only accounts (M:1)

For cloud-only accounts, you can map up to five certificates to use by populating the certificateUserIds field with unique values to identify each certificate. To map the certificates, in the admin center, go to the Authorization info tab.

If the organization uses high-affinity bindings like IssuerAndSerialNumber, values in certificateUserIds might look like the following example:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

In this example, the first value represents X509Certificate1. The second value represents X509Certificate2. The user can present either certificate at sign-in. If the CBA username binding is set to point to the certificateUserIds field to look for the specific binding type (in this example, IssuerAndSerialNumber), the user successfully signs in.

Hybrid synchronized accounts (M:1)

For synchronized accounts, you can map multiple certificates. In on-premises Active Directory, populate the altSecurityIdentities field with the values that identify each certificate. If your organization uses high-affinity bindings (that is, strong authentication) like IssuerAndSerialNumber, the values might look like these examples:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

In this example, the first value represents X509Certificate1. The second value represents X509Certificate2. The values must then be synced to the certificateUserIds field in Microsoft Entra ID.

Support for one certificate with multiple Microsoft Entra user accounts (1:M)

In some scenarios, an organization requires a user to use the same certificate to authenticate into multiple identities. It might be for an administrative account or for a developer or temporary duty account.

In on-premises Active Directory, the altSecurityIdentities field populates the certificate values. A hint is used during sign-in to direct Active Directory to the intended account to check for sign-in.

Microsoft Entra CBA has a different process, and no hint is included. Instead, Home realm discovery identifies the intended account and checks the certificate values. Microsoft Entra CBA also enforces uniqueness in the certificateUserIds field. Two accounts can't populate the same certificate values.

Cloud-only accounts (1:M)

For cloud-only accounts, create multiple username bindings and map unique values to each user account that uses the certificate. Access to each account is authenticated by using a different username binding. This authentication level applies to the boundary of a single directory or tenant. An Authentication Policy Administrator can map the certificate to use it in another directory or tenant if the values remain unique per account.

Populate the certificateUserIds field with a unique value that identifies the certificate. To populate the field, in the admin center, go to the Authorization info tab.

If the organization uses high-affinity bindings (that is, strong authentication) like IssuerAndSerialNumber and SKI, the values might look like the following example:

Username bindings:

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

User account certificateUserIds values:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Now, when either user presents the same certificate at sign-in, the user successfully signs in because their account matches a unique value on that certificate. One account is authenticated by using IssuerAndSerialNumber and the other by using SKI binding.

Hybrid synchronized accounts (1:M)

Synchronized accounts require a different approach. Although an Authentication Policy Administrator can map unique values to each user account that uses the certificate, the common practice of populating all values to each account in Microsoft Entra ID makes this approach difficult. Instead, Microsoft Entra Connect should filter the values per account to unique values populated into the account in Microsoft Entra ID. The uniqueness rule applies to the boundary of a single directory or tenant. An Authentication Policy Administrator can map the certificate to use it in another directory or tenant if the values remain unique per account.

The organization might also have multiple Active Directory forests that contribute users to a single Microsoft Entra tenant. In this case, Microsoft Entra Connect applies the filter to each of the Active Directory forests with the same goal: populate only a specific, unique value to the cloud account.

Populate the altSecurityIdentities field in Active Directory with the values that identify the certificate. Include the specific certificate value for that user account type (such as detailed, admin, or developer). Select a key attribute in Active Directory. The attribute tells synchronization which user account type the user is evaluating (such as msDS-cloudExtensionAttribute1). Populate this attribute with the user type value you want to use, such as detailed, admin, or developer. If the account is the user’s primary account, the value can be empty or NULL.

Check that the accounts look similar to these examples:

Forest 1: Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forest 1: Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forest 2: ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

You must then sync these values to the certificateUserIds field in Microsoft Entra ID.

To sync to certificateUserIds:

1. Configure Microsoft Entra Connect to add the alternativeSecurityIds field to the metaverse.
2. For each on-premises Active Directory forest, configure a new custom inbound rule with a high precedence (a low number, below 100). Add an Expression transform with the altSecurityIdentities field as the source. The target expression uses the key attribute that you selected and populated, and it uses the mapping to the user types you defined.

For example:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

In this example, altSecurityIdentities and the key attribute msDS-cloudExtensionAttribute1 are first checked to see if they're populated. If they aren't populated, altSecurityIdentities is checked to see if it's populated. If it's empty, set it to NULL. Otherwise, the account is a default scenario.

Also in this example, filter only on the IssuerAndSerialNumber mapping. If the key attribute is populated, then the value is checked to see if it's equal to one of your defined user types. In the example, if that value is detailed, filter on the SHA1PublicKey value from altSecurityIdentities. If the value is developer, filter on the SubjectKeyIssuer value from altSecurityIdentities.

You might encounter multiple certificate values of a specific type. For example, you might see multiple PrincipalName values or multiple SKI or SHA1-PUKEY values. The filter gets all the values and syncs them in Microsoft Entra ID, not just the first one that it finds.

Here's a second example that shows how to push an empty value if the control attribute is empty:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

If the value in altSecurityIdentities doesn't match any of the search values in the control attribute, an AuthoritativeNull value is passed. This value ensures that prior or subsequent rules that populate alternativeSecurityId are ignored. The result is empty in Microsoft Entra ID.

To sync an empty value:

1. Configure a new custom outbound rule with a low precedence (a high number, above 160 but from the bottom of the list).
2. Add a direct transform with the alternativeSecurityIds field as the source and the certificateUserIds field as the target.
3. Run a synchronization cycle to complete data population in Microsoft Entra ID.

Ensure that CBA in each tenant is configured with the username bindings pointing to the certificateUserIds field for the field types that you mapped from the certificate. Now any of these users can present the certificate at sign-in. After the unique value from the certificate is validated against the certificateUserIds field, the user is successfully signed in.

Certificate revocation process

The certificate revocation process allows an Authentication Policy Administrator to revoke a previously issued certificate from being used for future authentication. Certificate revocation doesn't revoke tokens that are already issued to the user. To manually revoke tokens, complete the steps described in Configure revocation.

Microsoft Entra ID downloads and caches your CRL from your CA to check whether certificates are revoked when the user authenticates.

An Authentication Policy Administrator can configure the CRL distribution point during the setup process for trusted issuers in the Microsoft Entra tenant. Each trusted issuer should have a CRL that can be referenced by using an internet-facing URL.

When a user performs an interactive sign-in with a certificate and the CRL exceeds the interactive limit for a cloud, initial sign-in fails and shows the following error message:

"The Certificate Revocation List (CRL) downloaded from <URI> has exceeded the maximum allowed size (<size> bytes) for CRLs in Microsoft Entra ID. Try again in few minutes. If the issue persists, contact your tenant administrators."

After the error, Microsoft Entra ID attempts to download the CRL subject to the service-side limits (45 MB in public Microsoft Entra ID and 150 MB in Azure US Government clouds).

Currently, we don't support Online Certificate Status Protocol (OCSP) for performance and reliability reasons. Instead of downloading the CRL for OCSP at each connection with the client browser, Microsoft Entra ID downloads it once at the first sign-in, and then caches it. This approach improves the performance and reliability of CRL verification. We also index the cache so that the search is faster. You must publish your CRLs for certificate revocation.

The following steps describe the typical flow for a CRL check:

1. Microsoft Entra ID attempts to download the CRL at the first sign-in event of any user with a certificate of the corresponding trusted issuer or CA.

2. Microsoft Entra ID caches and reuses the CRL for any subsequent usage. It honors the Next update date value and, if available, the Next CRL Publish date value (used by Windows Server CAs) in the CRL document.

   

3. User CBA fails if:

   • A CRL is configured for the trusted issuer and Microsoft Entra ID can't download the CRL, due to availability, size, or latency constraints.
   • The user's certificate is listed as revoked on the CRL.
   • Microsoft Entra ID attempts to download a new CRL from the distribution point if the cached CRL document is expired.

Currently, you can't manually force or retrigger a CRL download.

Configure revocation

To revoke a client certificate, Microsoft Entra ID fetches the certificate revocation list (CRL) from the URLs uploaded as part of certificate authority information and caches it. The last publish timestamp (Effective Date property) in the CRL is used to ensure the CRL is still valid. The CRL is periodically referenced to revoke access to certificates that are a part of the list.

If a more instant revocation is required (for example, if a user loses a device), the authorization token of the user can be invalidated. To invalidate the authorization token, set the StsRefreshTokensValidFrom field for this particular user using Windows PowerShell. You must update the StsRefreshTokensValidFrom field for each user you want to revoke access for.

To ensure that the revocation persists, you must set the Effective Date of the CRL to a date after the value set by StsRefreshTokensValidFrom and ensure the certificate in question is in the CRL.

The following steps outline the process for updating and invalidating the authorization token by setting the StsRefreshTokensValidFrom field.

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

The date you set must be in the future. If the date is not in the future, the StsRefreshTokensValidFrom property is not set. If the date is in the future, StsRefreshTokensValidFrom is set to the current time (not the date indicated by Set-MsolUser command).

CRL validation

A CRL is a record of digital certificates that have been revoked by a CA before the end of their validity period.

When CAs are uploaded to the Microsoft Entra trust store, a CrlDistributionPoint attribute isn't required. You can upload a CA without a CRL endpoint. CBA doesn't fail if an issuing CA doesn't specify a CRL.

To strengthen security and avoid misconfigurations, an Authentication Policy Administrator can require CBA authentication to fail if no CRL is configured for a CA that issues a user certificate.

Turn on CRL validation

To turn on CRL validation, select the Require CRL validation (recommended) checkbox.

After you turn on CRL validation, any CBA failure occurs because the user certificate was issued by a CA that doesn't have a CRL configured.

An Authentication Policy Administrator can exempt a CA if its CRL has issues that to fix. Select Add Exemption, and then select any CAs to exempt.

The CAs in the exempted list aren't required to have a CRL configured, and the user certificates they issue don't fail authentication.

Select CAs and select Add. You can use Search to filter the CA lists to select specific CAs.

CA scoping (preview)

CA scoping in Microsoft Entra allows tenant administrators to restrict the use of specific CAs to defined user groups. This feature enhances the security and manageability of CBA by ensuring that only authorized users can authenticate by using certificates issued by specific CAs.

CA scoping is useful in multi-PKI or B2B scenarios where multiple CAs are used across different user populations. It helps prevent unintended access and supports compliance with organizational policies.

Key benefits

• Restricts certificate use to specific user groups
• Supports complex PKI environments through multiple CAs
• Provides enhanced protection against certificate misuse or compromise
• Gives visibility into CA usage via sign-in logs and monitoring tools

An admin can use CA scoping to define rules that associate a CA (identified by its SKI) with a specific Microsoft Entra group. When a user attempts to authenticate by using a certificate, the system checks whether the issuing CA for the certificate is scoped to a group that includes the user. Microsoft Entra proceeds up the CA chain. It applies all scope rules until the user is found in one of the groups in all the scope rules. If the user isn't in the scoped group, authentication fails, even if the certificate is otherwise valid.

Set up the CA scoping feature

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.

2. Go to Entra ID > Authentication methods > Certificate-based authentication.

3. Under Configure, go to Certificate issuer scoping policy.

   

4. Select Add rule.

   

5. Select Filter CAs by PKI.

   Classic CAs shows all the CAs from the classic CA store. Selecting a specific PKI shows all the CAs from the selected PKI.

6. Select a PKI.

   

7. The Certificate issuer list shows all the CAs from the selected PKI. Select a CA to create a scope rule.

   

8. Select Add group.

   

9. Select a group.

   

10. Select Add to save the rule.

    

11. Select the I Acknowledge checkbox, and then select Save.

    

12. To edit or delete a CA scoping policy, select "..." on the rule row. To edit the rule, select Edit. To delete the rule, select Delete.

    

Known limitations

• Only one group can be assigned per CA.
• A maximum of 30 scoping rules is supported.
• Scoping is enforced at the intermediate CA level.
• Improper configuration might result in user lockouts if no valid scoping rules exist.

Sign-in log entries

• The sign-in log shows success. On the Additional Details tab, the SKI of the CA from the scoping policy rule appears.

  

• When a CBA fails due to a CA scoping rule, the Basic info tab in the sign-in log shows the error code 500189.

  

  End users see the following error message:

  

How CBA works with a Conditional Access authentication strength policy

You can use the built-in Microsoft Entra Phishing-resistant MFA authentication strength to create a Conditional Access authentication policy that specifies to use CBA to access a resource. The policy allows only authentication methods that are phishing-resistant, like CBA, FIDO2 security keys, and Windows Hello for Business.

You can also create a custom authentication strength to allow only CBA to access sensitive resources. You can allow CBA as single-factor authentication, MFA, or both. For more information, see Conditional Access authentication strength.

CBA strength with advanced options

In the CBA method policy, an Authentication Policy Administrator can determine the strength of the certificate by using an authentication binding policy on the CBA method. Now you can require a specific certificate to be used based on issuer and policy OIDs when users perform CBA to access certain sensitive resources. When you create a custom authentication strength, go to Advanced options. The feature provides a more precise configuration to determine the certificates and users that can access resources. For more information, see Advanced options for Conditional Access authentication strength.

Sign-in logs

Sign-in logs provide information about sign-ins and how your resources are used in the organization. For more information, see Sign-in logs in Microsoft Entra ID.

Next, consider two scenarios. In one scenario, the certificate satisfies single-factor authentication. In the second scenario, the certificate satisfies MFA.

For the test scenarios, select a user who has a Conditional Access policy that requires MFA.

Configure the user binding policy by mapping Subject Alternative Name and Principal Name to the userPrincipalName user object.

The user certificate should be configured like the example shown in this screenshot:

Troubleshoot sign-in issues with dynamic variables in sign-in logs

Although sign-in logs typically provide all the information you need to debug a sign-in issue, sometimes specific values are required. Sign-in logs don't support dynamic variables, so in some cases, the sign-in logs don't have the information you need for debugging.

For example, the failure reason in the sign-in logs might show "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." In this scenario,<expectedSKI> and <crlAKI> aren't populated with correct values.

When user sign-in with CBA fails, you can copy the log details from the More Details link on the error page. For more information, see Understanding the CBA error page.

Test single-factor authentication

For the first test scenario, configure the authentication policy where the IssuerAndSubject rule satisfies single-factor authentication.

1. Sign in to the Microsoft Entra admin center as the test user by using CBA. The authentication policy is set where the IssuerAndSubject rule satisfies single-factor authentication.

2. Search for and then select Sign-in logs.

   The next figure shows some of the entries you can find in the sign-in logs.

   The first entry requests the X.509 certificate from the user. The Interrupted status means that Microsoft Entra ID validated that CBA is set up for the tenant. A certificate is requested for authentication.

   

   Activity Details shows that the request is part of the expected sign-in flow in which the user selects a certificate.

   

   Additional Details shows the certificate information.

   

   The other entries show that the authentication is complete, a primary refresh token is sent back to the browser, and the user is granted access to the resource.

   

Test MFA

For the next test scenario, configure the authentication policy where the policyOID rule satisfies MFA.

1. Sign in to the Microsoft Entra admin center by using CBA. Because the policy was set to satisfy MFA, the user sign-in is successful without a second factor.

2. Search for and then select Sign-ins.

   Several entries in the sign-in logs appear, including an entry with an Interrupted status.

   

   Activity Details shows that the request is part of the expected sign-in flow in which the user selects a certificate.

   

   The entry with an Interrupted status displays more diagnostic information on the Additional Details tab.

   

   The following table has a description of each field.

   Field	Description
   User certificate subject name	Refers to the subject name field in the certificate.
   User certificate binding	Certificate: PrincipalName; user attribute: userPrincipalName; Rank: 1 This field shows which SAN PrincipalName certificate field was mapped to the userPrincipalName user attribute and was priority 1.
   User certificate authentication level	multiFactorAuthentication
   User certificate authentication level type	PolicyId This field shows that the policy OID was used to determine the authentication strength.
   User certificate authentication level identifier	1.2.3.4 This shows the value of the identifier policy OID from the certificate.

CBA error page

CBA might fail for multiple reasons. Examples include an invalid certificate, the user selected the wrong certificate or an expired certificate, or a CRL issue occurs. When certificate validation fails, the user sees this error message:

If CBA fails on a browser, even if the failure is because you cancel the certificate picker, close the browser session. Open a new session to try CBA again. A new session is required because browsers cache certificates. When CBA is retried, the browser sends a cached certificate during the TLS challenge, which then causes sign-in failure and the validation error.

1. To get logging information to send to an Authentication Policy Administrator for more information from the sign-in logs, select More details.

   

2. Select Other ways to sign in and try other available authentication methods to sign in.

   

Reset the certificate choice in Microsoft Edge

The Microsoft Edge browser added a feature that resets the certificate selection without restarting the browser.

The user completes the following steps:

1. When CBA fails, the error page appears.

   

2. To the left of the address URL, select the lock icon, and then select Your certificate choices.

   

3. Select Reset certificate choices.

   

4. Select Reset choices.

   

5. Select Other ways to sign in.

   

6. Select Use a certificate or smart card and continue with CBA authentication.

CBA in MostRecentlyUsed methods

After a user authenticates successfully by using CBA, the user's MostRecentlyUsed (MRU) authentication method is set to CBA. The next time the user enters their UPN and selects Next, they see the CBA method and don't need to select Use the certificate or smart card.

To reset the MRU method, cancel the certificate picker, and then select Other ways to sign in. Select another available method, and then complete authentication.

The MRU authentication method is set at the user level. If a user successfully signs in on a different device by using a different authentication method, the MRU is reset for the user to the currently signed-in method.

External identity support

An external identity B2B guest user can use CBA on the home tenant. If the cross-tenant settings for the resource tenant are set up to trust MFA from the home tenant, the user's CBA on the home tenant is honored. For more information, see Configure B2B collaboration cross-tenant access. Currently, CBA on a resource tenant isn't supported.

Related content

• Overview of Microsoft Entra CBA
• Set up Microsoft Entra CBA
• Microsoft Entra CBA on iOS devices
• Microsoft Entra CBA on Android devices
• Windows smart card sign-in by using Microsoft Entra CBA
• Certificate user IDs
• Migrate federated users
• FAQ
• Troubleshoot Microsoft Entra CBA