This chapter covers user risk investigation in Entra ID Protection, a core component of Microsoft's identity security. You will learn how to interpret risk detections, investigate user risk levels, and remediate compromised accounts. This topic is critical for the SC-200 exam, where approximately 10-15% of questions relate to identity protection and risk management. Mastery of user risk investigation is essential for security operations analysts who must quickly identify and respond to identity-based threats.
Jump to a section
Think of Entra ID Protection as a credit bureau that continuously monitors every user's financial behavior. Just as a credit score is calculated from payment history, credit utilization, and recent inquiries, Entra ID Protection calculates a user risk score from signals like impossible travel, leaked credentials, and anomalous sign-ins. When a credit bureau sees a sudden spike in credit card applications from a new address, it flags potential identity theft. Similarly, when Entra ID Protection detects a sign-in from a new location using a Tor browser, it increases the user's risk score. Like a credit freeze, you can block high-risk actions entirely or require additional verification (like a phone call to confirm a large purchase). The risk score decays over time if no new suspicious activity occurs, just as a credit score improves with consistent on-time payments. Administrators can review the risk history and manually dismiss false positives, akin to disputing a credit report error. The key difference is speed: while credit scores update monthly, Entra ID Protection updates risk in near real-time, allowing immediate response to threats.
What is Entra ID Protection User Risk?
Entra ID Protection (formerly Azure AD Identity Protection) is a feature of Microsoft Entra ID Premium P2 that detects and responds to identity-based risks. User risk represents the probability that a user's identity has been compromised. It is calculated using machine learning models that analyze sign-in patterns and user behavior. The risk is expressed as a level: Low, Medium, High, or None. The risk level is dynamic and changes as new signals arrive.
How User Risk is Calculated
User risk is computed by aggregating risk detections associated with a user over time. Each risk detection has a type (e.g., leaked credentials, impossible travel) and a confidence level (Low, Medium, High). The user risk level is derived from the number and severity of these detections. For example, a single high-confidence detection of leaked credentials may result in a High user risk. Multiple low-confidence detections might raise the risk to Medium. The exact algorithm is proprietary, but the exam focuses on how to interpret and respond to the risk level.
Key Components and Default Values
Risk Detection Types: The exam covers: Leaked Credentials, Impossible Travel, Anonymous IP Address, Malware Linked IP Address, Unfamiliar Sign-in Properties, Malicious IP Address, Suspicious Browser, Token Issuer Anomaly, and others. Each has a default risk level (e.g., Leaked Credentials is High).
Risk Levels: Low, Medium, High. None means no risk detected.
Risk History: Retained for 90 days for users with a free Azure AD license, but for Premium P2, risk data is stored for up to 30 days for user risk and 90 days for sign-in risk. However, the exam states that user risk data is retained for 30 days in Premium P2.
User Risk Policy: Configured in the Azure portal under Security > Identity Protection > User risk policy. You can set conditions (e.g., User risk level equals High) and controls (e.g., Block access, Allow but require MFA).
Remediation: Automatic remediation can be configured to require password change or MFA when risk is detected.
How User Risk Interacts with Sign-in Risk
Sign-in risk is calculated per sign-in attempt, while user risk is cumulative. A single risky sign-in may increase user risk if the detection type is severe. For example, a sign-in from an anonymous IP might increase sign-in risk but not necessarily user risk unless it happens repeatedly. The exam tests your ability to differentiate between the two and recommend appropriate actions.
Investigating User Risk
To investigate user risk, you use the Microsoft Entra admin center:
Navigate to Security > Identity Protection > Risky users.
Review the risk level, risk detections, and risk history.
Click on a user to see detailed risk events.
Use the 'Risk detections' tab to see each detection with its type, time, location, and risk level.
The 'Remediation' tab shows actions taken (e.g., password reset, MFA).
You can also use Microsoft Graph API to retrieve risk data programmatically:
GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsersRemediation Options
Manual remediation: Dismiss user risk (if false positive), Reset password, Revoke sessions.
Automatic remediation: Configure user risk policy to require password change or MFA.
Block access: Temporarily block the user until investigation is complete.
Typical Workflow for Security Operations
Alert received (e.g., from Microsoft Defender for Cloud Apps or Sentinel).
Open Identity Protection and identify the user with high risk.
Review risk detections to understand the cause.
Determine if the activity is legitimate (e.g., user traveling) or malicious.
If malicious, reset password and revoke sessions. If false positive, dismiss risk.
Optionally, add user to a custom blocklist or require MFA for future sign-ins.
Common Misconfigurations
Overly strict policies: Blocking all users with medium risk may cause false positives and lock out legitimate users.
Not enabling risk policies: Without a user risk policy, alerts are generated but no automatic remediation occurs.
Ignoring sign-in risk: User risk alone may miss attacks that only affect sign-in risk (e.g., password spray).
Integration with Microsoft Defender XDR
User risk data is ingested into Microsoft 365 Defender (Defender XDR) and can be correlated with other signals like alerts from Defender for Endpoint. For example, a user with high risk who also has a device detected with malware may indicate a broader compromise. The unified incident view in Defender XDR combines user risk with other alerts to provide a single investigation experience.
Exam Focus: Key Numbers and Terms
Risk detection types: Know the names and default risk levels.
Retention periods: User risk data retained for 30 days (Premium P2).
Risk levels: Low, Medium, High, None.
Policies: User risk policy and sign-in risk policy.
Remediation actions: Password reset, MFA, block access, dismiss risk.
Licensing: Entra ID Premium P2 required for Identity Protection.
Graph API endpoints: /identityProtection/riskyUsers and /identityProtection/riskDetections.
Step-by-Step Investigation Example
Suppose you receive an alert that a user's credentials were leaked. You navigate to Identity Protection and see the user's risk level is High. Under risk detections, you see a single detection of type 'Leaked Credentials' with high confidence. You click on the detection to see details: the leak was discovered on the dark web by Microsoft's threat intelligence. You decide to reset the user's password and revoke sessions. After remediation, the user risk level may drop to Medium or Low, but it may take up to 24 hours to update. You also configure an automatic policy to require password change for future high-risk users.
Access Identity Protection Dashboard
Navigate to the Microsoft Entra admin center (https://entra.microsoft.com). Under Security, select Identity Protection. The Risky users report shows all users with detected risk. The dashboard displays the number of users at each risk level (High, Medium, Low). You can filter by date range and risk level. This is the starting point for any user risk investigation.
Identify High-Risk Users
Click on the Risky users tab. Review the list sorted by risk level. Users with High risk should be prioritized. Note the 'Risk last updated' timestamp to see how recent the detection is. You can also export the list to CSV for offline analysis. The risk level is based on the most recent risk detection and the cumulative history.
Examine Risk Detections for a User
Click on a specific user to open their risk details. The 'Risk detections' tab lists each detection with type, date, location, IP address, and risk level. For example, a detection of type 'Impossible travel' will show the origin and destination locations and the time difference. This helps you understand the nature of the risk.
Correlate with Sign-in Logs
Use the 'Sign-ins' tab or Azure AD sign-in logs to see the actual sign-in attempts associated with the risk detections. Look for failed sign-ins, unusual IPs, or browser details. Cross-referencing helps confirm if the user was actually compromised or if it's a false positive (e.g., user traveling).
Take Remediation Action
Based on your investigation, choose a remediation action. Options include: reset password (which revokes sessions and tokens), require MFA, block sign-in, or dismiss user risk (if false positive). Use the 'Confirm user compromised' or 'Dismiss user risk' buttons to record your decision. For automatic remediation, configure a user risk policy.
Monitor After Remediation
After remediation, monitor the user's risk level for the next 24-48 hours. Check the 'Risk history' to see if new detections occur. If the risk level remains high, additional investigation may be needed. Also check if the user is able to sign in successfully after password reset.
Enterprise Scenario 1: Large Financial Institution
A bank with 50,000 employees uses Entra ID Protection to monitor for compromised accounts. They configured a user risk policy to require MFA for medium risk and block access for high risk. One day, they detected a user with high risk due to leaked credentials. The security team investigated and found that the user's password was exposed in a third-party data breach. They forced a password reset and revoked all sessions. The user was able to sign in with the new password and MFA. The risk level dropped to Low within an hour. The bank also integrated Identity Protection with Microsoft Sentinel to trigger automated playbooks (e.g., create a ticket, send email to manager). They experienced a 30% reduction in account compromises after implementing automatic remediation.
Enterprise Scenario 2: Global Technology Company
A tech company with 100,000 users had a user risk policy that blocked access for high risk. However, they received many false positives due to employees traveling internationally. The security team realized that the 'Impossible travel' detection was triggered when an employee logged in from the US and then from Asia within a short time, but the employee was using a VPN. They adjusted the policy to exclude known VPN IP ranges and added a custom risk detection rule to ignore trusted locations. They also implemented a user risk policy that only required MFA for medium risk, not block. This reduced false positives by 80%. They used the Graph API to export risk data daily for compliance reporting.
Common Pitfalls
Not excluding trusted IPs: Many organizations forget to add corporate VPN or office IP ranges to the named locations, causing false positive impossible travel detections.
Overlooking sign-in risk: Some admins only focus on user risk and miss sign-in risk anomalies like password spray attacks that don't raise user risk.
Delayed remediation: Waiting too long to act on high-risk users can lead to data breaches. Automatic remediation policies are critical.
Misunderstanding retention: Risk data is not retained indefinitely; after 30 days, old detections are purged. So historical analysis may be limited.
What the SC-200 Exam Tests
Objective 1.4: Investigate user risk in Entra ID Protection. The exam expects you to:
Interpret user risk levels (Low, Medium, High, None).
Identify risk detection types and their default severity.
Navigate the Identity Protection interface to find risky users and detections.
Choose appropriate remediation actions (password reset, MFA, block, dismiss).
Understand the difference between user risk and sign-in risk.
Know retention periods (30 days for user risk in Premium P2).
Configure user risk policies.
Common Wrong Answers and Why
'Reset password is the only remediation for high risk.' Wrong because you can also block access or require MFA. The exam often includes a scenario where MFA is sufficient.
'User risk is calculated per sign-in.' Wrong; sign-in risk is per sign-in, user risk is cumulative. Many candidates confuse the two.
'Risk data is retained for 90 days for all users.' Wrong; 90 days is for Azure AD Free, but for Premium P2, user risk is 30 days. The exam tests this distinction.
'Impossible travel always indicates compromise.' Wrong; it can be a false positive if the user uses a VPN or shares a device. The exam expects you to verify before acting.
Specific Numbers and Terms on the Exam
Risk detection types: Leaked Credentials (High), Impossible Travel (Medium), Anonymous IP (Medium), Malware Linked IP (Medium), Unfamiliar Sign-in Properties (Medium), Malicious IP (High).
Risk levels: Low, Medium, High, None.
Retention: User risk data retained for 30 days (Premium P2).
Policy actions: Block access, Allow but require MFA, Allow but require password change.
Graph API: /identityProtection/riskyUsers and /identityProtection/riskDetections.
Licensing: Microsoft Entra ID Premium P2.
Edge Cases
What if a user has no risk but sign-in risk is high? The user risk policy won't trigger; you need a sign-in risk policy.
Can you dismiss risk for a user that is already remediated? Yes, but it's not necessary; risk will decay over time.
What if a user's risk is medium but you want to block? You can configure a custom policy, but the default is to require MFA.
How to Eliminate Wrong Answers
If the question asks about 'user risk', eliminate answers about sign-in risk policies.
If the question mentions 'leaked credentials', the correct action is password reset (not just MFA).
If the question asks about 'retention', look for 30 days (Premium P2).
If the question involves 'impossible travel' and the user has a VPN, the answer should be to dismiss risk or add trusted IP.
User risk is cumulative; sign-in risk is per sign-in.
Risk levels: Low, Medium, High, None.
User risk data retained for 30 days (Premium P2).
Leaked credentials detection requires password reset.
Impossible travel can be false positive with VPN.
User risk policy can block or require MFA/password change.
Use Graph API: /identityProtection/riskyUsers.
Licensing: Microsoft Entra ID Premium P2 required.
These come up on the exam all the time. Here's how to tell them apart.
User Risk
Cumulative over time; reflects overall identity compromise likelihood.
Triggers user risk policy (e.g., block access, require password change).
Retained for 30 days with Premium P2.
Detections include leaked credentials, impossible travel (but aggregated).
Remediation often requires password reset or MFA.
Sign-in Risk
Per sign-in attempt; reflects likelihood that a specific sign-in is malicious.
Triggers sign-in risk policy (e.g., require MFA, block access).
Retained for 90 days.
Detections include anonymous IP, unfamiliar location, etc.
Remediation is often real-time MFA or block.
Mistake
User risk and sign-in risk are the same thing.
Correct
User risk is cumulative over time and reflects the likelihood that the user's identity is compromised. Sign-in risk is per sign-in attempt and reflects the likelihood that a specific sign-in is malicious. They are calculated separately and have different policies.
Mistake
You need Microsoft Entra ID Premium P1 for Identity Protection.
Correct
Identity Protection requires Microsoft Entra ID Premium P2. P1 provides conditional access but not risk detection and remediation features.
Mistake
Risk data is retained for 90 days for all users.
Correct
For Premium P2, user risk data is retained for 30 days. Sign-in risk data is retained for 90 days. Free and P1 users have limited or no risk data retention.
Mistake
Impossible travel detection always means the user is compromised.
Correct
Impossible travel can be a false positive if the user is using a VPN, sharing a device, or if there is a time zone misconfiguration. Always verify before taking action.
Mistake
Dismissing user risk removes all risk detections permanently.
Correct
Dismissing user risk only sets the risk level to None for that user. Risk detections are still visible in the risk history for 30 days. If new risky activity occurs, the risk level will increase again.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Navigate to the Microsoft Entra admin center > Security > Identity Protection > Risky users. Click on the user to see risk detections. Review each detection's type, location, and time. Correlate with sign-in logs to determine if the activity is legitimate. If compromised, reset password and revoke sessions. If false positive, dismiss user risk.
User risk is a cumulative score based on all risk detections associated with a user over time. Sign-in risk is calculated for each individual sign-in attempt. User risk policies apply to the user regardless of sign-in, while sign-in risk policies apply to specific sign-ins. Both are part of Identity Protection.
For Microsoft Entra ID Premium P2, user risk data is retained for 30 days. For sign-in risk, it's 90 days. Free and P1 users have limited retention. The exam tests the 30-day retention for user risk.
You can manually reset password (which revokes sessions), require MFA, block sign-in, or dismiss user risk. Automatic policies can enforce password change or MFA when risk level reaches a threshold. The exam expects you to choose password reset for leaked credentials.
Yes. Use the endpoint GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers to list risky users. You can also get risk detections with /riskDetections. This is useful for automation and integration with SIEM.
Microsoft Entra ID Premium P2 is required for full Identity Protection features, including risk detection and remediation policies. Azure AD Premium P1 provides conditional access but not risk-based policies.
In the Azure portal, go to Security > Identity Protection > User risk policy. Set conditions (e.g., user risk level equals High) and choose controls (e.g., Block access, Allow but require MFA or password change). Enable the policy and assign users/groups.
You've just covered User Risk Investigation in Entra ID Protection — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?