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.

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.

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.

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

Set “Enable policy” to true and create it.

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.

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.

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

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.

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.

Of course, you should rollout such changes in waves and give your admin users lead time to register their FIDO2 security key (https://aka.ms/mysecurityinfo).

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.

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…

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

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.

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.

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

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.

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.

Conclusion

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.

Links

• Official documentation - Conditional Access authentication strength (preview)
• Entra ID (Azure AD) authentication strengths API overview