Conditional Access authentication strength (preview)

Authentication strength is a Conditional Access control that allows administrators to specify which combination of authentication methods can be used to access a resource. For example, they can make only phishing-resistant authentication methods available to access a sensitive resource. But to access a nonsensitive resource, they can allow less secure multifactor authentication (MFA) combinations, such as password + SMS.

Authentication strength is based on the Authentication methods policy, where administrators can scope authentication methods for specific users and groups to be used across Azure Active Directory (Azure AD) federated applications. Authentication strength allows further control over the usage of these methods based upon specific scenarios such as sensitive resource access, user risk, location, and more.

Administrators can specify an authentication strength to access a resource by creating a Conditional Access policy with the Require authentication strength control. They can choose from three built-in authentication strengths: Multifactor authentication strength, Passwordless MFA strength, and Phishing-resistant MFA strength. They can also create a custom authentication strength based on the authentication method combinations they want to allow.

Scenarios for authentication strengths

Authentication strengths can help customers address scenarios, such as:

• Require specific authentication methods to access a sensitive resource.
• Require a specific authentication method when a user takes a sensitive action within an application (in combination with Conditional Access authentication context).
• Require users to use a specific authentication method when they access sensitive applications outside of the corporate network.
• Require more secure authentication methods for users at high risk.
• Require specific authentication methods from guest users who access a resource tenant (in combination with cross-tenant settings).

Authentication strengths

An authentication strength can include a combination of authentication methods. Users can satisfy the strength requirements by authenticating with any of the allowed combinations. For example, the built-in Phishing-resistant MFA strength allows the following combinations:

• Windows Hello for Business

  Or

• FIDO2 security key

  Or

• Azure AD Certificate-Based Authentication (Multi-Factor)

Built-in authentication strengths

Built-in authentication strengths are combinations of authentication methods that are predefined by Microsoft. Built-in authentication strengths are always available and can't be modified. Microsoft will update built-in authentication strengths when new methods become available.

The following table lists the combinations of authentication methods for each built-in authentication strength. Depending on which methods are available in the authentication methods policy and registered for users, they can use any one of the combinations to sign-in.

• MFA strength - the same set of combinations that could be used to satisfy the Require multifactor authentication setting.
• Passwordless MFA strength - includes authentication methods that satisfy MFA but don't require a password.
• Phishing-resistant MFA strength - includes methods that require an interaction between the authentication method and the sign-in surface.

Authentication method combination	MFA strength	Passwordless MFA strength	Phishing-resistant MFA strength
FIDO2 security key	✅	✅	✅
Windows Hello for Business	✅	✅	✅
Certificate-based authentication (Multi-Factor)	✅	✅	✅
Microsoft Authenticator (Phone Sign-in)	✅	✅
Temporary Access Pass (One-time use AND Multi-use)	✅
Password + something you have1	✅
Federated single-factor + something you have1	✅
Federated Multi-Factor	✅
Certificate-based authentication (single-factor)
SMS sign-in
Password
Federated single-factor

¹ Something you have refers to one of the following methods: SMS, voice, push notification, software OATH token and Hardware OATH token.

The following API call can be used to list definitions of all the built-in authentication strengths:

GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrengths/policies?$filter=policyType eq 'builtIn'

Custom authentication strengths

In addition to the three built-in authentication strengths, administrators can create up to 15 of their own custom authentication strengths to exactly suit their requirements. A custom authentication strength can contain any of the supported combinations in the preceding table.

1. In the Azure portal, browse to Azure Active Directory > Security > Authentication methods > Authentication strengths (Preview).

2. Select New authentication strength.

3. Provide a descriptive Name for your new authentication strength.

4. Optionally provide a Description.

5. Select any of the available methods you want to allow.

6. Choose Next and review the policy configuration.

   

Update and delete custom authentication strengths

You can edit a custom authentication strength. If it's referenced by a Conditional Access policy, it can't be deleted, and you need to confirm any edit. To check if an authentication strength is referenced by a Conditional Access policy,click Conditional Access policies column.

FIDO2 security key advanced options

Custom authentication strengths allow customers to further restrict the usage of some FIDO2 security keys based on their Authenticator Attestation GUIDs (AAGUIDs). The capability allows administrators to require a FIDO2 key from a specific manufacture in order to access the resource. To require a specific FIDO2 security key, complete the preceding steps to create a custom authentication strength, select FIDO2 Security Key, and click Advanced options.

Next to Allowed FIDO2 Keys click +, copy the AAGUID value, and click Save.

Using authentication strength in Conditional Access

After you determine the authentication strength you need, you'll need to create a Conditional Access policy to require that authentication strength to access a resource. When the Conditional Access policy gets applied, the authentication strength restricts which authentication methods are allowed.

