Using authentication strengths in Conditional Access policies

This week is all about a nice feature of Conditional Access. Not a particular new feature, but an important feature for a solid passwordless implementation. That feature is authentication strengths. Authentication strengths is a Conditional Access control that enables IT administrators to specify which combination of authentication methods should be used to access the assigned cloud apps. Before authentication strengths, it was not possible to differentiate between the different authentication methods that can be used as a second factor. Now with authentication strengths, it enables organizations to differentiate the available authentication methods between apps, or to simply prevent the usage of less secure MFA combinations (like password + SMS). With that, it opens a whole new world of potential scenarios that can be easily addressed. Maybe even the best part of it is that it’s based on the existing Authentication methods policies. Those policies can be used to scope the use of authentication methods and on top of that authentication strengths add even further fine grained control over the usage of those authentication methods. This post will go through the default authentication strengths, followed with the steps for creating custom authentications and for using those authentication strengths. All of that followed with the user experience.

Important: Use the combined security information registration to make sure that users only register authentication methods that are required via the Authentication methods policy.

Note: Authentication strengths is a feature of Conditional Access and has the same licensing requirements.

Built-in authentication strengths

The nice thing about authentication strengths is that it can include a combination of authentication methods. By default, Microsoft provides a few predefined authentications strengths. These built-in authentication strengths are always available, can’t be modified, and will be updated automatically by Microsoft. The table below provides an overview of the different authentication methods that are currently available, the category of those authentication methods in the admin console, and the built-in authentication strengths that contain the authentications methods.

Authentication method combination	Category	Built-in authentication strength
FIDO2 security key	Phishing-resistant MFA	Multi-factor authentication Passwordless MFA Phishing-resistant MFA
Windows Hello for Business	Phishing-resistant MFA	Multi-factor authentication Passwordless MFA Phishing-resistant MFA
Certificate-based authentication (Multi-Factor)	Phishing-resistant MFA	Multi-factor authentication Passwordless MFA Phishing-resistant MFA
Microsoft Authenticator (Phone Sign-in)	Passwordless MFA	Multi-factor authentication Passwordless MFA
Temporary Access Pass (One-time use)	Multi-factor authentication	Multi-factor authentication
Temporary Access Pass (Multi-use)	Multi-factor authentication	Multi-factor authentication
Password + Microsoft Authenticator (Push Notification)	Multi-factor authentication	Multi-factor authentication
Password + Software OATH token	Multi-factor authentication	Multi-factor authentication
Password + Hardware OATH token	Multi-factor authentication	Multi-factor authentication
Password + SMS	Multi-factor authentication	Multi-factor authentication
Password + Voice	Multi-factor authentication	Multi-factor authentication
Federated multi-factor	Multi-factor authentication	Multi-factor authentication
Federated single factor + Software OATH token	Multi-factor authentication	Multi-factor authentication
Federated single factor + Hardware OATH token	Multi-factor authentication	Multi-factor authentication
Federated single factor + SMS	Multi-factor authentication	Multi-factor authentication
Federated single factor + voice	Multi-factor authentication	Multi-factor authentication
Certificate-based authentication (single-factor)	Single-factor authentication	–
SMS	Single-factor authentication	–
Password	Single-factor authentication	–
Federated single-factor	Single-factor authentication	–

Creating custom authentication strengths

Besides using the built-in authentication strength options that are provided by Microsoft, it’s also possible to create custom authentication strengths. That can be useful to determine what (phishing resistant) MFA methods are allowed and approved for accessing apps within the organization. And maybe even more useful when trusting MFA from other Azure AD tenants. In that case, a custom authentication strength can be used to determine which MFA methods can be used by guest users. So, enough reasons to make it useful to look at the creation of a custom authentication strength. The following four steps walk through the pretty straight forward actions to create a custom authentication strength.

1. Open the Microsoft Intune admin center portal navigate to Endpoint security  > Conditional Access, or open the Azure portal and navigate to Azure Active Directory > Security > Conditional Access
2. On the Conditional Access | Overview page, navigate to Authentication strengths and click New authentication strength
3. On the Configure page, as shown below in Figure 1, provide a valid unique name and optionally a description, select the required authentication methods and click Next

4. On the Review page, review the configuration and click Create

Using authentication strengths in Conditional Access policies

When the required authentication strengths are configured, or already available, it’s time to have a look at how to use those authentication strengths within a Conditional Access policy. The following four steps walk through the pretty straight forward actions to create a Conditional Access policy that requires an authentication strength.

1. Open the Microsoft Intune admin center portal navigate to Endpoint security  > Conditional Access, or open the Azure portal and navigate to Azure Active Directory > Security > Conditional Access
2. On the Conditional Access | Overview page, navigate to Policies and click New policy
3. On the Assignments section, configure the following for the different assignments sections

• Users and groups: Select the users that should be assigned with this policy
• Cloud apps or actions: Select the apps that should be assigned with this policy
• Conditions: Select the conditions that should be used as additional filters for assignment of this policy

4. On the Access controls section, as shown below in Figure 2, configure the following for the grant control

• Grant: Configure the access enforcement for this policy that includes the Require authentication strength control to make sure that any required authentication strengths are applicable to the assigned apps and users
• Session: Not applicable for this configuration

5. Select Enable policy > On to enable this policy
6. Select Create to create this policy

Experiencing authentication strengths

When the configuration is in place, it’s time to experience the behavior with authentication strengths. In this case, the user is required to work from a compliant device with a specific authentication strength. That authentication strength requires the user to use Windows Hello for Business or a FIDO2 security key. So, when the user signs in to the device by using Windows Hello, the user won’t notice anything of this configuration change. When the user, however, simply uses a username and password, and wants to access an assigned cloud apps, the user will be prompted to use an additional sign-in method (as shown below in Figure 3). In case the user didn’t have a FIDO2 security key configured, the user would be notified to configure an additional authentication method.

Note: There won’t be a message that tells the user to sign in with Windows Hello.

More information

For more information about authentication strengths with Conditional Access, refer to the following docs.

• Overview of Azure Active Directory authentication strength – Microsoft Entra | Microsoft Learn
• Troubleshoot Azure AD authentication strength – Microsoft Entra | Microsoft Learn