Microsoft's edit · Certificate authentication bindings and limitations

11 ---

2 −title: Microsoft Entra certificate-based authentication technical deep dive

3 −description: Learn how Microsoft Entra certificate-based authentication works

2 +title: Microsoft Entra CBA Technical Concepts

3 +description: Learn how Microsoft Entra certificate-based authentication (CBA) works and the technical concepts you need to set up and manage CBA.

44 ms.service: entra-id

55 ms.subservice: authentication

6 −ms.topic: how-to

6 +ms.topic: concept-article

77 ms.date: 03/04/2025

88 ms.author: justinha

99 author: vimrang

1313 ms.localizationpriority: high

1414 ---

1515

16 −# Microsoft Entra certificate-based authentication technical deep dive

17 −

18 −This article explains how Microsoft Entra certificate-based authentication (CBA) works, and dives into technical details on Microsoft Entra CBA configurations.

16 +# Microsoft Entra certificate-based authentication technical concepts

1917

20 −<a name='how-does-microsoft-entra-certificate-based-authentication-work'></a>

18 +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.

2119

2220 ## How does Microsoft Entra certificate-based authentication work?

2321

24 −The following image describes what happens when a user tries to sign in to an application in a tenant where Microsoft Entra CBA is enabled.

22 +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.

2523

26 −:::image type="content" border="false" source="./media/concept-certificate-based-authentication-technical-deep-dive/how-it-works.png" alt-text="Illustration with steps about how Microsoft Entra certificate-based authentication works." :::

24 +:::image type="content" border="false" source="./media/concept-certificate-based-authentication-technical-deep-dive/how-it-works.png" alt-text="Diagram that shows an overview of the steps in Microsoft Entra certificate-based authentication." :::

2725

28 −What follows are the steps to take:

26 +The following steps summarize the Microsoft Entra CBA process:

2927