How authentication strength works with the Authentication methods policy

There are two policies that determine which authentication methods can be used to access resources. If a user is enabled for an authentication method in either policy, they can sign in with that method.

• Security > Authentication methods > Policies is a more modern way to manage authentication methods for specific users and groups. You can specify users and groups for different methods. You can also configure parameters to control how a method can be used.

  

• Security > Multifactor Authentication > Additional cloud-based multifactor authentication settings is a legacy way to control multifactor authentication methods for all of the users in the tenant.

  

Users may register for authentications for which they are enabled, and in other cases, an administrator can configure a user's device with a method, such as certificate-based authentication.

The authentication strength Conditional Access policy defines which methods can be used. Azure AD checks the policy during sign-in to determine the user’s access to the resource. For example, an administrator configures a Conditional Access policy with a custom authentication strength that requires FIDO2 Security Key or Password + SMS. The user accesses a resource protected by this policy. During sign-in, all settings are checked to determine which methods are allowed, which methods are registered, and which methods are required by the Conditional Access policy. To be used, a method must be allowed, registered by the user (either before or as part of the access request), and satisfy the authentication strength.

User experience

The following factors determine if the user gains access to the resource:

• Which authentication method was previously used?
• Which methods are available for the authentication strength?
• Which methods are allowed for user sign-in in the Authentication methods policy?
• Is the user registered for any available method?

When a user accesses a resource protected by an authentication strength Conditional Access policy, Azure AD evaluates if the methods they have previously used satisfy the authentication strength. If a satisfactory method was used, Azure AD grants access to the resource. For example, let's say a user signs in with password + SMS. They access a resource protected by MFA authentication strength. In this case, the user can access the resource without another authentication prompt.

Let's suppose they next access a resource protected by Phishing-resistant MFA authentication strength. At this point, they'll be prompted to provide a phishing-resistant authentication method, such as Windows Hello for Business.

If the user hasn't registered for any methods that satisfy the authentication strength, they are redirected to combined registration.

If the authentication strength doesn't include a method that the user can register and use, the user is blocked from sign-in to the resource.

Registering authentication methods

The following authentication methods can't be registered as part of combined registration interrupt mode:

• Microsoft Authenticator (phone sign-in) - Can be registered from the Authenticator app.
• FIDO2 - can be registered using combined registration managed mode.
• Certificate-based authentication - Require administrator setup, cannot be registered by the user.
• Windows Hello for Business - Can be registered in the Windows Out of Box Experience (OOBE) or the Windows Settings menu.

If a user isn't registered for these methods, they can't access the resource until the required method is registered. For the best user experience, make sure users complete combined registered in advance for the different methods they may need to use.

Federated user experience

For federated domains, MFA may be enforced by Azure AD Conditional Access or by the on-premises federation provider by setting the federatedIdpMfaBehavior. If the federatedIdpMfaBehavior setting is set to enforceMfaByFederatedIdp, the user must authenticate on their federated IdP and can only satisfy the Federated Multi-Factor combination of the authentication strength requirement. For more information about the federation settings, see Plan support for MFA.

If a user from a federated domain has multifactor authentication settings in scope for Staged Rollout, the user can complete multifactor authentication in the cloud and satisfy any of the Federated single-factor + something you have combinations. For more information about staged rollout, see Enable Staged Rollout using Azure portal.

External users

The Authentication methods policy is especially useful for restricting external access to sensitive apps in your organization because you can enforce specific authentication methods, such as phishing-resistant methods, for external users.

When you apply an authentication strength Conditional Access policy to external Azure AD users, the policy works together with MFA trust settings in your cross-tenant access settings to determine where and how the external user must perform MFA. An Azure AD user authenticates in their home Azure AD tenant. Then when they access your resource, Azure AD applies the policy and checks to see if you've enabled MFA trust. Note that enabling MFA trust is optional for B2B collaboration but is required for B2B direct connect.

In external user scenarios, the authentication methods that can satisfy authentication strength vary, depending on whether the user is completing MFA in their home tenant or the resource tenant. The following table indicates the allowed methods in each tenant. If a resource tenant has opted to trust claims from external Azure AD organizations, only those claims listed in the “Home tenant” column below will be accepted by the resource tenant for MFA. If the resource tenant has disabled MFA trust, the external user must complete MFA in the resource tenant using one of the methods listed in the “Resource tenant” column.

Authentication method	Home tenant	Resource tenant
SMS as second factor	✅	✅
Voice call	✅	✅
Microsoft Authenticator push notification	✅	✅
Microsoft Authenticator phone sign-in	✅	✅
OATH software token	✅	✅
OATH hardware token	✅
FIDO2 security key	✅
Windows Hello for Business	✅

