Conditional Access authentication strength

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 + text message.

Authentication strength is based on the Authentication methods policy, where administrators can scope authentication methods for specific users and groups to be used across Microsoft Entra ID 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

• Microsoft Entra 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: text message, 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. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.

2. Browse to Protection > Authentication methods > Authentication strengths.

3. Select New authentication strength.

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

5. Optionally provide a Description.

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

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

How an authentication strength policy is evaluated during sign-in

The authentication strength Conditional Access policy defines which methods can be used. Microsoft Entra ID 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 + text message. 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.

How multiple Conditional Access authentication strength policies are evaluated

In general, when there are multiple Conditional Access policies applicable for a single sign-in, all conditions from all policies must be met. In the same vein, when there are multiple Conditional Access policies which apply authentication strengths to the sign-in, the user must satisfy all of the authentication strength policies. For example, if two different authentication strength policies both require FIDO2, the user can use their FIDO2 security key and satisfy both policies. If the two authentication strength policies have different sets of methods, the user must use multiple methods to satisfy both policies.

How multiple Conditional Access authentication strength policies are evaluated for registering security info

For security info registration, the authentication strength evaluation is treated differently – authentication strengths that target the user action of Registering security info are preferred over other authentication strength policies that target All cloud apps. All other grant controls (such as Require device to be marked as compliant) from other Conditional Access policies in scope for the sign-in will apply as usual.

For example, let’s assume Contoso would like to require their users to always sign in with a phishing-resistant authentication method and from a compliant device. Contoso also wants to allow new employees to register these authentication methods using a Temporary Access Pass (TAP). TAP can’t be used on any other resource. To achieve this goal, the admin can take the following steps:

1. Create a custom authentication strength named Bootstrap and recovery that includes the Temporary Access Pass authentication combination, it can also include any of the phishing-resistant MFA methods.
2. Create a Conditional Access policy which targets All cloud apps and requires Phishing-resistant MFA authentication strength AND Require compliant device grant controls.
3. Create a Conditional Access policy that targets the Register security information user action and requires the Bootstrap and recovery authentication strength.

As a result, users on a compliant device would be able to use a Temporary Access Pass to register FIDO2 security keys and then use the newly registered FIDO2 security key to authenticate to other resources (such as Outlook).

Note

If multiple Conditional Access policies target the Register security information user action, and they each apply an authentication strength, the user must satisfy all such authentication strengths to sign in.

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, Microsoft Entra ID evaluates if the methods they have previously used satisfy the authentication strength. If a satisfactory method was used, Microsoft Entra ID grants access to the resource. For example, let's say a user signs in with password + text message. 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.

Register passwordless authentication methods

The following authentication methods can't be registered as part of combined registration interrupt mode. Make sure users are registered for these methods before you apply a Conditional Access policy that can require them to be used for sign-in. If a user isn't registered for these methods, they can't access the resource until the required method is registered.

Method	Registration requirements
Microsoft Authenticator (phone sign-in)	Can be registered from the Authenticator app.
FIDO2 security key	Can be registered using combined registration managed mode.
Certificate-based authentication	Requires administrator setup; can't 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.

Federated user experience

For federated domains, MFA may be enforced by Microsoft Entra 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.

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 Microsoft Entra 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. A Microsoft Entra user authenticates in their home Microsoft Entra tenant. Then when they access your resource, Microsoft Entra ID 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 Microsoft Entra 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
text message 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, a Microsoft Entra user authenticates with their own account in their home tenant. Then when this user tries to access your resource, Microsoft Entra ID applies the authentication strength Conditional Access policy and checks to see if you've enabled MFA trust.

• If MFA trust is enabled, Microsoft Entra ID 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, Microsoft Entra ID presents the user with a challenge to complete MFA in the home tenant using an acceptable authentication method.
• If MFA trust is disabled, Microsoft Entra ID 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.)

Limitations

• Conditional Access policies are only evaluated after the initial authentication - As a result, authentication strength doesn't 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 aren't currently supported by authentication strength - The Email one-time pass (Guest) authentication method isn't included in the available combinations.

• Windows Hello for Business – If the user signed in with 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 signed in with another method like password as their primary authenticating method, and the authentication strength requires Windows Hello for Business, they aren't prompted to sign in with Windows Hello for Business. The user needs to restart the session, choose Sign-in options, and select a method required by the authentication strength.

Known isssues

The following known issues are currently being addressed:

• Sign-in frequency - If both sign-in frequency and authentication strength requirements apply to a sign-in, and the user has previously signed in using a method that meets the authentication strength requirements, the sign-in frequency requirement doesn't apply. Sign-in frequency allows you to set the time interval for re-authentication of users based on their credentials, but it isn't fully integrated with authentication strength yet. It works independently and doesn't currently impact the actual sign-in procedure. Therefore, you may notice that some sign-ins using expired credentials don't prompt re-authentication and the sign-in process proceeds successfully.

• FIDO2 security key Advanced options - Advanced options aren't supported for external users with a home tenant that is located in a different Microsoft cloud than the resource tenant.

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 Microsoft Entra ID 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

• Microsoft Entra ID P1 - Your tenant needs to have Microsoft Entra ID 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