30 −1. The user tries to access an application, such as [MyApps portal](https://myapps.microsoft.com/).

31 −1. If the user isn't already signed in, the user is redirected to the Microsoft Entra ID **User Sign-in** page at [https://login.microsoftonline.com/](https://login.microsoftonline.com/).

32 −1. The user enters their username into the Microsoft Entra sign-in page, and then selects **Next**. Microsoft Entra ID does home realm discovery using the tenant name and the username is used to look up the user in the tenant.

33 −␣␣␣

34 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in.png" alt-text="Screenshot of the Sign-in for MyApps portal.":::

28 +1. A user tries to access an application, such as the [MyApps portal](https://myapps.microsoft.com/).

29 +1. 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/`.

30 +1. 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.

31 +

32 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in.png" alt-text="Screenshot that shows the sign-in page for the MyApps portal.":::

3533

36 −1. Microsoft Entra ID checks whether CBA is enabled for the tenant. If CBA is enabled, the user sees a link to **Use a certificate or smartcard** on the password page. If the user doesn't see the sign-in link, make sure CBA is enabled on the tenant. For more information, see [How do I enable Microsoft Entra CBA?](./certificate-based-authentication-faq.yml#how-can-an-administrator-enable-microsoft-entra-cba-).

37 −

38 − >[!NOTE]

39 − > If CBA is enabled on the tenant, all users see the link to **Use a certificate or smart card** on the password page. However, only the users in scope for CBA can authenticate successfully against an application that uses Microsoft Entra ID as their Identity provider (IdP).

34 +1. Microsoft Entra ID checks whether CBA is enabled for the tenant. If CBA is enabled, 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 enabled on the tenant.

4035

41 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-cert.png" alt-text="Screenshot of the Use a certificate or smart card.":::

36 + For more information, see [How do I enable Microsoft Entra CBA?](./certificate-based-authentication-faq.yml#how-does-an-administrator-enable-microsoft-entra-cba-).

4237

43 − If you enabled other authentication methods like **Phone sign-in** or **Security keys**, users might see a different sign-in screen.

38 + > [!NOTE]

39 + > 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.

4440

45 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-alt.png" alt-text="Screenshot of the Sign-in if FIDO2 is also enabled.":::

41 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-cert.png" alt-text="Screenshot that shows the option to use a certificate or smart card.":::

4642

47 −1. Once the user selects certificate-based authentication, the client is redirected to the certauth endpoint, which is [https://certauth.login.microsoftonline.com](https://certauth.login.microsoftonline.com) for public Microsoft Entra ID. For [Azure Government](/azure/azure-government/compare-azure-government-global-azure#guidance-for-developers), the certauth endpoint is [https://certauth.login.microsoftonline.us](https://certauth.login.microsoftonline.us).

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

4844

49 − <!---

50 − If you enable issuer hints, the certauth endpoint is `https://t{tenantid}.certauth.login.microsoftonline.com`.

51 − --->

45 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-alt.png" alt-text="Screenshot that shows the sign-in dialog if FIDO2 authentication is also available.":::

5246

53 − The endpoint performs 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.

47 +1. 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](/azure/azure-government/compare-azure-government-global-azure#guidance-for-developers), the certificate authentication endpoint is `https://certauth.login.microsoftonline.us`.

5448

55 − >[!NOTE]

56 − >The network administrator should allow access to the User sign-in page and certauth endpoint `*.certauth.login.microsoftonline.com` for the customer's cloud environment. Disable TLS inspection on the certauth endpoint to make sure the client certificate request succeeds as part of the TLS handshake.

49 + 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.

5750

58 − Make sure your TLS inspection disablement also works for the new url with issuer hints. Don't hardcode the url with tenantId because it might change for B2B users. Use a regular expression to allow both the old and new URL to work for TLS inspection disablement. 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`.

51 + > [!NOTE]

52 + > 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.

53 + >

54 + > 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`.

5955

60 − Unless access is allowed, certificate-based authentication fails if you enable [issuer hints](#understanding-issuer-hints-preview).

56 + Unless access is allowed, CBA fails if you enable [issuer hints](#issuer-hints-preview).

6157

62 −1. Microsoft Entra ID requests a client certificate. The user picks the client certificate, and selects **Ok**.

58 +1. Microsoft Entra ID requests a client certificate. The user selects the client certificate, and then selects **OK**.

6359

64 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png" alt-text="Screenshot of the certificate picker." lightbox="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png":::

60 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png" alt-text="Screenshot that shows the certificate picker." lightbox="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png":::

6561

66 −1. Microsoft Entra ID verifies the certificate revocation list to make sure the certificate isn't revoked and is valid. Microsoft Entra ID identifies the user by using the [username binding configured](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy) on the tenant to map the certificate field value to the user attribute value.

67 −1. If a unique user is found with a Conditional Access policy that requires multifactor authentication, and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy) satisfies MFA, then Microsoft Entra ID signs the user in immediately. If MFA is required but the certificate satisfies only a single factor, either passwordless sign-in or FIDO2 is offered as a second factor if they're already registered.

62 +1. 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](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy) on the tenant to map the certificate field value to the user attribute value.

63 +1. If a unique user is found via a Microsoft Entra Conditional Access policy that requires MFA and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-an-authentication-binding-policy) 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.

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

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

7065

71 −## Understanding issuer hints (Preview)

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

7267

73 −Issuer hints send back a Trusted CA Indication as part of the TLS handshake. The trusted CA list is set to subject of the Certificate Authorities (CAs) uploaded by the tenant in the Entra trust store. A browser client or native application client can use the hints sent back by server to filter the certificates shown in the certificate picker. The client shows only the authentication certificates issued by the CAs in the trust store.

68 +## Issuer hints (preview)

7469

75 −### Enable issuer hints

70 +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.

7671

77 −To enable select on the check box **Issuer Hints**. [Authentication Policy Administrators](../role-based-access-control/permissions-reference.md#authentication-policy-administrator) should select **I acknowledge** after making sure that the proxy with TLS inspection enabled is updated correctly, and save.

72 +### Enable issuer hints

7873

79 −>[!NOTE]

80 −>If your organization has firewalls or proxies with TLS inspection, acknowledge that you disabled TLS inspection of the certauth endpoint capable of matching any name under `[*.]certauth.login.microsoftonline.com`, customized according to the specific proxy in use.

74 +To enable issuer hints, select the **Issuer Hints** checkbox. An [Authentication Policy Administrator](../role-based-access-control/permissions-reference.md#authentication-policy-administrator) should select **I Acknowledge** after making sure that the proxy with TLS inspection enabled is updated correctly, and then save the changes.

8175

76 +> [!NOTE]

77 +> If your organization has firewalls or proxies that use TLS inspection, acknowledge that you disabled TLS inspection of the CA endpoint that is capable of matching any name under `[*.]certauth.login.microsoftonline.com`, customized according to the specific proxy in use.

8278

83 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/issuer-hints.png" alt-text="Screenshot of how to enable issuer hints.":::

79 +:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/issuer-hints.png" alt-text="Screenshot that shows how to enable issuer hints." lightbox="media/concept-certificate-based-authentication-technical-deep-dive/issuer-hints.png":::

8480

85 −>[!Note]

86 −>The certificate authority URL is in the format `t{tenantId}.certauth.login.microsoftonline.com` after issuer hints are enabled.

81 +> [!NOTE]

82 +> After issuer hints are enabled, the CA URL has the format `<tenantId>.certauth.login.microsoftonline.com`.

8783

88 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/issuer-hints-picker.png" alt-text="Screenshot of the certificate picker after issuer hints are enabled.":::

84 +:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/issuer-hints-picker.png" alt-text="Screenshot that shows the certificate picker after issuer hints are enabled.":::

8985

9086 ### CA trust store update propagation

9187

92 −After you enable issuer hints and add, update, or delete CAs from the trust state, there's a delay of up to 10 minutes to propagate the issuer hints back to client. Users can't authenticate with certificates issued by the new CAs until the hints are propagated.

88 +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.

9389

94 −Authentication Policy Administrators should sign in with a certificate after they enable issuer hints to initiate the propagation. Users see the following error message when CA trust store updates are in propagation.

90 +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:

9591

96 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/propagation-error.png" alt-text="Screenshot of an error users see if updates are in progress.":::

92 +:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/propagation-error.png" alt-text="Screenshot that shows the error users see if updates are in progress.":::

9793

98 −## MFA with single-factor certificate-based authentication

94 +## MFA with single-factor CBA

9995

100 −Microsoft Entra CBA is supported as both first factor and second factor for authentication.

101 −Some of the supported combinations are:

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

10297

103 −1. CBA (first factor) and [passkeys](../authentication/how-to-enable-authenticator-passkey.md) (second factor)

104 −1. CBA (first factor) and [passwordless phone sign-in](../authentication/howto-authentication-passwordless-phone.md#enable-passwordless-phone-sign-in-authentication-methods) (second factor)

105 −1. CBA (first factor) and [FIDO2 security keys](../authentication/howto-authentication-passwordless-security-key-windows.md) (second factor)

106 −1. Password (first factor) + CBA (second factor) (Preview)

98 +Here are some supported combinations:

10799

108 −>[!Note]

109 −>CBA as a second factor on iOS has [known issues](./concept-certificate-based-authentication-mobile-ios.md#known-issues) and is blocked on iOS. We are working on fixing the issues and should be supported on iOS.

100 +- CBA (first factor) and [passkeys](../authentication/how-to-enable-authenticator-passkey.md) (second factor)

101 +- CBA (first factor) and [passwordless phone sign-in](../authentication/howto-authentication-passwordless-phone.md#enable-passwordless-phone-sign-in-authentication-methods) (second factor)

102 +- CBA (first factor) and [FIDO2 security keys](../authentication/howto-authentication-passwordless-security-key-windows.md) (second factor)

103 +- Password (first factor) and CBA (second factor) (preview)

110104

111 −Users need to have a way to get MFA and register passwordless sign-in or FIDO2 in advance to signing in with Microsoft Entra CBA.

105 +> [!NOTE]

106 +> Currently, using CBA as a second factor on iOS has [known issues](./concept-certificate-based-authentication-mobile-ios.md#known-issues) and is blocked on iOS. We're working to resolve the issues.

112107

113 −>[!IMPORTANT]

114 −>A user is considered MFA capable when they're included in the CBA method settings. This means the user can't use proof up as part of their authentication to register other available methods. Make sure users without a valid certificate aren't included in the CBA method settings. For more information about how authentication works, see [Microsoft Entra multifactor authentication](../authentication/concept-mfa-howitworks.md).

108 +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.

115109

116 −## Options to get MFA capability with Single factor certificates

110 +> [!IMPORTANT]

111 +> A user is considered MFA capable if their username appears in the CBA method settings. In this scenario, the user can't use their identity as part of their authentication to register other available methods. Make sure that users without a valid certificate aren't included in the CBA method settings. For more information about how authentication works, see [Microsoft Entra multifactor authentication](../authentication/concept-mfa-howitworks.md).

117112

118 −Microsoft Entra CBA is capable of multifactor authentication (MFA). Microsoft Entra CBA can be either single-factor (SF) or multifactor (MF) depending on the tenant configuration. Enabling CBA makes a user potentially capable to complete MFA. A user with single factor certificate needs another factor to complete MFA which is why we will not allow registration of other methods without satisfying MFA. If the user doesn't have any other MFA auth method registered and are added into scope for CBA auth method, the user can't proof up to register other authentication methods and get MFA.

113 +## Options to get MFA capability with single-factor certificates

119114

120 −If the CBA-enabled user only has a Single Factor (SF) certificate and needs to complete MFA:

121 − 1. Use a password and SF certificate (OR)

122 − 1. Authentication Policy Administrator can issue a Temporary Access Pass (OR)

123 − 1. Authentication Policy Administrator adds a phone number and allows voice/text message authentication for the user account.

115 +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.

124116

125 −If the CBA-enabled user hasn't yet been issued a certificate and needs to complete MFA:

126 − 1. Authentication Policy Administrator can issue a Temporary Access Pass (OR)

127 − 1. Authentication Policy Administrator adds a phone number and allows voice/text message authentication for the user account.

117 +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.

128118

129 −If the CBA-enabled user can't use an MF cert, such as on mobile device without smart card support, and needs to complete MFA:

130 − 1. Authentication Policy Administrator can issue a Temporary Access Pass (OR)

131 − 1. User needs to register another MFA method (when user can use MF cert on some device) (OR)

132 − 1. Authentication Policy Administrator adds a phone number and allows voice/text message authentication for the user account.

133 −

134 −**Steps to set up passwordless phone sign in (PSI) with CBA**

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

135120

136 −For passwordless sign-in to work, users should disable legacy notification through their mobile app.

121 +- The user can enter a password and use a single-factor certificate.

122 +- An Authentication Policy Administrator can issue a temporary access pass.

123 +- An Authentication Policy Administrator can add a phone number and allow voice or text message authentication for the user account.

137124

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

126 +

127 +- An Authentication Policy Administrator can issue a temporary access pass.

128 +- An Authentication Policy Administrator can add a phone number and allow voice or text message authentication for the user account.

129 +

130 +If the CBA-enabled 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:

131 +

132 +- An Authentication Policy Administrator can issue a temporary access pass.

133 +- The user can register another MFA method (when the user *can* use a multifactor certificate on a device).

134 +- An Authentication Policy Administrator can add a phone number and allow voice or text message authentication for the user account.

135 +

136 +### Set up passwordless phone sign-in with CBA

137 +

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

139 +

138140 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../role-based-access-control/permissions-reference.md#authentication-policy-administrator).

139141

140 −1. Follow the steps at [Enable passwordless phone sign-in authentication](../authentication/howto-authentication-passwordless-phone.md#enable-passwordless-phone-sign-in-authentication-methods).

142 +1. Complete the steps described in [Enable passwordless phone sign-in authentication](../authentication/howto-authentication-passwordless-phone.md#enable-passwordless-phone-sign-in-authentication-methods).

141143

142 − >[!IMPORTANT]

143 − >In the preceding configuration, make sure you chose **Passwordless** option. You need to change the **Authentication mode** for any groups added for PSI to **Passwordless**. If you choose **Any**, CBA and PSI don't work.

144 + > [!IMPORTANT]

145 + > 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.

144146

145147 1. Select **Entra ID** > **Multifactor authentication** > **Additional cloud-based multifactor authentication settings**.

146148

147 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/configure.png" alt-text="Screenshot of how to configure multifactor authentication settings.":::

149 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/configure.png" alt-text="Screenshot that shows how to configure the MFA settings.":::

148150

149 −1. Under **Verification options**, clear **Notification through mobile app**, and select **Save**.

151 +1. Under **Verification options**, clear the **Notification through mobile app** checkbox, and then select **Save**.

150152

151 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/clear-notification.png" alt-text="Screenshot of how to remove notification through mobile app.":::

153 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/clear-notification.png" alt-text="Screenshot that shows how to remove the notification through mobile app option.":::

152154

153 −## MFA authentication flow using single factor certificates and passwordless sign in

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

154156

155 −Let's look at an example of a user who has single-factor certificate, and is configured for passwordless sign-in.

157 +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:

156158

157 −1. Enter your user principal name (UPN) and select **Next**.

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

158160

159 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/user-principal-name.png" alt-text="Screenshot of how to enter a user principal name.":::

161 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/user-principal-name.png" alt-text="Screenshot that shows how to enter a user principal name.":::

160162

161 −1. Select **Sign in with a certificate**.

163 +1. Select **Use a certificate or smart card**.

162164

163 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-cert.png" alt-text="Screenshot of how to sign in with a certificate.":::

165 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-cert.png" alt-text="Screenshot that shows how to sign in with a certificate.":::

164166

165 − If you enabled other authentication methods like Phone sign-in or FIDO2 security keys, users might see a different sign-in screen.

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

166168

167 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-alt.png" alt-text="Screenshot of alternate way to sign in with a certificate.":::

169 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-alt.png" alt-text="Screenshot that shows an alternative way to sign in with a certificate.":::

168170

169 −1. Pick the correct user certificate in the client certificate picker and select **OK**.

171 +1. In the client certificate picker, select the correct user certificate, and then select **OK**.

170172

171 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png" alt-text="Screenshot of how to select a certificate.":::

173 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png" alt-text="Screenshot that shows how to select a certificate.":::

172174

173 −1. Because the certificate is configured to be single-factor authentication strength, the user needs a second factor to meet MFA requirements. The user sees available second factors, which in this case is passwordless sign-in. Select **Approve a request on my Microsoft Authenticator app**.

175 +1. 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**.

174176

175 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/second-factor-request.png" alt-text="Screenshot of second factor request.":::

177 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/second-factor-request.png" alt-text="Screenshot that shows completing a second-factor request.":::

176178

177 −1. You'll get a notification on your phone. Select **Approve Sign-in?**.

178 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/approve.png" alt-text="Screenshot of approval request.":::

179 +1. You get a notification on your phone. Select **Approve sign-in?**.

180 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/approve.png" alt-text="Screenshot that shows the phone approval request.":::

179181

180 −1. Enter the number you see on the browser or app screen into Microsoft Authenticator.

182 +1. In Microsoft Authenticator, enter the number you see in the browser or app.

181183

182 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/number.png" alt-text="Screenshot of number match.":::

184 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/number.png" alt-text="Screenshot that shows a number match." lightbox="media/concept-certificate-based-authentication-technical-deep-dive/number.png":::

183185

184 −1. Select **Yes** and user can authenticate and sign in.

186 +1. Select **Yes**, and you can authenticate and sign in.

185187

186 −## Understanding the authentication binding policy

188 +## Authentication binding policy

187189

188 −The authentication binding policy helps determine the strength of authentication as either single-factor or multifactor. Authentication Policy Administrators can change the default value from single-factor to multifactor, or set up custom policy configurations either by using issuer subject or policy OID or Issuer and Policy OID fields in the certificate.

190 +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.

189191

190 −### Certificate strengths

192 +### Certificate strength

191193

192 −Authentication Policy Administrators can determine whether the certificates are single-factor or multifactor strength. For more information, see the documentation that maps [NIST Authentication Assurance Levels to Microsoft Entra auth Methods](https://aka.ms/AzureADNISTAAL), which builds upon [NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt](https://csrc.nist.gov/publications/detail/sp/800-63b/final).

194 +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](https://aka.ms/AzureADNISTAAL), which builds upon [NIST 800-63B SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Mgmt](https://csrc.nist.gov/publications/detail/sp/800-63b/final).

193195

194 −### Multifactor certificate authentication

196 +### Multifactor certificate authentication

195197

196 −When a user has a multifactor certificate, they can perform multifactor authentication only with certificates. However, an Authentication Policy Administrator should make sure the certificates are protected with a PIN or biometric to be considered multifactor.

198 +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.

197199

198 −<a name='how-microsoft-entra-id-resolves-multiple-authentication-policy-binding-rules'></a>

200 +### Multiple authentication policy binding rules

199201

200 −### How Microsoft Entra ID resolves multiple authentication policy binding rules

202 +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.

201203

202 −Because multiple custom authentication binding policy rules can be created with different certificate fields like using issuer + policy OID, or just Policy OID or just issuer. Below are the steps used to determine the authentication protection level when custom rules overlap. They are as follows:

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

203205

204 −1. Issuer + policy OID rules take precedence over Policy OID rules. Policy OID rules take precedence over certificate issuer rules.

205 −1. Issuer + 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 issuer value and policy OID is given MFA.

206 −1. Next, custom rules using policy OIDs are evaluated. If you have a certificate A with policy OID **1.2.3.4.5** and a derived credential B based on that certificate has a policy OID **1.2.3.4.5.6**, and the custom rule is defined as **Policy OID** with value **1.2.3.4.5** with MFA, only certificate A satisfies MFA, and credential B satisfies only single-factor authentication. If the user used derived credential during sign-in and was configured to have MFA, the user is asked for a second factor for successful authentication.

207 −1. 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 a single-factor authentication.

208 −1. Next, custom rules using issuer CA are evaluated.

209 −1. If a certificate has both policy OID and Issuer rules matching, the policy OID is always checked first, and if no policy rule is found then the issuer bindings are checked. Policy OID has a higher strong authentication binding priority than the issuer.

210 −1. If one CA binds to MFA, all user certificates that the CA issues qualify as MFA. The same logic applies for single-factor authentication.

211 −1. If one policy OID binds to MFA, all user certificates that include this policy OID as one of the OIDs (A user certificate could have multiple policy OIDs) qualify as MFA.

212 −1. One certificate issuer can only have one valid strong authentication binding (that is, a certificate can't bind to both single-factor and MFA).

206 +1. Issuer and policy OID rules take precedence over policy OID rules. Policy OID rules take precedence over certificate issuer rules.

207 +1. 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.

208 +1. 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.

209 +1. 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.

210 +1. 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.

211 +1. If one CA binds to MFA, all user certificates that the CA issues qualify as MFA. The same logic applies to single-factor authentication.

212 +1. 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.)

213 +1. 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).

213214

214 −>[!IMPORTANT]

215 −>There's a known issue where a Microsoft Entra Authentication Policy Administrator configures a CBA authentication policy rule using both Issuer and Policy OID impacts some device registration scenarios including:

216 −>- Windows Hello For Business enrollment

217 −>- Fido2 Security Key registration

218 −>- Windows Passwordless Phone Sign-in

219 −>

220 −>Device registration with Workplace Join, Microsoft Entra ID and Hybrid Microsoft Entra device join scenarios aren't impacted. CBA authentication policy rules using either Issuer OR Policy OID aren't impacted.

221 −>To mitigate, Authentication Policy Administrators should:

222 −>- Edit the certificate-based authentication policy rules currently using both Issuer and Policy OID options and remove either the Issuer or OID requirement and save. OR

223 −>- Remove the authentication policy rule currently using both Issuer and Policy OID and create rules using only issuer or policy OID

215 +> [!IMPORTANT]

216 +> Currently, in a known issue that is being addressed, if an Authentication Policy Administrator creates a CBA policy rule by using both the issuer and the policy OID, some device registration scenarios are affected.

217 +>

218 +> The affected scenarios include:

219 +>

220 +> - Windows Hello for Business enrollment

221 +> - FIDO2 security key registration

222 +> - Windows passwordless phone sign-in

224223 >

225 −>We are working to fix the issue.

224 +> Device registration with Workplace Join, Microsoft Entra ID, and Microsoft Entra hybrid joined scenarios aren't affected. CBA policy rules that use either the issuer *or* the policy OID aren't affected.

225 +>

226 +> To mitigate the issue, an Authentication Policy Administrator should complete *one* of the following options:

227 +>

228 +> - Edit the CBA policy rule that currently uses both the issuer and the policy OID to remove either the issuer or the policy ID requirement.

229 +> - Remove the authentication policy rule that currently uses both the issuer and the policy OID, and then create a rule that uses only the issuer or the policy OID.

226230

227 −## Understanding the username binding policy

231 +## Username binding policy

228232

229 −The username binding policy helps validate the certificate of the user. By default, Subject Alternate Name (SAN) Principal Name in the certificate is mapped to UserPrincipalName attribute of the user object to determine the user.

233 +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.

230234

231 −### Achieve higher security with certificate bindings

235 +### Achieve higher security by using certificate bindings

232236

233 −There are seven supported methods for certificate bindings. In general, mapping types are considered high-affinity if they're based on identifiers that you can't reuse, such as Subject Key Identifiers or SHA1 Public Key. These identifiers convey a higher assurance that only a single certificate can be used to authenticate the respective user.

237 +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.

234238

235 −Mapping types based on user names and email addresses are considered low-affinity. Microsoft Entra ID implements three mappings considered low-affinity based on reusable identifiers. The others are considered high-affinity bindings. For more information, see [certificateUserIds](concept-certificate-based-authentication-certificateuserids.md).

239 +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`](concept-certificate-based-authentication-certificateuserids.md).

236240

238242 |:--------------------------|:----------------------------------------:|:----------------------:|:----:|

244 −|SHA1PublicKey | `X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR` The SHA1PublicKey value (SHA1 hash of the entire certificate content including the public key) is found in the Thumbprint property of certificate.| certificateUserIds | high-affinity |

245 −|IssuerAndSerialNumber | `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT` To get the correct value for serial number, run this command and store the value shown in CertificateUserIds: **Syntax**: `Certutil –dump –v [~certificate path~] >> [~dumpFile path~]` **Example**: `certutil -dump -v firstusercert.cer >> firstCertDump.txt` | certificateUserIds | high-affinity |

248 +|`SHA1PublicKey` | `X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR` The `SHA1PublicKey` value (SHA1 hash of the entire certificate content, including the public key) is in the **Thumbprint** property of the certificate.| `certificateUserIds` | High affinity |

249 +|`IssuerAndSerialNumber` | `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT` To get the correct value for the serial number, run this command and store the value shown in `certificateUserIds`: **Syntax**: `certutil –dump –v [~certificate path~] >> [~dumpFile path~]` **Example**: `certutil -dump -v firstusercert.cer >> firstCertDump.txt` | `certificateUserIds` | High affinity |

246250

247 −>[!IMPORTANT]

248 −> You can use the [CertificateBasedAuthentication PowerShell module](concept-certificate-based-authentication-certificateuserids.md#how-to-find-the-correct-certificateuserids-values-for-a-user-from-the-end-user-certificate-using-powershell-module) to find the correct CertificateUserIds values for a user from the end user certificate.

251 +> [!IMPORTANT]

252 +> You can use the [`CertificateBasedAuthentication` PowerShell module](concept-certificate-based-authentication-certificateuserids.md#how-to-find-the-correct-certificateuserids-values-for-a-user-from-the-end-user-certificate-using-powershell-module) to find the correct `certificateUserIds` value for a user in a certificate.

249253

250 −### Define Affinity binding at the tenant level and override with custom rules

254 +### Define and override affinity binding

251255

252 −With this feature an Authentication Policy Administrator can configure whether a user can be authenticated by using low-affinity or high-affinity username binding mapping. You can set **Required affinity binding** for the tenant, which applies to all users. You can also override the tenant-wide default value by creating custom rules based on Issuer and Policy OID, or Policy OID, or Issuer.

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

253257

254 −<a name='how-microsoft-entra-id-resolves-multiple-username-policy-binding-rules'></a>

258 +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.

255259

256 −### How Microsoft Entra ID resolves multiple username policy binding rules

260 +### Multiple username policy binding rules

257261

258 −Use the highest priority (lowest number) binding.

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

259263

260 −1. Look up the user object by using the username or User Principal Name.

261 −1. Get the list of all username bindings setup by the Authentication Policy Administrator in the CBA authentication method configuration ordered by the 'priority' attribute. Today the concept of priority isn't exposed in Portal UX. Graph returns the priority attribute for each binding and they're used in the evaluation process.

262 −1. If the tenant has high affinity binding enabled or if the certificate value matches a custom rule that required high affinity binding, remove all the low affinity bindings from the list.

263 −1. Evaluate each binding in the list until a successful authentication occurs.

264 +1. Looks up the user object by using the username or UPN.

265 +1. 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.

266 +1. If the tenant has high-affinity binding enabled or if the certificate value matches a custom rule that requires high-affinity binding, removes all the low-affinity bindings from the list.

267 +1. Evaluates each binding in the list until a successful authentication occurs.

264268 1. 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.

265 − 1. If a match is found, user authentication is successful.

266 − 1. If a match isn't found, move to the next priority binding.

267 −1. If the X.509 certificate field isn't on the presented certificate, move to the next priority binding.

268 −1. Validate all the configured username bindings until one of them results in a match and user authentication is successful.

269 + - If a match is found, user authentication is successful.

270 + - If a match isn't found, moves to the next priority binding.

271 +1. If the X.509 certificate field isn't on the presented certificate, moves to the next priority binding.

272 +1. Validates all configured username bindings until one of them results in a match and user authentication is successful.

269273 1. If a match isn't found on any of the configured username bindings, user authentication fails.

270274

271 −<a name='securing-microsoft-entra-configuration-with-multiple-username-bindings'></a>

275 +## Secure Microsoft Entra configuration by using multiple username bindings

272276

273 −## Securing Microsoft Entra configuration with multiple username bindings

277 +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.

274278

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

279 +> [!IMPORTANT]

280 +> If you configure multiple bindings, Microsoft Entra CBA authentication is only as secure as your lowest-affinity binding because CBA validates each binding to authenticate the user. To prevent a scenario where a single certificate matches multiple Microsoft Entra accounts, an Authentication Policy Administrator can:

281 +>

282 +> - Configure a single binding method in the username binding policy.

283 +> - If a tenant has multiple binding methods configured and doesn't want to allow one certificate to map to multiple accounts, an Authentication Policy Administrator must ensure that all allowable methods configured in the policy map to the same Microsoft Entra account. All user accounts should have values that match all the bindings.

284 +> - If a tenant has multiple binding methods configured, an Authentication Policy Administrator should ensure that they don't have more than one low-affinity binding.

276285

277 −>[!IMPORTANT]

278 −>If you configure multiple bindings, Microsoft Entra CBA authentication is only as secure as your lowest affinity binding because CBA validates each binding to authenticate the user. To prevent a scenario where a single certificate matches multiple Microsoft Entra accounts, an Authentication Policy Administrator can:

279 −>- Configure a single binding method in the username binding policy.

280 −>- If a tenant has multiple binding methods configured and doesn't want to allow one certificate to map to multiple accounts, the Authentication Policy Administrator must ensure all allowable methods configured in the policy map to the same Microsoft Entra account. All user accounts should have values matching all of the bindings.

281 −>- If a tenant has multiple binding methods configured, the Authentication Policy Administrator should make sure that they don't have more than one low-affinity binding.

286 +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.

282287

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

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

284289

285 −<a name='support-for-multiple-certificates-with-one-entra-user-account-m1'></a>

290 +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.

286291

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

288 −There are scenarios where an organization issues multiple certificates for a single identity. Most commonly this could be a derived credential for a mobile device or can also be for a secondary smartcard or x509 credential holder capable device such as a Yubikey.

292 +#### Cloud-only accounts (M:1)

289293

290 −**Cloud only accounts**

291 −For cloud-only accounts you can map multiple certificates (up to 5) for use by populating the certificateUserIds field (Authorization info in the User Portal) with unique values identifying each certificate. If the organization is using high affinity bindings say Issuer + SerialNumber, values within CertificateUserIds may look like the following:

292 −

294 +For cloud-only accounts, you can map multiple certificates (up to five) to use by populating the `certificateUserIds` field (on the **Authorization info** tab in the admin center) with unique values identifying each certificate. If the organization uses high-affinity bindings, like `IssuerAndSerialNumber`, values in `certificateUserIds` might look like the following example:

295 +

293296 `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT`\

294297 `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV`

295 −

296 −In this example the first value represents X509Certificate1 and the second value represents X509Certificate2. The user may present either certificate at sign-in and as long as the CBA Username Binding is set to point to the certificateUserIds field to look for the particular binding type (that is, Issuer+SerialNumber in this example), then the user successfully signs in.

297298

298 −**Hybrid Synchronized accounts**

299 −For synchronized accounts you can map multiple certificates for use by populating the altSecurityIdentities field in AD the values identifying each certificate. If the organization is using high affinity (that is, strong authentication) bindings say Issuer + SerialNumber, this could look like the following:

300 −

299 +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.

300 +

301 +#### Hybrid synchronized accounts (M:1)

302 +

303 +For synchronized accounts, you can map multiple certificates. In Windows Server 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:

304 +

301305 `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT`\

302306 `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV`

303 −

304 −In this example the first value represents X509Certificate1 and the second value represents X509Certificate2. These values must then be synchronized to the certificateUserIds field in Microsoft Entra ID.

305307

306 −<a name='support-for-one-certificate-with-multiple-entra-user-accounts-1m'></a>

308 +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.

307309

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

309 −There are scenarios where an organization needs the user to use the same certificate to authenticate into multiple identities. Most commonly this is for administrative accounts. It can also be for developer accounts or temporary duty accounts. In traditional AD the altSecurityIdentities field is used to populate the certificate values and a Hint is used during sign-in to direct AD to the desired account to check for the sign-in. With Microsoft Entra CBA this is different and there is no Hint. Instead, Home Realm Discovery identifies the desired account to check the certificate values. The other key difference is that Microsoft Entra CBA enforces uniqueness in the certificateUserIds field. This means that two accounts can't both populate the same certificate values.

310311

311 −>[!Important]

312 −> It isn't a very secure configuration to use same credential to authenticate into different Microsoft Entra accounts and it's recommended not to allow one certificate for multiple Microsoft Entra user accounts.

312 +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.

313313

314 −**Cloud only accounts**

315 −For cloud-only accounts you need to create multiple username bindings and map unique values to each user account that is to use the certificate. Each account is authenticated into using a different username binding. This applies within the boundary of a single directory/tenant (that is, Authentication Policy Administrators can map the certificate for use in another directory/tenant as well, as long as the values remain unique per account too).

316 −

317 −Populate the certificateUserIds field (Authorization info in the User Portal) with a unique value identifying the desired certificate. If the organization is using high affinity bindings (that is, strong authentication) bindings say Issuer + SerialNumber and SKI, this could look like the following:

314 +In Windows Server Active Directory, the `altSecurityIdentities` field populates the certificate values. A hint is used during sign-in to direct Windows Server Active Directory to the intended account to check for sign-in.

318315

316 +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.

317 +

318 +> [!IMPORTANT]

319 +> Using the same credentials to authenticate into different Microsoft Entra accounts isn't a secure configuration. We recommend that you don't allow a single certificate to be used for multiple Microsoft Entra user accounts.

320 +

321 +#### Cloud-only accounts (1:M)

322 +

323 +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.

324 +

325 +Populate the `certificateUserIds` field (on the **Authorization info** tab in the admin center) with a unique value that identifies the certificate. If the organization uses high-affinity bindings (that is, strong authentication) like `IssuerAndSerialNumber` and `SKI`, it might look like the following example:

326 +

319327 Username bindings:

320 −- Issuer + Serial Number -> CertificateUserIds

321 −- SKI -> CertificateUserIds

322328

323 −User account CertificateUserIds values:\

329 +- `IssuerAndSerialNumber` > `certificateUserIds`

330 +- `SKI` > `certificateUserIds`

331 +

332 +User account `certificateUserIds` values:\

324333 `X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR`\

325334 `X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT`

326335

327 −Now, when either user presents the same certificate at sign-in the user is successfully sign-in because their account matches a unique value on that certificate. One account is authenticated into using Issuer+SerialNumber and the other using SKI binding.

336 +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.

328337

329 −>[!Note]

330 −> The number of accounts that can be used in this manner is limited by the number of username bindings configured on the tenant. If the organization is using only High Affinity bindings the number of accounts supported is limited to 3. If the organization is also utilizing low affinity bindings then this number increases to 7 accounts (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

338 +> [!NOTE]

339 +> The number of accounts that can be used in this manner is limited by the number of username bindings configured on the tenant. If the organization uses only high-affinity bindings, the maximum number of accounts supported is three. If the organization also uses low-affinity bindings, the number increases to seven accounts: one `PrincipalName`, one `RFC822Name`, one `SKI`, one `SHA1PublicKey`, one `IssuerAndSubject`, one `IssuerAndSerialNumber`, and one `Subject`.

331340

332 −**Hybrid Synchronized accounts**

333 −For synchronized accounts the approach is different. While Authentication Policy Administrators can map unique values to each user account that use the certificate, the common practice of populating all values to each account in Microsoft Entra ID makes this difficult. Instead, Microsoft Entra Connect should filter the desired values per account to unique values populated into the account in Microsoft Entra ID. The uniqueness rule applies within the boundary of a single directory/tenant (that is, Authentication Policy Administrators can map the certificate for use in another directory/tenant as well, as long as the values remain unique per account too). Further, the organization may have multiple AD forests contributing users into a single Microsoft Entra tenant. In this case, Microsoft Entra Connect applies the filter to each of these AD forests with the same goal to populate only a desired unique value to the cloud account.

341 +#### Hybrid synchronized accounts (1:M)

334342

335 −Populate the altSecurityIdentities field in AD with the values identifying the desired certificate and to include the desired certificate value for that user account type (such as detailee, admin, developer, and so on). Select a key attribute in AD which tells the synchronization which user account type the user is evaluating (such as msDS-cloudExtensionAttribute1). Populate this attribute with the user type value you desire such as detailee, admin, or developer. If this is the user’s primary account, the value can be left empty/null.

336 −

337 −The accounts could look like the following:

338 −

339 −Forest 1 - Account1 ([email protected]):\

343 +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.

344 +

345 +The organization might also have multiple Windows Server 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 Windows Server Active Directory forests with the same goal: populate only a specific, unique value to the cloud account.

346 +

347 +Populate the `altSecurityIdentities` field in Windows Server 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 Windows Server 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.

348 +

349 +Check that the accounts look similar to these examples:

350 +

351 +Forest 1 - Account1 (<[email protected]>):\

340352 `X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR`\

341353 `X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT`\

342354 `X509:<PN>[email protected]`

343 −␣

344 −Forest 1 - Account2 ([email protected]): \

355 +

356 +Forest 1 - Account2 (<[email protected]>): \

345357 `X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR`\

346 −`X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT`\

358 +`X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT`\

347359 `X509:<PN>[email protected]`

348 −␣

349 −Forest 2 – ADAccount1 ([email protected]):\

360 +

361 +Forest 2 – ADAccount1 (<[email protected]>):\

350362 `X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR`\

351 −`X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT`\

363 +`X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT`\

352364 `X509:<PN>[email protected]`

353 −

354 −These values must then be synchronized to the certificateUserIds field in Microsoft Entra ID.

355365

356 −**Steps to synchronize to certificateUserIds**

357 −1. Configure Microsoft Entra Connect to add the alternativeSecurityIds field to the Metaverse

358 −1. For each AD Forest, configure a new custom inbound rule with a high precedence (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 as well as the mapping to the User Types that you defined.

359 −1. For example:

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

360367

368 +To sync to `certificateUserIds`:

369 +

370 +1. Configure Microsoft Entra Connect to add the `alternativeSecurityIds` field to the metaverse.

371 +1. For each Windows Server 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.

372 +

373 +For example:

374 +

361375 ```powershell

362376 IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])),

363377     IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0),

368382     Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:"),InStrRev($item, "<SR>"))>0)), NULL)

369383 )

370384 ```

371 −In the example above, altSecurityIdentities and the key attribute msDS-cloudExtensionAttribute1is are first checked to see if they're populated. If not, altSecurityIdentities is checked to see if it's populated. If it's empty then we set it to NULL. Otherwise the account falls into the default case and in this example we filter to only the Issuer+SerialNumber mapping. If the key attribute is populated, then the value is checked to see if it's equal to one of our defined user types. In this example if that value is detailee, then we filter to the SHA1PublicKey value from altSecurityIdentities. If the value is developer, then we filter to the SubjectKeyIssuer value from altSecurityIdentities. There may be multiple certificate values of a specific type. For example, multiple PrincipalName values or multiple SKI or SHA1-PUKEY values. The filter gets all the values and sync into Microsoft Entra ID – not just the first one it finds.

372 −1. A second example that shows how to push an empty value if the control attribute is empty is:

373 −

385 +

386 +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.

387 +

388 +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`.

389 +

390 +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.

391 +

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

393 +

374394 ```powershell

375395 IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])),

376396     IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0),

381401     AuthoritativeNull, NULL)

