Conditional Access Authentication strength

When using Microsoft Entra Entra ID (Azure AD), you can choose between a wide range of MFA options as an admin and user. Depending on the method you choose this can be a very strong second factor (e.g., FIDO2), or it could be a weaker second factor like text messages. Up until now there was no way to distinguish between the different methods.

But with the recent announcement about authentication strength this changes.

Authentication strength is an additional control in your conditional access policies toolset. It allows you to restrict access to certain applications or for certain user groups when not using a specified second factor.

I’m excited to have participated in the private preview of Authentication Strengths and had active product conversations with engineering about this new feature. Now that the feature is officially in public preview, I can share with you the insights I gained during this preview as a contributor!

There are three different built-in presets you can choose from:

  1. Phishing resistant MFA
  2. Passwordless MFA
  3. Multi-factor authentication

Those presets are a great starting point, but you can also create your own authentication strengths policy if needed. You can select from all the available multi factor options. This allows for really fine-grained control.

Authentication combinations

Currently the following combinations are available to select when building your own authentication strength policy. For reference I added the built-in category as well. Keep in mind that methods with high authentication strength are also included in the lower categories. So Passwordless MFA also includes FIDO2 security keys.

Authentication Combination Description Category
fido2 FIDO2 Security Key Phishing-resistant MFA
windowsHelloForBusiness Windows Hello For Business Phishing-resistant MFA
x509CertificateMultiFactor Certificate Based Authentication (Multi-Factor) Phishing-resistant MFA
deviceBasedPush Microsoft Authenticator (Phone Sign-in) Passwordless MFA
federatedMultiFactor Federated Multi-Factor Multi-factor authentication
federatedSingleFactor Federated Single-Factor Multi-factor authentication
hardwareOathfederatedSingleFactor Federated Single-Factor + Hardware OATH token Multi-factor authentication
microsoftAuthenticatorPushfederatedSingleFactor Federated Single-Factor + Microsoft Authenticator (Push Notification) Multi-factor authentication
password Password Multi-factor authentication
passwordhardwareOath Password + Hardware OATH token Multi-factor authentication
passwordmicrosoftAuthenticatorPush Password + Microsoft Authenticator (Push Notification) Multi-factor authentication
passwordsms Password + SMS Multi-factor authentication
passwordsoftwareOath Password + Software OATH token Multi-factor authentication
passwordvoice Password + Voice Multi-factor authentication
passwordx509CertificateMultiFactor Password + Certificate Based Authentication (Multi-Factor) Multi-factor authentication
passwordx509CertificateSingleFactor Password + Certificate Based Authentication (Single-Factor) Multi-factor authentication
sms SMS Multi-factor authentication
smsfederatedSingleFactor Federated Single-Factor + SMS Multi-factor authentication
softwareOathfederatedSingleFactor Federated Single-Factor + Software OATH token Multi-factor authentication
temporaryAccessPassMultiUse Temporary Access Pass (Multi-use) Multi-factor authentication
temporaryAccessPassOneTime Temporary Access Pass (One-time use) Multi-factor authentication
voicefederatedSingleFactor Federated Single-Factor + Voice Multi-factor authentication
x509CertificateSingleFactor Certificate Based Authentication (Single Factor) Multi-factor authentication
If you want to query the available combinations yourself, you can use the following graph endpoint

Use cases

From a use case perspective here are three examples I will use to explain the creation and usage of authentication strength

  1. Protect a critical application from access
  2. Prevent administrators using a non-phishing resistant method
  3. Raise the MFA bar for guest users

Protect a critical application from access

You want to protect a certain application, e.g., your HR system, from being accessed using a possibly phishable credential over the internet but still allow all credentials when the device used is compliant.

In this case you can use the built-in definition “Phishing resistant MFA”.

Open up the Entra ID (Azure AD) portal and switch to Security, Authentication methods, Authentication strengths.

Built-In Authentication strengths

Here you see all built-in authentication strength. To actually use them, you have to create a Conditional Access Policy. Switch over to “Conditional Access Policies” and create a new one.

Give the CAP a meaningful name and assign it to all your users. Since it will be also scoped to a specific app, exclusions should not be needed.

Next select the application you want to protect.

Conditional Access App selection

Using the access control portion of the CAP enable “Require authentication strength”.

At the moment you must not also select “Require device to be compliant” because the OR mechanism does not work in the public preview. The PG is working at an fix for this problem.

Authentication strengths in grant selection

Set “Enable policy” to true and create it.

Enable conditional access policy

Prevent administrators using a non-phishing resistant method

For this example, we will not use one of built-in template, but create a custom policy.

