How to Configure Microsoft Entra ID Authentication Strengths for Granular MFA Enforcement

For years, IT administrators treated Multi-Factor Authentication (MFA) as a binary switch. In Conditional Access, you simply checked the box for “Require multifactor authentication.” If the user provided a 6-digit SMS code, they were granted access. If they provided a hardware FIDO2 security key, they were granted access. To the system, both methods were viewed as mathematically equal.

This architecture is fundamentally broken in the modern threat landscape. SMS codes and Authenticator app push notifications are highly susceptible to MFA Fatigue attacks (MFA bombing) and adversary-in-the-middle (AiTM) phishing proxies (like Evilginx). A hardware FIDO2 key, however, is cryptographically bound to the origin domain, rendering it impervious to phishing.

Microsoft solved this discrepancy with Authentication Strengths. This feature allows architects to define granular hierarchies of MFA methods. You can now build a Conditional Access policy that says: “To access the generic HR portal, any MFA method is fine. But to access the Azure portal or the Global Administrator console, you must use a phishing-resistant method like a FIDO2 key.”

This guide explains how to configure and deploy Authentication Strengths in Microsoft Entra ID.

Step 1: Understanding the Built-in Strengths

Entra ID provides three default, built-in Authentication Strengths that cannot be modified. They are structured hierarchically:

1. Multifactor authentication (Lowest): Accepts almost everything, including SMS, Voice calls, OATH hardware tokens, and Microsoft Authenticator push notifications.
2. Passwordless MFA (Medium): Requires methods that do not use a password, such as Windows Hello for Business or Microsoft Authenticator (configured for phone sign-in).
3. Phishing-resistant MFA (Highest): Strictly limits authentication to FIDO2 security keys (like YubiKeys), Windows Hello for Business, or Certificate-Based Authentication (CBA).

Step 2: Creating a Custom Authentication Strength

While the built-in strengths are useful, most enterprises require custom configurations. For example, you may want to allow FIDO2 and Microsoft Authenticator, but explicitly ban SMS and Voice calls company-wide.

1. Navigate to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Protection > Authentication methods > Authentication strengths.
3. Click New authentication strength.
4. Name: Modern MFA (No Telephony).
5. In the method selector, check the boxes for FIDO2 security key, Windows Hello for Business, and Microsoft Authenticator (Push/Passwordless).
6. Ensure SMS and Voice are strictly unchecked.
7. Click Create.

Step 3: Enforcing Authentication Strength via Conditional Access

Authentication Strengths do absolutely nothing until they are enforced by a Conditional Access policy.

Let’s build a policy that forces highly privileged IT administrators to use Phishing-resistant MFA when accessing the Microsoft Azure Management portals.

1. Navigate to Protection > Conditional Access > Policies.
2. Click New policy.
3. Name: Require Phishing-Resistant MFA for Azure Admins.
4. Users: Select the specific group containing your Global Administrators, Privileged Role Administrators, and Azure Subscription owners.
5. Target resources: Click Select apps and search for Microsoft Azure Management.

Now, configure the critical enforcement control:

1. Under Access controls, click Grant.
2. Check the box for Require authentication strength.
3. From the dropdown menu, select the built-in Phishing-resistant MFA.
4. Click Select.
5. Set the policy to Report-only for testing, then switch to On when verified.
6. Click Create.

Step 4: The End-User Experience and Step-Up Authentication

When an IT administrator logs into their standard Office 365 email from a new laptop, they might be prompted for a standard Microsoft Authenticator push notification (based on your baseline policies).

However, the moment they navigate to portal.azure.com to modify a virtual machine, Entra ID evaluates the session token. It recognizes that the session was established using an Authenticator app, which does not meet the “Phishing-resistant” requirement for Azure Management.

The user is seamlessly interrupted with a Step-up Authentication prompt. Entra ID will say, “Your organization requires a stronger authentication method to access this resource.” The user is then forced to plug in their YubiKey and touch the biometric sensor. Once the FIDO2 cryptographic challenge is satisfied, they are granted access to Azure.

Conclusion

Relying on generic MFA policies is no longer sufficient to stop modern phishing campaigns. By deploying Entra ID Authentication Strengths, security architects can eliminate SMS and voice vulnerabilities, enforce cryptographic, phishing-resistant tokens for critical infrastructure access, and gracefully implement step-up authentication without disrupting standard daily workflows.