Module 4 of 6

🎯 Security Course · Module 4 of 6

Identity Protection & Risk-Based Conditional Access

📂 Course: M365 Security Administration
📦 Module: 4 of 6
🎯 Exam: SC-200
⏱ Read time: ~22 min

SC-200 Exam Alignment
SC-200

Mitigate threats using Microsoft Entra ID Protection: Understand risk detections, configure sign-in risk and user risk policies, build risk-based Conditional Access policies, and investigate and remediate risky users and risky sign-ins.

Sign-in risk = the probability that THIS specific sign-in attempt was not made by the legitimate account owner (e.g. sign-in from an anonymous IP, impossible travel)
User risk = the cumulative probability that THIS user account is compromised — accumulates over time from multiple risk events
Risk levels: Low, Medium, High — each Conditional Access policy can target one or more risk levels
Entra ID Protection requires Microsoft Entra ID P2 (or Microsoft 365 E5 / EMS E5) — P1 does not include risk-based Conditional Access

Exam Tip: SC-200 distinguishes between the remediation actions for user risk vs sign-in risk. For sign-in risk: the correct remediation is requiring MFA at sign-in (the user proves they are the legitimate owner). For user risk: the correct remediation is requiring a secure password change — because a compromised account must change its credentials to regain a clean risk state. Confirming compromise vs dismissing risk are admin actions — know the difference.

Microsoft Entra ID Protection uses machine learning and Microsoft’s global threat intelligence to detect suspicious sign-in patterns and compromised accounts in real time. When risk is detected, it can automatically enforce additional authentication requirements or block access — preventing attackers from accessing corporate resources even with stolen credentials.

🔍 Risk Detections

Entra ID Protection generates risk detections when suspicious activity is observed. Each detection contributes to the user’s risk level or sign-in risk score.

Risk Detection	Type	What It Detects	Risk Level
Anonymous IP address	Sign-in risk	Sign-in from a Tor exit node, VPN, or known anonymiser proxy	Medium
Impossible travel	Sign-in risk	Two sign-ins from geographically distant locations within a time period that would make travel physically impossible	Medium / High
Unfamiliar sign-in properties	Sign-in risk	Sign-in properties (location, device, browser) that deviate from the user’s historical pattern	Low / Medium
Malware-linked IP address	Sign-in risk	Sign-in from an IP address known to be associated with botnet activity	High
Leaked credentials	User risk	User’s credentials found in darkweb paste sites or breach databases correlated by Microsoft threat intelligence	High
Azure AD threat intelligence	User risk / Sign-in risk	Internal Microsoft threat intelligence flags known attack patterns specific to this user or sign-in	High
Password spray attack	User risk	Low-and-slow password guessing attack pattern detected across the tenant	High

📋 User Risk vs Sign-In Risk Policies

Entra ID Protection has two types of risk policies (configurable in the Entra ID Protection blade or as Conditional Access policies). Both can trigger access controls in real time.

	Sign-In Risk Policy	User Risk Policy
What triggers it	A specific sign-in attempt has elevated risk indicators (anonymous IP, impossible travel, etc.)	The cumulative risk level of the user account reaches the configured threshold
When evaluated	Real-time — at the moment of sign-in	Real-time at sign-in, or raised by detection of leaked credentials
Recommended response	Require MFA — if the user can pass MFA, the sign-in risk is dismissed automatically	Require secure password change (MFA + password reset) — this clears the accumulated user risk
Block access	Configure for High risk when MFA is not sufficient or for break-glass scenarios	Configure for High risk when account is very likely compromised
Requires	Entra ID P2	Entra ID P2

🔐 Risk-Based Conditional Access Policies

The modern approach is to configure risk responses as Conditional Access policies rather than using the legacy Identity Protection policy blade. Conditional Access gives more granularity over who the policy applies to and what the access control is.

Sign-In Risk Policy — Example Configuration

📋 CA Policy: Require MFA for Medium+ Sign-In Risk

Users	All users (exclude break-glass accounts)
Target resources	All cloud apps
Conditions → Sign-in risk	Medium and High
Grant	Require multifactor authentication
Session	Sign-in frequency: Every time (for High risk)

