Require Multifactor Authentication is good, but what if the methods that can be registered aren’t powerful enough to secure the resources? Eg: Accept the Auth push notification or SMS or Phone Call method. Those traditional methods have proved user authentication methods must be strengthened in-order to defend today’s sophisticated phishing attacks.
Introducing Authentication strengths
Conditional Access Policies have become one of the core components in the security posture now, helping organizations implement the zero-trust principles a great deal. Recently Microsoft announced Conditional Access Authentication Strengths. This is still in preview at the time of writing. With this, you can use the built-in strength settings or customize the strengths to match the requirement. In this blog post, I will go through the configuration and how to set up strengths and discuss the user experience.
This has the option of applying high-security controls to critical accounts and standard security controls to non-critical accounts.
In this article I’m talking about,
- Where do you need to think about the authentication strengths?
- Prerequisites
- Built-in Strengths
- Configure Custom Auth Strengths in a Conditional Access Policy?
- Apply Authentication strength to a Conditional Access Policy
- Testing and User Experience
- What About the Authentication Methods Policy?
- Final Words, Known Issues and Limitations
Where do you need to think about the authentication strengths?
- 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).
Prerequisites
- Azure AD Premium P1 license at a minimum
- Enable Combined Registration – please refer this article
Built-in Strengths
As I mentioned above, the Authentication Methods page has some built-in strengths you can use, or you can create new strengths by using the given combinations.
Built-in strengths can’t be modified and Microsoft will update them when a new method becomes available.
To make this configuration work, the password strength needs to be set up in a conditional access policy – I will go through that below
Go to Entra.microsoft.com –> Go to Azure Active Directory –> Protect & secure –> Authentication methods –> Authentication strengths
If you go to one strength option, you can see the Authentication flows as below. Users can satisfy the strength requirements by authenticating with any of the allowed combinations
The below table is from Microsoft Learn and it talks about the strength of each method
- 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.
1 Something you have refers to one of the following methods: SMS, voice, push notification, software OATH token. Hardware OATH token is currently not supported.
Configure Custom Auth Strengths in a Conditional Access Policy?
If you require to create Strengths of your own, check below.
Go to Entra.microsoft.com –> Gio to Azure Active Directory –> Protect & secure –> Authentication methods –> Authentication strengths
Click on New authentication strength
Select the required combinations
Review the settings and press create
Apply Authentication strength to a Conditional Access Policy
When you try to create a new CA policy and go to Access controls section you will now see Require authentication strength (Preview) option. As a current limitation, this option can’t be used with Require multifactor authentication option.
Now that you have seen the Authentication strengths, as I mentioned above, authentication strength needs to be applied to a conditional access policy. You will also see the custom strength we created earlier. With the use of this setting, complete the CA policy creation.
Testing and User Experience
Few noteworthy sections from the Learn pages. When the user tries to access a resource that’s protected by an authentication strength/ CA 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, and if not, they will be prompted to provide/ satisfy the new authentication method and will be redirected to combined registration (https://aka.ms/mysecurityinfo)
These factors will come into play
- 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?
Registering Authentication Methods – Interrupt Mode
Ideally, at the time if the user hasn’t registered for strong authentication methods, when they trying to access a protected resource, they will be asked to complete the registration and will be re-directed to the combined registration page at https://aka.ms/mysecurityinfo
Important!
If the user hasn’t already registered to the below methods already, they will not be redirected at the time of accessing the protected resource.
- 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.
User experience when Windows Hello for Business hasn’t been registered before accessing protected resources
What About the Authentication Methods Policy?
For some methods to be used, they need to be enabled from the Azure AD first. I will go with the FIDO2 key experience. Ideally, the Authentication Strength CA Policy defines which methods can be used. If the FIDO2 is set as a part of Authentication Strength, during the sign-in process all settings are checked to determine which methods are allowed to use, which methods are registered, and which methods are required by the CA policy.
Example 1 – Enabling FIDO2 Security Keys
If you required to enable FIDO2 keys for authentication,
- Make sure it is enabled in the Authetication Methods policy along with the user scope
- Make sure the user has registered before hand so the CA Policy will run smoothly.
To do this, go to Authentication Methods –> Policies
Select FIDO2 security key method –> Enable and select the users (all users/ users to groups)
User provisioning – follow this article I wrote a while ago see the user registration steps for the FIDO2 key brand of their choice
FIDO2 Security keys advanced options – Please read this section for more info
Example 2 – Enabling Temporary Access Pass (TAP)
For this to be enabled in the Authentication Strength methods, it needs to be configured 1st. At a high level,
- Enable the authentication method in Authentication Methods –> Policies
- Set the user scope
- Go to the user and setup the TAP method in Authentication methods
Final Words, Known Issues and Limitations
Yes, when you configure some strength options (eg: FIDO2, Windows Hello for business ,etc.) the user has to register for the said method before-hand. However, this is a great way to build a robust as well as a good phishing-resistant mechanism in your zero-trust workflows. With a little bit of testing and understanding the capabilities, you can be ready to apply this when it’s available generally.
I believe by then the known Issues and limitations mentioned in the below section will be resolved as well –Please read this section for more info
In my next post, I will look at how to enable strengths when collaborating with external users and other tenants. Hope to see you soon!
EMS Route - Shehan Perera 
2 thoughts on “How to Configure Azure AD Authentication Strengths”