Adventure Works' security team wants to use Microsoft Entra ID Protection's sign-in risk signals to automate their response to risky sign-ins. Their policy is: sign-ins flagged as 'High' risk should be completely blocked, while sign-ins flagged as 'Medium' risk should be allowed if the user completes MFA. What is the correct way to implement this in Microsoft Entra?
Select an answer to reveal the explanation.
Short Explanation
Think of sign-in risk like a traffic light: High risk gets a red light (block completely), Medium risk gets a yellow light (prove it's really you with MFA). One policy can't do both jobs because you can't simultaneously block and grant access, so you need two separate Conditional Access policies, each targeting a different risk level.
Full Explanation
Microsoft Entra Conditional Access supports sign-in risk as a condition (available when Entra ID Protection / Microsoft Entra ID P2 licensing is present). One CA policy can target one or more specific risk levels. Because the desired outcome differs per risk level — Block for High, Grant+MFA for Medium — two separate policies are required. The High-risk policy sets Conditions > Sign-in risk = High and Access controls > Block access. The Medium-risk policy sets Conditions > Sign-in risk = Medium and Access controls > Grant access, Require multi-factor authentication. This is the Microsoft-recommended architecture for risk-based access control. The approach that creates a single Conditional Access policy targeting all sign-in risk levels (Low, Medium, High) with Block access is incorrect because it would also block Medium-risk users, denying them the option to self-remediate with MFA. This is overly restrictive and doesn't match the requirement to allow MFA for medium-risk sign-ins. The approach that configures the sign-in risk policy directly within Microsoft Entra ID Protection (under Security > Identity Protection > Sign-in risk policy) and sets it to block high-risk users only is incorrect because Microsoft Entra ID Protection does have its own built-in sign-in risk policy (legacy feature), but Microsoft now recommends managing risk responses through Conditional Access policies instead of the Identity Protection policy blade. More importantly, the legacy Identity Protection sign-in risk policy supports block or require MFA but cannot differentiate between High and Medium risk with different actions in the same policy. Using Conditional Access provides more control and is the current best practice. The approach that sets up Microsoft Sentinel with an analytics rule to detect high-risk sign-ins and trigger an automated playbook that blocks the user account in Microsoft Entra ID is incorrect because Microsoft Sentinel is a SIEM/SOAR platform used for broader threat detection, investigation, and response across the enterprise. While Sentinel can detect risky sign-ins and trigger playbooks, this approach is significantly more complex, introduces latency in the remediation loop, and is not the purpose-built solution for this scenario. Conditional Access provides real-time, inline enforcement at the authentication layer. Exam tip: Conditional Access sign-in risk conditions require Microsoft Entra ID P2 (or Microsoft 365 E5). Know that High risk = Block and Medium risk = MFA is the standard Microsoft recommended posture. Two separate policies for two different outcomes is the correct implementation pattern.