In the Entra ID (Azure AD) portal switch to Security, Authentication methods and choose Authentication strength.

New authentication strengths

Create a new policy and name it “Phishing-resistant and TAP”

Next select all the phishing resistant method available. Feel free to remove those you don’t need e.g., certificate based sign-in. Also select both Temporary Access Pass methods, since this will be the backup method when an admin has lost their FIDO2 security key, and it can also be used as a bootstrap method for setting up the security key in the first place.

Select different authentication strengths

Now you need to create a conditional access policy to enforce this policy.

As always with conditional access policies you should test this change before rolling it out to all users.

For users, choose “Directory roles” and select all available Entra ID (Azure AD) roles. You might want to skip the reader roles since they do not allow changes. Also exclude any On-Premises Directory Synchronization Service accounts and your break glass account.

Next select all cloud apps for the scope and then define your custom authentication strength policy as a grant control.

Select all cloud apps

Set grant control to custom authentication strengths

To test your newly created policy sign in using an affected admin user and try to use your password to sign in.

If an admin user still signs in using a password, she will be prompted to use a stronger authentication method instead.

Sign in only with defined authentication strengths

Be aware that the user’s password could still be phished, but the attacker cannot intercept the second factor rendering the password useless.

Of course, you should rollout such changes in waves and give your admin users lead time to register their FIDO2 security key (

After you enabled this policy for everybody, the only way to sign in using a phishable method is when using a TAP. Don’t forget to explain to the admins how they can issue one for their colleagues if needed.

Keep in mind that currently it is not possible to use FIDO2 security keys on iOS and Android, rendering the use of those operating systems impossible for administrators.

FIDO2 security advanced options

You can even go a step further and lock down which FIDO2 security keys your administrators can use. This might be the case if you have a special firmware in place or did some extra certification with the vendor and want to make sure that your administrators only use those keys.

This will get even more relevant in the future when new versions of FIDO2 allow for new multi-device usage (passkeys). While you might want to allow passkeys for your main workforce, you might need to verify that the keys used by your administrators cannot save the private key in a non hardware HSM and sync it to the private account at Google or Apple.

For each key model, the vendor assigns an Authenticator Attestation Globally Unique ID which identifies the exact model.

When creating the authentication strength policy you can select advanced options for FIDO2 security key…

FIDO2 security key advanced options

…and define the AAGUIDs of the security keys you have approved for usage.

Authenticator Attestation GUIDs

Raise the MFA bar for guest users

Imaging you want to use the new cross tenant settings to trust your partners MFA method.

As of now the following MFA methods in the guests home tenant would be accepted in your (resource) tenant.

  • SMS
  • Voice call
  • Microsoft Authenticator push notification
  • Microsoft Authenticator phone sign-in
  • OATH software token
  • OATH hardware token
  • FIDO2 security key
  • Windows Hello for Business

Now you can restrict this to only MFA methods that are allowed in your authentication strength policy.

Start by enabling the inbound trust settings for MFA in the Cross-tenant access settings menu. You can do this either for all tenants, or scope it to specific partner tenants.

Cross tenant MFA trust

In this case I trust MFA from every other tenant. I can do this with confidence, because now I create an authentication strength policy that only allows certain combinations I deem fit for my guests.

Custom authentication strengths for guests

Next, I create a conditional access policy requiring all guest users to use the newly created custom authentication strength.

Require conditional access policy for guest and external accounts

Select custom Guest MFA authentication strengths

After enabling this policy, when a user has only used MFA using a SMS or phone call, she will be prompted to satisfy the requirement with MFA. Depending on what is registered with the user this can be either the Authenticator app or a security key.

Sign in as guest with app...

...or step up your authentication strengths if needed

If the user has no prior MFA methods registered or no sufficient one, she will be required to do so. But in contrary to the old way, this registration happens in the home tenant of the user.

Register stronger authentication method if needed


As you can see Authentication strength and Conditional Access Policies together are a simple but powerful method to make sure your users are protected by a level of MFA you decide. Since Microsoft introduced the Azure MFA methods like SMS and phone-call, the attack landscape changed quite a bit and so did the techniques available to us as defenders.

With FIDO2 or certificate-based authentication in Entra ID (Azure AD) there are methods available to secure even the most at-risk users. And with Authentication strength an additional piece of this puzzle was released and can help us to make those accounts even more secure and not rely on human judgment which MFA method to use.

In the collaboration setting this allows you to trust MFA from other tenants without introducing an additional risk because the other tenant might not be as secure as your tenant by default. You can control which MFA methods you allow and which ones you prevent. If this means you trust every tenant’s MFA is up to you. But now you could.