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 set up for the tenant. If CBA is set up, the user sees a link to **Use a certificate or smart card** on the password page. If the user doesn't see the sign-in link, make sure that CBA is set up for the tenant.

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 we turn on Microsoft Entra CBA?](./certificate-based-authentication-faq.yml#how-do-we-turn-on-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 turn on [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 multifactor authentication (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 +### Turn on 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 turn on 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 that has TLS inspection set up 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 turned off 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 turn on 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 you turn on issuer hints, 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 you turn on issuer hints.":::

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-capable 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-capable 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-capable user can't use a multifactor certificate, such as if they're using a mobile device without smart card support but they need to complete MFA, choose *one* of these options to authenticate the user:

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 configured 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 up to five certificates to use by populating the `certificateUserIds` field with unique values to identify each certificate. To map the certificates, in the admin center, go to the **Authorization info** tab.

295 +

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

297 +

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

294299 `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.

297300

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 −

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

302 +

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

304 +

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

306 +

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

302308 `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.

305309

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

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

307311

308312 ### 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.

310313

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.

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

313315

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:

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

318317

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

319 +

320 +> [!IMPORTANT]

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

322 +

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

324 +

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

326 +

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

328 +

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

330 +

319331 Username bindings:

320 −- Issuer + Serial Number -> CertificateUserIds

321 −- SKI -> CertificateUserIds

322332

323 −User account CertificateUserIds values:\

333 +- `IssuerAndSerialNumber` > `certificateUserIds`

334 +- `SKI` > `certificateUserIds`

335 +

336 +User account `certificateUserIds` values:\

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

325338 `X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT`

326339

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.

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

328341

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

342 +> [!NOTE]

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

331344

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.

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

334346

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]):\

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

348 +

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

350 +

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

352 +

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

354 +

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

340356 `X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR`\

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

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

343 −␣

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

359 +

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

345361 `X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR`\

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

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

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

348 −␣

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

364 +

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

350366 `X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR`\

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

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

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

353 −

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

355369

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:

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

360371

372 +To sync to `certificateUserIds`:

373 +

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

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

376 +

377 +For example:

378 +

361379 ```powershell

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

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

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

369387 )

370388 ```

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 −

389 +

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

391 +

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

393 +

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

395 +

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

397 +

374398 ```powershell

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

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

381405     AuthoritativeNull, NULL)

382406 )

383407 ```

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.

390408

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

410 +

411 +To sync an empty value:

412 +

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

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

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

416 +

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

418 +

419 +

391420 ## Certificate Authority (CA) Scoping (Preview)

392421

393 −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.

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

394423

395 −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.

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

396425

397 −**Key Benefits**

398 −- Restrict certificate usage to specific user groups

399 −- Support for complex PKI environments with multiple CAs

400 −- Enhanced protection against certificate misuse or compromise

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

426 +### Key benefits

402427

403 −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.

428 +- Restricts certificate use to specific user groups

429 +- Supports complex PKI environments through multiple CAs

430 +- Provides enhanced protection against certificate misuse or compromise

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

404432

405 −### Steps to enable CA scoping feature

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

406434

435 +### Set up the CA scoping feature

436 +

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

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

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

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

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

410440

411 −:::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.":::

441 + :::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.":::

412442

413 −1. Select **Add rule**

443 +1. Select **Add rule**.

414444

415 −:::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.":::

445 + :::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.":::

416446

417 −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.

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

418448

419 −:::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.":::

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

420450

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

451 +1. Select a PKI.

422452

423 −:::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.":::

453 + :::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.":::

424454

425 −1. Select **Add group**

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

426456

427 −:::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.":::

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

428458

429 −1. Select a group

459 +1. Select **Add group**.

430460

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

461 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-add-group.png" alt-text="Screenshot that shows the add group option in CA scoping.":::

432462

433 −1. Select **Add** to save the rule

463 +1. Select a group.

434464

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

465 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-select-group.png" alt-text="Screenshot that shows the select group option in CA scoping.":::

436466

437 −1. Select **I Acknowledge** and Select **Save** to save CBA config

467 +1. Select **Add** to save the rule.

438468

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

469 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-save-rule.png" alt-text="Screenshot that shows the save rule option in CA scoping.":::

440470

441 −1. To edit or delete a CA scoping policy select "..." on the rule row. Select **Edit** to edit the rule and **Delete** to delete the rule.

471 +1. Select the **I Acknowledge** checkbox, and then select **Save**.

442472

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

473 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-save-cbaconfig.png" alt-text="Screenshot that shows the save CBA configuration option in CA scoping.":::

444474

445 −### Known Limitations

475 +1. To edit or delete a CA scoping policy, select "..." on the rule row. To edit the rule, select **Edit**. To delete the rule, select **Delete**.

476 +

477 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/ca-scoping-policy-edit-delete.png" alt-text="Screenshot that shows how to edit or delete in CA scoping.":::

478 +

479 +### Known limitations

480 +

446481 - Only one group can be assigned per CA.