For more information about how to set authentication strengths for external users, see Conditional Access: Require an authentication strength for external users.

User experience for external users

An authentication strength Conditional Access policy works together with MFA trust settings in your cross-tenant access settings. First, an Azure AD user authenticates with their own account in their home tenant. Then when this user tries to access your resource, Azure AD applies the authentication strength Conditional Access policy and checks to see if you've enabled MFA trust.

• If MFA trust is enabled, Azure AD checks the user's authentication session for a claim indicating that MFA has been fulfilled in the user's home tenant. See the preceding table for authentication methods that are acceptable for MFA when completed in an external user's home tenant. If the session contains a claim indicating that MFA policies have already been met in the user's home tenant, and the methods satisfy the authentication strength requirements, the user is allowed access. Otherwise, Azure AD presents the user with a challenge to complete MFA in the home tenant using an acceptable authentication method.
• If MFA trust is disabled, Azure AD presents the user with a challenge to complete MFA in the resource tenant using an acceptable authentication method. (See the table above for authentication methods that are acceptable for MFA by an external user.)

Known issues

• Users who signed in by using certificate-based authentication aren't prompted to reauthenticate - If a user first authenticated by using certificate-based authentication and the authentication strength requires another method, such as a FIDO2 security key, the user isn't prompted to use a FIDO2 security key and authentication fails. The user must restart their session to sign-in with a FIDO2 security key.

• Using 'Require one of the selected controls' with 'require authentication strength' control - After you select authentication strengths grant control and additional controls, all the selected controls must be satisfied in order to gain access to the resource. Using Require one of the selected controls isn't applicable, and will default to requiring all the controls in the policy.

• Authentication loop - When the user is required to use Microsoft Authenticator (Phone Sign-in) but the user is not registered for this method, they will be given instructions on how to set up the Microsoft Authenticator, that does not include how to enable Passwordless sign-in. As a result, the user can get into an authentication loop. To avoid this issue, make sure the user is registered for the method before the Conditional Access policy is enforced. Phone Sign-in can be registered using the steps outlined here: Add your work or school account to the Microsoft Authenticator app ("Sign in with your credentials")

Limitations

• Conditional Access policies are only evaluated after the initial authentication - As a result, authentication strength will not restrict a user's initial authentication. Suppose you are using the built-in phishing-resistant MFA strength. A user can still type in their password, but they will be required to use a phishing-resistant method such as FIDO2 security key before they can continue.

• Require multifactor authentication and Require authentication strength can't be used together in the same Conditional Access policy - These two Conditional Access grant controls can't be used together because the built-in authentication strength Multifactor authentication is equivalent to the Require multifactor authentication grant control.

• Authentication methods that are currently not supported by authentication strength - The Email one-time pass (Guest) authentication method is not included in the available combinations.

• Windows Hello for Business – If the user has used Windows Hello for Business as their primary authentication method it can be used to satisfy an authentication strength requirement that includes Windows Hello for Business. However, if the user has used another method as their primary authenticating method (for example, password) and the authentication strength requires them to use Windows Hello for Business they will not be prompted to use not register for Windows Hello for Business.

FAQ

Should I use authentication strength or the Authentication methods policy?

Authentication strength is based on the Authentication methods policy. The Authentication methods policy helps to scope and configure authentication methods to be used across Azure AD by specific users and groups. Authentication strength allows another restriction of methods for specific scenarios, such as sensitive resource access, user risk, location, and more.

For example, the administrator of Contoso wants to allow their users to use Microsoft Authenticator with either push notifications or passwordless authentication mode. The administrator goes to the Microsoft Authenticator settings in the Authentication method policy, scopes the policy for the relevant users and set the Authentication mode to Any.

Then for Contoso’s most sensitive resource, the administrator wants to restrict the access to only passwordless authentication methods. The administrator creates a new Conditional Access policy, using the built-in Passwordless MFA strength.

As a result, users in Contoso can access most of the resources in the tenant using password + push notification from the Microsoft Authenticator OR only using Microsoft Authenticator (phone sign-in). However, when the users in the tenant access the sensitive application, they must use Microsoft Authenticator (phone sign-in).

Prerequisites

• Azure AD Premium P1 - Your tenant needs to have Azure AD Premium P1 license to use Conditional Access. If needed, you can enable a free trial.
• Enable combined registration - Authentication strengths are supported when using combined MFA and SSPR registration. Using the legacy registration will result in poor user experience as the user may register methods that aren't required by the authentication method policy.

Next steps

• Troubleshoot authentication strengths