MFA Not Required for Risky Sign-ins

Multi-Factor Authentication (MFA), formerly known as Two-Factor Authentication (2FA), offers robust protection for accounts against the vulnerabilities associated with weak or compromised passwords. Adhering to best practices and industry standards, it is advisable to block the authentication or ask for MFA when a user sign-in seems risky according to Microsoft Entra ID Protection criteria.

When an attacker obtains a user password through any means, MFA blocks the authentication by requesting an additional factor such as a time-expiring code from a mobile application, a physical token, a biometric feature, etc.

Microsoft Entra ID Protection, a feature requiring Microsoft Entra ID P2 licenses, identifies risky sign-ins within Entra ID. A sign-in risk represents the probability that a given authentication request isn't the authorized identity owner, based on a list of detections. Sign-in risk detection spans 3 levels:

• High
• Medium
• Low

Using this sign-in risk level can trigger Multi-Factor Authentication (MFA) through two protective features: Conditional Access Policies and Microsoft Entra ID Protection. Tenable recommends configuring it via a Conditional Access policy (CAP) due to its added benefits, including enhanced diagnostic data, seamless integration with report-only mode, Graph API support, and the ability to incorporate additional Conditional Access attributes, such as sign-in frequency, within the policy. Legacy risk policies configured in Microsoft Entra ID Protection will retire on October 1, 2026, and must migrate to Conditional Access Policies. Therefore, this IoE only checks for Conditional Access Policies.

Based on this recommendation, the IoE ensures there is at least one (or two separate) Conditional Access policies with the following settings:

• "Users" set to include "All users".
• "Target resources" set to "All resources".
• "Conditions > Client apps" set to "No" ("Not configured"). Alternatively, set to "Yes" with all these four options selected: "Browser", "Mobile apps and desktop clients", "Exchange ActiveSync clients", and "Other clients".
• "Conditions > Sign-in risk" set to "Yes", selecting both "High" and "Medium" risk levels. Alternatively, configure two separate policies—one targeting "High" risk and the other targeting "Medium" risk—to achieve the same effect.
• "Grant" set to "Require multifactor authentication" or to "Require authentication strength" with one of the following values: "Multifactor authentication", "Passwordless MFA", or "Phishing-resistant MFA".
• "Session -> Sign-in frequency" set to "Every time".
• Lastly, set "Enable policy" to "On" (not "Off" or "Report-only").

An enabled Conditional Access Policy (CAP) must exist for the tenant, covering all users and requesting MFA in risky sign-in situations.

To do so, you can create a CAP in the following ways:

• Configuring this condition in an existing CAP by using "Conditions > Sign-in risk" as outlined in this Microsoft guide and applying the settings specified in this Indicator of Exposure's description.
• Creating a fresh CAP and configuring it as specified in the IoE's description.
• Creating a new dedicated CAP using the "Require multifactor authentication for risky sign-ins" template from Microsoft. This template meets all the criteria that this Indicator of Exposure requires.

Note: When the sign-in risk Conditional Access policy is enabled, it automatically blocks risky authentications for users who have not yet registered for Microsoft Entra multifactor authentication (MFA), without offering MFA registration at that moment. To prevent blocking users, ensure they complete MFA registration in advance. Also, refer to the related IoEs "Missing MFA for Non-Privileged Account" and "Missing MFA for Privileged Account".

Even though you can directly configure the sign-in risk policy in Microsoft Entra ID Protection, Microsoft considers this feature legacy and plans to retire it on October 1, 2026. Microsoft is already urging administrators to migrate risk policies to Conditional Access. Therefore, Tenable does not recommend using legacy risk policies in Microsoft Entra ID Protection, and this IoE ignores it.

Note: Both Microsoft and Tenable recommend that you exclude certain accounts from Conditional Access policies to prevent tenant-wide account lockout and undesired side effects. Tenable also recommends that you follow the Microsoft documentation "Plan a Conditional Access deployment" to ensure proper planning and change management, as well as mitigate the risk of locking yourself out.

Name: MFA Not Required for Risky Sign-ins

Codename: MFA-NOT-REQUIRED-FOR-RISKY-SIGN-INS

Severity: High

Type: Microsoft Entra ID Indicator of Exposure