User Risk Policy — Example Configuration

📋 CA Policy: Require Password Change for High User Risk

Users	All users (exclude break-glass accounts)
Target resources	All cloud apps
Conditions → User risk	High
Grant	Require multifactor authentication AND Require password change

⚠️ Password Change Clears User Risk — MFA Alone Does Not

When user risk is High (e.g. leaked credentials detected), requiring MFA alone is not sufficient remediation. The attacker still has the password. The correct grant control is “Require password change” — this forces the user to change their password through the self-service password reset flow, which in turn clears the high user risk state. After a successful password change, the user risk is automatically dismissed by Entra ID Protection.

🔎 Risky Users Dashboard Investigation

Navigate to Entra ID → Security → Identity Protection → Risky users to see all users with elevated risk. From here, admins can investigate each user’s risk history and take remediation actions.

Admin Action	When to Use	Effect on Risk
Confirm user compromised	Investigation confirms the account was taken over by an attacker	Sets user risk to High; disables the account; admin must reset credentials and re-enable
Dismiss user risk	Investigation confirms the detections were false positives (e.g. VPN caused anonymous IP alert)	Clears the user risk back to None; does not affect future real detections
Block user	Immediate containment needed before investigation is complete	Blocks all sign-ins to the account immediately
Investigate with Defender portal	Correlate identity risk with device alerts and email activity	No direct risk change — opens the full investigation workflow in Microsoft 365 Defender

PowerShell — Identity Protection via Microsoft Graph

# Connect with Identity Protection read/write scopes
Connect-MgGraph -Scopes 'IdentityRiskyUser.ReadWrite.All','IdentityRiskEvent.Read.All'

# Get all High and Medium risk users
Get-MgRiskyUser -Filter "riskLevel eq 'high' or riskLevel eq 'medium'" | Select-Object UserDisplayName,UserPrincipalName,RiskLevel,RiskState,RiskLastUpdatedDateTime

# Get risk detection history for a specific user
Get-MgIdentityRiskDetection -Filter "userId eq '<UserId>'" | Select-Object DetectionTimingType,RiskDetail,RiskEventType,RiskLevel

# Confirm user as compromised (disables sign-in)
Confirm-MgRiskyUserCompromised -UserIds @('<UserId>')

# Dismiss risk for false positive
Invoke-MgDismissRiskyUser -UserIds @('<UserId>')

💡 Best Practices

Deploy the MFA registration policy first (Entra ID Protection → MFA registration policy) — risk-based Conditional Access is ineffective if users haven’t registered MFA yet and can’t complete the challenge
Always exclude break-glass emergency admin accounts from sign-in risk and user risk policies — otherwise a false positive during an incident could lock out your emergency access
Use Report-only mode first when deploying new risk-based Conditional Access policies — review the sign-in logs to understand impact before switching to Enforce mode
Review the Risky users dashboard weekly and investigate any High risk users within 24 hours — leaked credential detections indicate an active threat
Configure the risk-based user risk policy to require password change (not just MFA) for High user risk — this is the only way to automatically clear accumulated risk through self-service

🎓 Interview Q&A

Q: An Entra ID Protection alert shows a user account as High user risk due to “Leaked credentials” — the user’s email/password combination was found on a darkweb breach site. What is the correct immediate response and why?

Two parallel actions:

1. Force an immediate password reset — require the user to change their password via the user risk Conditional Access policy (Require password change grant) or manually trigger a password reset in the admin portal. This invalidates the stolen credential immediately.

2. Investigate active sessions — check the user’s recent sign-in logs (Entra ID → Sign-in logs, filter for this user) for any successful sign-ins from unfamiliar locations or IPs, particularly ones that preceded the detection. If suspicious sessions are found, revoke all active refresh tokens using Revoke-MgUserSignInSession.

A successful password change through the SSPR/password reset flow will automatically dismiss the user risk in Entra ID Protection. Simply dismissing the risk without forcing a password change is incorrect — the attacker still has usable credentials.

🎯 SC-200 Mock Test

Module 4 — Identity Protection & Risk-Based CA

5 questions · Scenario-based · Pass mark: 70%

Q1 of 5

