Newly released to Conditional Access in Azure AD is the “Authentication Strengths” settings. These allow you to control the strength of the authentication you need to be used for that conditional access rule. Before this feature was available you had the option of allowing access with no second factor, MFA as a second factor (any MFA), requiring a hybrid AAD Joined or compliant device, as well as options controlling the apps you can use.
Now you have the option to control exactly what type of second factor of authentication you require. Indeed, the MFA control in Conditional Access now recommends you try this feature instead of just selecting MFA:
There are three Authentication Strength rules in place “out of the box”, and you can add your own. Lets look at the defaults and then look at creating our own.
The defaults are:
- Multi-Factor Authentication
- Passwordless MFA
- Phish resistant MFA
Multi-Factor Authentication is the same as the previous MFA control in Conditional Access – that is, it allows the use of 17 different MFA methods. Its a long list, and so this screenshot from the area where you add your own Authentication Strengths gives you an idea of what it includes:
Passwordless MFA is four individual controls, which are Windows Hello for Business, FIDO2 Security Keys, Certificate Based Authentication (Multi-Factor) and Microsoft Authenticator (Phone Sign-On). These four are high assurance authentication strength methods.
Phish Resistant MFA are three separate controls (Windows Hello for Business, FIDO2 Security Keys, Certificate Based Authentication (Multi-Factor)).
Notice how each group is a subset of the other, growing in strength as you move down the list.
Microsoft’s recommendation to use Authentication Strengths is to move from MFA granted Conditional Access rules, and if you do this and change to the Multi-Factor Authentication option all you have done is change a setting in Conditional Access without any impact on the user. The MFA check box and the Multi-Factor Authentication strength control are the same thing.
Where this feature really benefits you and your organization is to move to Passwordless MFA or Phish Resistant MFA controls. Lets see how to do that with an example from my tenant where I have an “admins require MFA” Conditional Access rule.
Notice the recommendation to change as mentioned above and the warning that you cannot enable Authentication Strengths when MFA is selected. So the migration route for updating your control is to turn off MFA and turn on Authentication Strengths in single action – click Save after both changes:
So we have made a change and achieved absolutely nothing – so lets ensure that Admins impacted by this Conditional Access rule require a passwordless MFA method – that is, admins now cannot use their password to authenticate! All you need to do is change the Multi-Factor Authentication strength to the Passwordless MFA authentication strength as shown:
What does that look like for the user impacted by that Conditional Access rule? Lets see the login sequence for Azure AD Portal:
Options for SMS or phone call (and 11 other methods that are not in the Passwordless MFA Authentication Strength are now not available to me to use.
Finally, what if you want an Authentication Strength that is different than the defaults Microsoft offer – for example if you want FIDO2 keys only for your users or admins. For this you need to create a Custom Authentication Strength. These are found in Azure AD Portal > Security > Authentication Methods > Authentication Methods > Authentication Strengths or via the new Entra Admin Center under Protect & Secure > Authentication Methods > Authentication Strengths:
Create a new Authentication Strength, which we will call FIDO2 Passwordless Only. For Security Keys you can even list which keys are allowed under Advanced Options:
Once the Authentication Strength is created, move back to the Conditional Access rules to update your rules to use the new Authentication Strength:
And the new user experience – its the same as above, but if you don’t use the required Authentication Strength you are prompted to continue authenticating until you do:
To get to the above screenshot I tried a number of different login methods (too many to screenshot and add here). I entered my username followed by my password. I got the below as I had my Security Key in my USB port:
So I removed the key and clicked the banner to use “Hello or a security key” – my custom Authentication Strength does not allow Windows Hello for Business, so the banner is wrong but I am not offered Hello as an option which my device will successfully do for me if it was allowed. I had removed my security key and so I was prompted for standard MFA (my phone got a push notification) but even on completing that, I got the above again – I could not login until I inserted by Security Key and performed a step-up authentication with the only method I had allowed to be used.
So the big question – is this the removing of passwords from Azure AD. No, not really – but it is the enforcement of authentication methods that can really protect your accounts. If you have a passwordless method enforced for a user via Conditional Access then can still go username + password, but are now required to do a passwordless auth after that – so why bother, why not just click “Sign-in Options” at the bottom of the initial login screen and select the top option below – then you never enter your password, because its not ever needed any more.
What it is is the removal of the “Per-User Legacy MFA” rules for controlling which MFA methods you can use. That is, this is not important anymore:
Call to action – take your existing “MFA for Admin” Conditional Access rules (you do have these don’t you?) and increase the Authentication Strength on them. Then move to maybe a new rule that covers your high risk users and which reduces the MFA methods available to them.
Leave a Reply