447482 - A maximum of 30 scoping rules is supported.

448483 - Scoping is enforced at the intermediate CA level.

449 −- Improper configuration may result in user lockouts if no valid scoping rules exist.

484 +- Improper configuration might result in user lockouts if no valid scoping rules exist.

450485

451486 ### Sign-in log entries

452487

453 −- Sign in log will show success and in **Additional Details** tab the SKI of the CA from scoping policy rule will be shown.

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

454489

455 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log-success.png" alt-text="Screenshot of CA scoping rule sign in log success.":::

490 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log-success.png" alt-text="Screenshot that shows a CA scoping rule sign-in log success.":::

456491

457 −- When a CBA authentication fails due to a CA scoping rule, the Basic info tab in the sign-in log will show the error code 500189

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

458493

459 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log-error.png" alt-text="Screenshot of CA scoping sign in log error.":::

494 + :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log-error.png" alt-text="Screenshot that shows a CA scoping sign-in log error.":::

460495

461 −- End users will see the error message below.

496 + End users see the following error message:

462497

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

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

464499

465500 ## How CBA works with a Conditional Access authentication strength policy

466501

467 −Customers can create a Conditional Access authentication strength policy to specify that CBA be used to access a resource.

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

468503

469 −You can use the built-in **Phishing-resistant MFA** authentication strength. That policy only allows authentication methods that are phishing-resistant like CBA, FIDO2 security keys, and Windows Hello for Business.

504 +You can also create a custom authentication strength to allow only CBA to access sensitive resources. You can allow CBA as single-factor authentication, MFA, or both. For more information, see [Conditional Access authentication strength](concept-authentication-strengths.md).

470505

471 −You can also create a custom authentication strength to allow only CBA to access sensitive resources. You can allow CBA as a single-factor, multifactor, or both. For more information, see [Conditional Access authentication strength](concept-authentication-strengths.md).

506 +### CBA strength with advanced options

472507

473 −### CBA authentication strength with advanced options

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

474509

475 −In the CBA Authentication methods policy, an Authentication Policy Administrator can determine the strength of the certificate by using [authentication binding policy](#understanding-the-authentication-binding-policy) on the CBA method. Now you can configure **Advanced options** when you create a custom authentication strength to require a specific certificate to be used, based on issuer and policy OIDs, when users perform CBA to access certain sensitive resources. This feature provides a more precise configuration to determine the certificates and users that can access resources. For more information, see [Advanced options for Conditional Access authentication strength](concept-authentication-strength-advanced-options.md).

510 +## Sign-in logs

476511

477 −## Understanding Sign-in logs

512 +Sign-in logs provide information about sign-ins and how your resources are used in the organization. For more information, see [Sign-in logs in Microsoft Entra ID](../monitoring-health/concept-sign-ins.md).

478513

479 −Sign-in logs provide information about sign-ins and how your resources are used by your users. For more information about sign-in logs, see [Sign-in logs in Microsoft Entra ID](../monitoring-health/concept-sign-ins.md).

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

480515

481 −Let's walk through two scenarios, one where the certificate satisfies single-factor authentication and another where the certificate satisfies MFA.

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

482517

483 −For the test scenarios, choose a user with a Conditional Access policy that requires MFA.

484 −Configure the user binding policy by mapping SAN Principal Name to UserPrincipalName.

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

485519

486 −The user certificate should be configured like this screenshot:

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

487521

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

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

489523

490 −### Troubleshooting sign-in issues with dynamic variables in sign-in logs

491 −Although sign-in logs provide all the information to debug a user's sign-in issues, there are times when specific values are required and since sign-in logs don't support dynamic variables, the sign-in logs would have missing information.

492 −For ex: The failure reason in sign-in log would show something like "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier {expectedSKI} doesn't match CRL Authority Key {crlAK}. Request your tenant administrator to check the CRL configuration." where {expectedSKI} and {crlAKI} aren't populated with correct values.

524 +### Troubleshoot sign-in issues with dynamic variables in sign-in logs

493525

494 −When users sign-in with CBA fails, please copy the log details from 'More Details' link in the error page. For more detailed info, look at [understanding CBA error page](./concept-certificate-based-authentication-technical-deep-dive.md#understanding-the-certificate-based-authentication-error-page)

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

495527

496 −### Test single-factor authentication

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

497529

498 −For the first test scenario, configure the authentication policy where the Issuer subject rule satisfies single-factor authentication.

530 +When user sign-in with CBA fails, you can copy the log details from the **More Details** link on the error page. For more information, see [Understanding the CBA error page](./concept-certificate-based-authentication-technical-deep-dive.md#cba-error-page).

499531

500 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/single-factor.png" alt-text="Screenshot of the Authentication policy configuration showing single-factor authentication required." lightbox="./media/concept-certificate-based-authentication-technical-deep-dive/single-factor.png":::

532 +### Test single-factor authentication

Certificate authentication bindings and limitations

Microsoft's edit · 21 Aug 2025 18:44 UTC