Secure Sloth Secure Sloth

What in the MFA…? Deconflicting MFA settings in Microsoft Entra ID

Peer reviewed by: Sean Johnstone

Overview

Once upon a time, it used to be sufficient for a user to register any second factor for multifactor authentication (MFA), since it is generally more secure to have some type of MFA than to have nothing at all; however, certain threat actor groups (which shall not be named in this post) quickly found new ways to circumvent MFA. For example, to compromise phone-based MFA, such as SMS text or voice call, threat actors started to perform SIM swapping and voice forwarding techniques that would intercept the SMS one-time passcode or the verification phone call needed to complete a login. Even software-based MFA, such as push notifications and number matching, may be circumvented via MFA fatigue and adversary-in-the-middle (AiTM) attacks. Given all of these challenges with conventional MFA methods, phishing-resistant MFA, such FIDO2 or Web Authentication (WebAuthn), is considered to be the gold standard for securing user logins but can be difficult to implement due to hardware costs and/or operational overhead.

In Microsoft Entra ID (Entra ID), the cloud-based directory service used by Microsoft 365 (M365) and Microsoft Azure (Azure), there are two settings that dictate what second factors can be used for MFA. The “authentication methods policy” is the Microsoft recommended way to manage authentication methods and includes more modern methods, like passwordless authentication; similarly, the legacy “Multifactor authentication settings” also allow an organization to manage authentication methods for all users in the tenant. In this post, we will walk through the following scenarios where a user may be able to use weaker methods for MFA despite perceived restrictions being in place:

  1. The “authentication methods policy” disallows SMS or voice MFA but “Multifactor authentication settings” permit SMS or voice

  2. The “Multifactor authentication settings” disallow SMS or voice MFA but the “authentication methods policy” permits SMS or voice

It is worth noting that the “Password reset settings” in the self-service password reset (SSPR) service face similar risks when permitting weaker second factors; however, SSPR settings do not apply to Entra ID sign-ins (i.e. allowing mobile phone as an option for a password reset does not allow SMS or voice to be used for MFA). Additionally, for sake of conciseness, we will not be covering the challenges posed by AiTM attacks against M365 or available token protection features, which Microsoft already covers in depth here: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/token-protection-by-using-microsoft-entra-id-/4302207

Details

In this first scenario, we have configured the “authentication methods policy” to disallow SMS or voice to be used as a second factor for MFA.

Microsoft Entra ID > Authentication methods

However, we configured the legacy “Multifactor authentication settings” to allow call and text messages.

Microsoft Entra ID > Security > Manage > Multifactor authentication > Additional cloud-based multifactor authentication settings > Service settings

Per Microsoft, “Settings aren't synchronized between the policies, which allows administrators to manage each policy independently. Microsoft Entra ID respects the settings in all of the policies so a user who is enabled for an authentication method in any policy can register and use that method. To prevent users from using a method, it must be disabled in all policies.”

As such, I am able to register and use either SMS or voice as my second factor when signing into Azure.

Now, we can flip this around by enabling SMS and voice in the “authentication methods policy”.

Microsoft Entra ID > Authentication methods

And then can attempt to restrict SMS and voice options by only allowing “Verification code from mobile app or hardware token” in the legacy “Multifactor authentication settings”.

Microsoft Entra ID > Security > Manage > Multifactor authentication > Additional cloud-based multifactor authentication settings > Service settings

As expected, we still have the option to add and use SMS or voice as a second factor when signing in due to the “authentication method policies” settings. 

Conclusion and recommendations

Entra ID will seemingly err on the least restrictive setting regardless if it is set in the modern “authentication method policies” or the legacy “Multifactor authentication settings”. Although Microsoft plans to decommission the legacy MFA settings by September 30th, 2025, it is better to take steps now to mitigate the risk of more sophisticated threat actors abusing weaker second factors to bypass MFA.

Disclaimer: before disabling certain MFA methods across your Entra ID tenant, consider the potential impact of removing these options (i.e. managing users who cannot use Microsoft Authenticator), coordinate with the necessary technical teams to develop a phased transition strategy, and ensure you have emergency break glass accounts available in the event that Entra ID access is unwittingly lost.

The following steps can be taken to mitigate the risk of using weaker methods for MFA:

1. Migrate from the legacy MFA and SSPR policies to the current Entra ID authentication policies
This can be done from the Azure Portal or Microsoft Entra admin center by changing the migration status in the authentication policies settings.

Microsoft Entra ID > Authentication methods > Migration status

2. Align authentication methods policy and legacy MFA settings

Ensure “SMS” and “Voice call” are disabled in the Entra ID “authentication methods policy” and the legacy MFA settings (“Additional cloud-based multifactor authentication settings - Service settings”) should be set to only “Verification code from mobile app or hardware token; note that the “Email OTP” in the Entra ID “authentication methods policy” is only usable for SSPR by members of the tenant and can be configured to be used for sign-in by guest users.

3. Consider enforcing authentication strength via Conditional Access Policies

For more mature organizations that have the proper licensing, consider using Conditional Access Policies (CAPs) to only allow the use of phishing-resistant factors for MFA to relevant applications via the “Require authentication strength” option in the “Grant” section; note that this type of CAP should be rolled out in planned segments and could accidentally cut off access for users who do not have phishing-resistant authentication methods available.  It is best practice to exempt your emergency break glass accounts from CAPs to mitigate the risk of such lockouts.

Microsoft Entra ID > Conditional Access

Read More