In the last couple of months, Microsoft released new functionality for Azure AD Conditional Access. All of this functionality is still in public preview, so please read the following article on what to expect from Preview functionality: Preview Terms Of Use | Microsoft Azure

In these series of articles I will go through the following new functionality:

• Part 1: Authentication Strength (this article)
• Part 2: Conditional Access filters for Apps and Workload Identities
• Part 3: Granular control for external user types

Authentication Strength

On October 19th, Alex Weinert the Director of Identity Security at Microsoft announced the public preview of authentication strength. Authentication Strength is a new Grant access control option available when you create or modify an existing Conditional Access policy.

With Authentication Strength we have the option to distinct between the Multi Factor Authentication (MFA) method that can be used to fulfil the Access Control eventually granting access to the targeted resource app that you define in your conditional access policy.

Fact is today that not all MFA methods can be considered equally secure, and in my opinion, customers should start moving away from these lesser secure authentication methods like SMS, phone call, but also only letting users allowing/denying an MFA request they receive in the authenticator app which gets exploited nowadays as well. If you want to know a bit more about this specific subject, I want to suggest that your read this excellent article written by Jeffrey Appel: How to mitigate MFA fatigue and learn from the Uber breach for additional protection (jeffreyappel.nl)

As you can see from the screenshots, you have the ability to choose between different Authentication strengths configurations. Three built-in configuration are provided by Microsoft, but you can also create your own. Let’s go through the built-in ones first, which are:

• Multi-factor authentication
• Passwordless MFA
• Phishing-resistant MFA

Multi-factor authentication

Microsoft calls the Multi-factor authentication authentication strength a medium assurance authentication strength that includes multi-factor, for example password + SMS.

The Multi-factor authentication authentication strength when used allows the following methods:

• Windows Hello for Business
• FIDO2 Security Key
• Certificate Based Authentication (Multi-factor)
• Microsoft Authenticator (Phone Sign-in)
• Temporary Access Pass (One-time use)
• Temporary Access Pass (Multi-use)
• Password + Microsoft Authenticator (Push Notification)
• Password + Software OATH token
• Password + Hardware OATH token
• Password + SMS
• Password + Voice
• Federated Multi-Factor
• Federated Single Factor + Microsoft Authenticator (Push Notification)
• Federated Single Factor + Software OATH token
• Federated Single Factor + Hardware OATH token
• Federated Single Factor + SMS
• Federated Single Factor + Voice

Passwordless MFA

Microsoft calls the Passwordless MFA authentication strength a high assurance authentication strength that includes methods with Cryptographic keys, for example FIDO2 security key.

The Passwordless MFA authentication strength when used allows the following methods:

• Windows Hello for Business
• FIDO2 Security Key
• Certificate Based Authentication (Multi-Factor)
• Microsoft Authenticator (Phone Sign-in)

Phishing-resistant MFA

Microsoft calls the Phishing-resistant MFA authentication strength a method that is phishing resistant that includes methods like FIDO2 and Windows Hello for Business

The Phishing resistant MFA authentication strength when used allows the following methods:

• Windows Hello for Business
• FIDO2 Security Key
• Certificate Based Authentication (Multi-Factor)

Creating your own Authentication Strength Method

You can also define your own Authentication Strength method(s), by clicking on “+ Authentication Strength” which will start the New authentication strength wizard.

In the custom authentication strength wizard you can choose methods from the following categories:

• Phishing-resistant multifactor authentication
  • Windows Hello for Business
  • FIDO2 Security Key
  • Certificate Based Authentication (Multi-factor)
• Passwordless multifactor authentication
  • Microsoft Authenticator (Phone Sign-in
• Multifactor authentication
  • Temporary Access Pass (One-time use)
  • Temporary Access Pass (Multi-use)
  • Password + Microsoft Authenticator (Push Notification)
  • Password + Software OATH token
  • Password + Hardware OATH token
  • Password + SMS
  • Password + Voice
  • Federated Multi-Factor
  • Federated Single Factor + Microsoft Authenticator (Push Notification)
  • Federated Single Factor + Software OATH token
  • Federated Single Factor + Hardware OATH token
  • Federated Single Factor + SMS
  • Federated Single Factor + Voice
• Single-factor authentication
  • Certificate Based Authentication (Single Factor)
  • SMS
  • Password
  • Federated Single-Factor

Configure specific allowed FIDO2 keys

For the FIDO2 Security key you can even specify the allowed FIDO2 keys by specifying their Authenticator Attestation GUIDs (AAGUIDs). In the example below I’m configuring the Feitan AllinPass Fido 2 as allowed FIDO2 method

Authentication Strength use cases

The Authentication Strength option allows for all kinds of new scenario’s which can be accomplished using Conditional Access.

Personally I would start with making sure that Administrative accounts can only sign in using Password-less MFA options, removing legacy MFA factors like SMS and Phone voice call if still in use and you are not able to turn those off on the global level. Another interesting option is to combine Authentication Strength with Authentication Context, so that you can require a specific MFA method, when a SharePoint site with a specific sensitivity label gets accessed, or when a certain session control policy is triggered in Microsoft Defender for Cloud Apps (MDCA).

A first look at Azure AD Conditional Access authentication context

We could also leverage authentication strength when user risk or sign-in risk as part of Azure AD identity protection is High. Another option is to use Authentication Strength in combination with cross-tenant settings as configured in Azure AD.

Authentication Strength in action

Before you start exploring Authentication Strength, make sure to read the known issues, which are documented here: Overview of Azure Active Directory authentication strength (preview) – Known issues.

In my case, I tried building the following scenario:

See what happens if an Administrator role eligible user logs in with an authentication method, which isn’t supported as an authentication method after elevating to its administrator role using Privileged Identity Management (PIM).

While building this solution I learned the following:

• If for example SMS is turned off in the Global Settings, it’s not available for the user to use if it’s included in the Authentication Strength policy.

• It’s not possible to combine Multi Factor Authentication and Authentication Strength as grant controls in your Conditional Access policy, this is also noted when you create the policy.

• You cannot combine Authentication Strength as a grant access control, while still having applicable Conditional Access policies using the “Multi Factor Authentication” access control. All applicable policies must use the Authentication Strength method, if one of them is using MFA you will receive a message similar like the one below.

• When having multiple Conditional Access policies setting Authentication Strength, but with different authentication strengths set, the outcome can become unreliable. Say for example you have One CA policy with the “Multi-factor Authentication” authentication strength and another with the “Passwordless MFA” authentication strength, and both are applicable to the scenario, the outcome of the applied authentication strength can differ on a per scenario basis, making the use case unreliable.
• I also had issues with using the Authentication App, when making the Passwordless MFA default option available to the CA policy requiring MFA for the Admin roles. In this case after elevating my rights, I was prompted for MFA but couldn’t use the Phone sign-in which I configured on my admin account in the Microsoft Authenticator App, resulting in the “Let’s try something else” method. I could use another method (my configured FIDO2 security key) successfully luckily. The only way for me to make this scenario work was to make the a new Authentication Strength policy and include the Password + Microsoft Authenticator (Push Notification) option as well.

Authentication Strength Conclusion

Authentication Strength is a welcome addition to the Conditional Access Grant access control options already available and will eventually replace the current “Require MFA” option. Most ideally you want to configure your Conditional Access policies in such a way that all MFA required policies are enforced in the most secure way. Authentication Strength can help to setup a phased approach in order to move your users to these new secure ways of accessing your company apps and data, and provide you with options to enforce stronger authentication methods in certain use cases.

Be careful though with the current caveats causing authentication loops and thoroughly test your modified/new Conditional Access policies before deploying this new grant control.