A user’s account is flagged with High user risk due to leaked credentials. A Conditional Access policy grants “Require MFA” for High user risk. The user successfully completes MFA. What is the user risk state after this?

ARisk is automatically cleared to None — MFA proves the user is legitimate

BRisk is reduced from High to Medium — further activity will clear it

CRisk remains High — MFA alone does not remediate leaked credentials; the attacker still knows the password

DRisk is set to Dismissed — Identity Protection automatically dismisses after MFA success

✅ C. MFA alone does NOT clear user risk when the detection is “Leaked credentials.” The attacker still knows the password — completing MFA just proves the current sign-in is by someone who has the second factor. The user risk remains High until the user completes a password change (which invalidates the stolen credential). The correct grant for user risk policies should be “Require MFA AND Require password change.”

Q2 of 5

Which Entra ID licence tier is required to configure risk-based Conditional Access policies using sign-in risk and user risk conditions?

AMicrosoft Entra ID P2 (included in M365 E5, EMS E5, or Entra ID P2 standalone)

BMicrosoft Entra ID P1 — Conditional Access is a P1 feature and includes risk conditions

CMicrosoft 365 Business Premium — includes all Conditional Access features

DAny paid Microsoft 365 licence — Identity Protection is included in all plans

✅ A. Risk-based Conditional Access (using sign-in risk or user risk as conditions) requires Microsoft Entra ID P2. P1 includes Conditional Access but only allows conditions like MFA, device compliance, and location — not risk conditions. P2 adds the Entra ID Protection engine (risk detections, risky users dashboard, risk-based CA). M365 Business Premium includes P1 only; M365 E3 includes P1; M365 E5 and EMS E5 include P2.

Q3 of 5

A user is flagged as High user risk by Entra ID Protection. After investigation, you determine all the risky sign-ins were generated by a legitimate VPN service the user regularly uses and are false positives. What is the correct admin action?

AConfirm user compromised — this locks the account and forces a credential reset

BBlock the user — disable the account until the VPN is reconfigured

CAdd the VPN’s IP address to the Trusted Named Locations in Conditional Access to prevent future false positives, then wait for risk to age out

DDismiss the user risk — clears the accumulated risk without affecting the account; then add the VPN IP to Named Locations to prevent recurrence

✅ D. “Dismiss user risk” is the correct action for confirmed false positives — it clears the risk state to None without disabling or affecting the user’s account. Then, add the VPN’s known IP range to Named Locations as a trusted location in Conditional Access so future sign-ins from that IP are not flagged as “anonymous IP” or “unfamiliar sign-in properties.” This is the complete remediation: clear the false positive AND prevent recurrence.

Q4 of 5

What risk detection is triggered when Entra ID Protection detects two sign-ins from geographically distant locations in a time window that makes physical travel between them impossible?

AAnonymous IP address — sign-in is masked by an anonymising proxy service

BImpossible travel — two sign-ins in distant locations within a timeframe that makes physical travel impossible

CUnfamiliar sign-in properties — sign-in location deviates from user’s historical pattern

DLeaked credentials — user credentials found in a breach database

✅ B. Impossible travel. This detection fires when Entra ID Protection detects two successful sign-ins from geographically distant locations — e.g. London and Tokyo — within a time window that makes physical travel between them impossible (e.g. 2 hours). This is a strong indicator of credential theft where an attacker in one location used stolen credentials while the legitimate user also signed in from their normal location.

Q5 of 5

You are creating a risk-based Conditional Access policy targeting High sign-in risk. Which grant control provides the correct remediation that also allows Entra ID Protection to automatically dismiss the sign-in risk if successful?

ARequire compliant device

BBlock access — High sign-in risk should always be blocked, not challenged

CRequire password change

DRequire multifactor authentication — if the user passes MFA, the sign-in risk is automatically dismissed for that session

✅ D. For sign-in risk, requiring MFA is the correct grant. When a user with a risky sign-in successfully completes MFA, Entra ID Protection automatically dismisses the sign-in risk for that session — the MFA success proves the legitimate user is present. This is distinct from user risk, where a password change is required to clear the accumulated risk. Block access is appropriate only when you want zero tolerance for High sign-in risk and accept that legitimate users with false positives will be completely locked out.