382402 )

383403 ```

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

385 −1. Configure a new custom outbound rule with a low precedence (high number above 160 – bottom of list).

386 −1. Add a direct transform with the alternativeSecurityIds field as the source and the certificateUserIds field as the target.

387 −1. Run a synchronization cycle to complete the population of the data in Microsoft Entra ID.

388 −

389 −Ensure that CBA in each tenant is configured with the Username Bindings pointing to the certificateUserIds field for the field types that you have mapped from the certificate. Now any of these users may present the certificate at sign-in and after the unique value from the certificate is validated against the certificateUserIds field, that user is successfully signed-in.

390404

391 −## Understanding the certificate revocation process

405 +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.

392406

393 −The certificate revocation process allows Authentication Policy Administrators to revoke a previously issued certificate from being used for future authentication. The certificate revocation won't revoke already issued tokens of the user. Follow the steps to manually revoke tokens at [Configure revocation](./certificate-based-authentication-federation-get-started.md#step-3-configure-revocation).

407 +To sync an empty value:

394408

395 −Microsoft Entra ID downloads and caches the customers certificate revocation list (CRL) from their certificate authority to check if certificates are revoked during the authentication of the user.

409 +1. Configure a new custom outbound rule with a low precedence (a high number, above 160 but from the bottom of the list).

410 +1. Add a direct transform with the `alternativeSecurityIds` field as the source and the `certificateUserIds` field as the target.

411 +1. Run a synchronization cycle to complete data population in Microsoft Entra ID.

396412

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

398 −

399 −>[!IMPORTANT]

400 −>The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in public Microsoft Entra ID and 45 MB in Azure US Government clouds, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate-based authentications using certificates issued by the corresponding CA fail. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and to clean up expired certificates. For more information, see [Is there a limit for CRL size?](certificate-based-authentication-faq.yml#is-there-a-limit-for-crl-size-).

413 +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.

401414

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

415 +## Certificate revocation process

403416

404 −"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."

417 +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](./certificate-based-authentication-federation-get-started.md#step-3-configure-revocation).

405418

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

420 +

421 +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.

422 +

423 +> [!IMPORTANT]

424 +> The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in public Microsoft Entra ID and 45 MB in Azure US Government clouds. The time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, CBA that uses a certificate issued by the corresponding CA fails. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and clean up expired certificates. For more information, see [Do CRLs have a size limit?](certificate-based-authentication-faq.yml#do-crls-have-a-size-limit-).

425 +

426 +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:

427 +

428 +`"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."`

429 +

406430 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).

407431

408 −>[!IMPORTANT]

409 −>If an Authentication Policy Administrator skips the configuration of the CRL, Microsoft Entra ID doesn't perform any CRL checks during the certificate-based authentication of the user. This can be helpful for initial troubleshooting, but shouldn't be considered for production use.

432 +> [!IMPORTANT]

433 +> If an Authentication Policy Administrator doesn't configure the CRL, Microsoft Entra ID doesn't perform any CRL checks during CBA for a user. This option can be helpful for initial troubleshooting, but don't use it in production.

410434

411 −As of now, we don't support Online Certificate Status Protocol (OCSP) because of performance and reliability reasons. Instead of downloading the CRL at every connection by the client browser for OCSP, Microsoft Entra ID downloads once at the first sign-in and caches it. This action improves the performance and reliability of CRL verification. We also index the cache so the search is much faster every time. Customers must publish CRLs for certificate revocation.

435 +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.

412436

413 −The following steps are a typical flow of the CRL check:

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

414438

415 −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 certificate authority.

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

417 −1. The user certificate-based authentication fails if:

439 +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.

440 +1. 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.

441 +

442 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/user-cert.png" alt-text="Screenshot that shows the revoked user certificate in the CRL." :::

443 +

444 +1. User CBA fails if:

445 +

418446 - A CRL is configured for the trusted issuer and Microsoft Entra ID can't download the CRL, due to availability, size, or latency constraints.

419447 - The user's certificate is listed as revoked on the CRL.

420 −

421 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/user-cert.png" alt-text="Screenshot of the revoked user certificate in the CRL." :::

422 −

423 − - Microsoft Entra ID attempts to download a new CRL from the distribution point if the cached CRL document is expired.

448 + - Microsoft Entra ID attempts to download a new CRL from the distribution point if the cached CRL document is expired.

424449

425 −>[!NOTE]

426 −>Microsoft Entra ID checks the CRL of the issuing CA and other CAs in the PKI trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to make sure a bad actor doesn't bring down the service by uploading a PKI chain with a huge number of CAs with a bigger CRL size.

427 −If the tenant's PKI chain has more than 5 CAs, and if there's a CA compromise, Authentication Policy Administrators should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.

428 −␣

450 +> [!NOTE]

451 +> Microsoft Entra ID checks the CRL of the issuing CA and other CAs in the public key infrastructure (PKI) trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to ensure that a bad actor doesn't bring down the service by uploading a PKI chain that has a vast number of CAs and a larger CRL.

452 +>

453 +> If the tenant's PKI chain has more than 5 CAs, and if there's a CA compromise, an Authentication Policy Administrator should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.

429454

430 −>[!IMPORTANT]

431 −>Due to the nature of CRL caching and publishing cycles, it's highly recommended that, if there's a certificate revocation, to also revoke all sessions of the affected user in Microsoft Entra ID.

455 +> [!IMPORTANT]

456 +> Due to the nature of CRL caching and publishing cycles, we recommend that if a certificate is revoked, you also revoke all sessions of the affected user in Microsoft Entra ID.

432457

433 −As of now, there's no way to manually force or retrigger the download of the CRL.

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

434459

435 −### How to configure revocation

460 +### Configure revocation

436461

437462 [!INCLUDE [Configure revocation](../../includes/entra-authentication-configure-revocation.md)]

438463

439 −## Understanding CRL validation

464 +## CRL validation

440465

441 −A CRL is a record of digital certificates that have been revoked before the end of their validity period by a certificate authority (CA).

442 −When CAs are uploaded to the Microsoft Entra trust store, a CRL, or more specifically the CrlDistributionPoint attribute, isn't required. A CA can be uploaded without a CRL endpoint, and certificate-based authentication won't fail if an issuing CA doesn't have a CRL specified.

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

443467

444 −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 an end user certificate.

468 +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.

445469

470 +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.

471 +

446472 ### Enable CRL validation

447473

448 −To enable CRL validation, select **Require CRL validation (recommended)**.

474 +To enable CRL validation, select the **Require CRL validation (recommended)** checkbox.

449475

450 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/require-validation.png" alt-text="Screenshot of how to require CRL validation." :::

476 +:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/require-validation.png" alt-text="Screenshot that shows how to require CRL validation." :::

451477

452 −Once enabled, any CBA fail is because the end user certificate was issued by a CA with no CRL configured.

478 +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.

453479

454 −An Authentication Policy Administrator can exempt a CA if its CRL has issues that should be fixed. Select **Add Exemption** and select any CAs that should be exempted.

480 +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.

455481

456 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/exempt-validation.png" alt-text="Screenshot of how to exempt CAs from CRL validation." :::

482 +:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/exempt-validation.png" alt-text="Screenshot that shows how to exempt CAs from CRL validation." :::

457483

458 −The CAs in the exempted list aren't required to have CRL configured and the end-user certificates that they issue don't fail authentication.

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

459485

460 −Select CAs and select **Add**. The **Search** text box can be used to filter the CA lists to select specific CAs.

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

461487

462 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/exempted.png" alt-text="Screenshot of CAs that are exempted from CRL validation." :::

488 +:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/exempted.png" alt-text="Screenshot that shows CAs that are exempted from CRL validation." :::

463489

464 −## Certificate Authority (CA) Scoping (Preview)

490 +## CA scoping (preview)

465491

466 −Certificate Authority (CA) Scoping in Microsoft Entra allows tenant administrators to restrict the use of specific certificate authorities (CAs) to defined user groups. This feature enhances the security and manageability of certificate-based authentication (CBA) by ensuring that only authorized users can authenticate using certificates issued by specific CAs.

492 +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.

467493

468 −CA Scoping is particularly 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.

494 +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.

469495

470 −**Key Benefits**

471 −- Restrict certificate usage to specific user groups

472 −- Support for complex PKI environments with multiple CAs

473 −- Enhanced protection against certificate misuse or compromise

474 −- Visibility into CA usage via sign-in logs and monitoring tools

496 +### Key benefits

475497

476 −CA Scoping allows admins to define rules that associate a CA (identified by its Subject Key Identifier, or SKI) with a specific Microsoft Entra group. When a user attempts to authenticate using a certificate, the system checks whether the certificate’s issuing CA is scoped to a group that includes the user. Entra walks up the CA chain and applies all the scope rules until user is found in one of the groups in all the scope rules. If the user is not in the scoped group, authentication fails, even if the certificate is otherwise valid.

498 +- Restricts certificate use to specific user groups

499 +- Supports complex PKI environments through multiple CAs

500 +- Provides enhanced protection against certificate misuse or compromise

501 +- Gives visibility into CA usage via sign-in logs and monitoring tools

477502

478 −### Steps to enable CA scoping feature

503 +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.

479504

505 +### Enable the CA scoping feature

506 +

480507 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../role-based-access-control/permissions-reference.md#authentication-policy-administrator).

481 −1. Browse to **Entra ID** > **Authentication methods** > **Certificate-based Authentication**.

482 −1. Under **Configure**, go to **Certificate issuer scoping policy**

508 +1. Go to **Entra ID** > **Authentication methods** > **Certificate-based authentication**.

509 +1. Under **Configure**, go to **Certificate issuer scoping policy**.

483510

484 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-config.png" alt-text="Screenshot of CA scoping policy.":::

511 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-config.png" alt-text="Screenshot that shows CA scoping policy.":::

485512

486 −1. Select **Add rule**

513 +1. Select **Add rule**.

487514

488 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-add-rule.png" alt-text="Screenshot of CA scoping add rule.":::

515 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-add-rule.png" alt-text="Screenshot that shows how to add a CA scoping rule.":::

489516

490 −1. Select **Filter CAs by PKI**. **Classic CAs** will show all the CAs from classic CA store and selecting a specific PKI will show all the CAs from the selected PKI. Select a PKI.

517 +1. Select **Filter CAs by PKI**.

491518

492 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-pki-filter.png" alt-text="Screenshot of CA scoping PKI filter.":::

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

493520

494 −1. **Certificate issuer** drop down will show all the CAs from the selected PKI. Select a CA to create a scope rule.

521 +1. Select a PKI.

495522

496 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-select-cert.png" alt-text="Screenshot of CA scoping select CA.":::

523 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-pki-filter.png" alt-text="Screenshot that shows the CA scoping PKI filter.":::

497524

498 −1. Select **Add group**

525 +1. The **Certificate issuer** list shows all the CAs from the selected PKI. Select a CA to create a scope rule.

499526

500 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-add-group.png" alt-text="Screenshot of CA scoping add group.":::

Certificate authentication bindings and limitations

Microsoft's edit · 6 Aug 2025 21:14 UTC