This chapter covers Entra ID Protection and risk policies, a core component of identity security in Microsoft 365. For the MS-102 exam, this topic appears in approximately 10-15% of questions, focusing on how to configure and manage risk detection, risk-based Conditional Access policies, and user remediation. Understanding the mechanics of risk scores, detection types, and policy integration is critical for passing the Identity Access domain (Objective 2.3).
Jump to a section
Think of Entra ID Protection as a bank's security system. The bank has a list of known customers (users) and their usual behaviors (sign-in patterns). A security guard (Conditional Access) checks IDs at the door. Entra ID Protection is the bank's fraud detection center. It monitors every transaction (sign-in) and looks for anomalies: a customer who always uses the downtown branch suddenly swiping a card in a foreign country at 3 AM, or someone trying to withdraw cash while wearing a ski mask (impossible travel, anonymous IP, or leaked credentials). When a risky transaction is detected, the system calculates a risk score (low/medium/high) and triggers an alarm. The alarm can be configured to either just log the event, require additional verification (like a phone call to confirm), or automatically lock the account (block sign-in). The bank also has a 'risk-based policy' that says: if a transaction is high-risk, require manager approval before proceeding. In Entra ID, this is a Conditional Access policy that uses the risk level as a condition. The system also learns over time: if a customer's behavior changes (e.g., they move to a new city), the system adapts and stops flagging the new location as risky after a few legitimate logins (risk feedback and user risk remediation).
What is Entra ID Protection?
Entra ID Protection (formerly Azure AD Identity Protection) is a cloud-based service that detects and responds to identity-based risks. It analyzes billions of sign-in signals daily using Microsoft's security graph and machine learning models. The service provides a unified view of risky users and risky sign-ins, and allows administrators to configure policies that automatically remediate or block access based on risk levels. It is a premium feature requiring Azure AD Premium P2 licenses for full functionality (risk-based Conditional Access policies). Without P2, you can view reports but cannot enforce risk-based policies.
How It Works Internally — Detection Mechanism
Entra ID Protection collects signals from multiple sources: - Azure AD sign-in logs: IP addresses, device fingerprints, browser strings, timestamps. - Microsoft Defender for Cloud Apps: Behavioral analytics, impossible travel, anomalous file access. - Microsoft 365 Defender: Threat intelligence feeds, leaked credentials databases. - Azure AD Identity Protection itself: Machine learning models that generate risk scores.
Each sign-in attempt is evaluated in real-time (or near-real-time for offline detections). The system computes two types of risk: - User risk: The probability that a user's identity has been compromised. Based on events like leaked credentials, suspicious password changes, or anomalous activity over time. - Sign-in risk: The probability that a specific sign-in attempt is unauthorized. Based on characteristics like anonymous IP, atypical travel, malware-linked IP, or unfamiliar sign-in properties.
Risk levels are categorized as Low, Medium, High, or None. The thresholds are internal Microsoft algorithms, but administrators can influence them via risk detection configuration (e.g., marking a detection as safe or confirming compromise).
Key Components and Defaults
- Risk Detections: There are over 30 detection types, but the exam focuses on these: - Leaked Credentials: Microsoft compares hashed passwords against known leaked databases from the dark web. This is a high-fidelity detection. - Impossible Travel: Two sign-ins from geographically distant locations within a time window shorter than the travel time. Requires at least 10 minutes between sign-ins and a distance > 500 km. - Anonymous IP Address: Sign-in from an IP address known as an anonymous proxy or Tor exit node. - Atypical Travel: Similar to impossible travel but uses machine learning to detect patterns that are unusual for the user. - Malware Linked IP Address: IP address known to be associated with botnets or malware command-and-control servers. - Unfamiliar Sign-in Properties: Sign-in with properties (IP, device, location) not seen before for that user. - Admin Confirmed User Compromised: An admin manually marks a user as compromised. - Password Spray: Multiple accounts targeted with a few common passwords from a single IP.
Risk Levels and Scoring: Each detection has an inherent risk level (Low, Medium, High) that contributes to the overall sign-in risk. The user risk is an aggregate of all risk detections over time. There is no public formula, but detections like Leaked Credentials always result in High user risk.
- Policies: Two built-in risk policies can be enabled: - User Risk Policy: Conditionally requires multi-factor authentication (MFA) or blocks access based on user risk level. - Sign-In Risk Policy: Conditionally requires MFA or blocks access based on sign-in risk level. These are Conditional Access policies that appear in the Azure AD Conditional Access blade once enabled. They use the risk level as a condition (e.g., 'High' or 'Medium and above').
- Timers: - User risk expires after 30 days if no new detections occur and the user has not been remediated. - Sign-in risk is tied to a specific sign-in event and does not expire; it is evaluated at sign-in time. - Remediation actions: If a user is blocked by a risk policy, they can self-remediate by completing MFA or changing their password (if configured). The admin can also dismiss risk manually.
Configuration and Verification Commands
Policies are configured in the Azure portal under Azure Active Directory > Security > Identity Protection. You can also use Microsoft Graph PowerShell or Microsoft Graph API.
Example PowerShell cmdlets (requires AzureADPreview module):
# Get current user risk policy
Get-AzureADIdentityProtectionPolicyUserRisk
# Update user risk policy to require MFA for medium risk and above
Set-AzureADIdentityProtectionPolicyUserRisk -PolicyState Enabled -RiskLevelForMFA Medium,High -RiskLevelForBlock High
# Get sign-in risk policy
Get-AzureADIdentityProtectionPolicySignInRisk
# Update sign-in risk policy
Set-AzureADIdentityProtectionPolicySignInRisk -PolicyState Enabled -RiskLevelForMFA Medium,High -RiskLevelForBlock HighTo view risk detections:
# Get risky users
Get-AzureADRiskyUser
# Get risk history for a user
Get-AzureADRiskyUser -Id "user@domain.com" | Get-AzureADRiskyUserHistory
# Confirm user as compromised (adds to user risk)
Set-AzureADUser -ObjectId "user@domain.com" -RiskLevel HighIn the Graph API:
GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers
GET https://graph.microsoft.com/v1.0/identityProtection/riskDetectionsHow It Interacts with Related Technologies
Conditional Access: Risk policies are a type of Conditional Access policy. They only work if Conditional Access is enabled for the tenant. The risk condition can be used alongside other conditions (e.g., location, device) in custom policies.
MFA Registration: Users must be registered for MFA before risk policies can require MFA. The Combined Registration page allows users to register for both MFA and SSPR.
Identity Governance: User risk can trigger access reviews or automatic remediation workflows via Azure AD Identity Governance.
Microsoft Defender for Cloud Apps: Provides additional risk signals like impossible travel and anomalous file access, which feed into Identity Protection.
Microsoft 365 Defender: Leaked credentials detection comes from threat intelligence shared across the Defender suite.
Risk Remediation and User Experience
When a user triggers a high-risk sign-in and the policy is set to require MFA, they must complete MFA successfully to proceed. If the policy is set to block, they receive a generic 'access denied' message. Users can self-remediate by completing MFA or changing their password if the administrator has enabled self-remediation. The admin can also manually dismiss risk by clicking 'Dismiss user risk' or 'Confirm user compromised' in the portal. Confirming compromise adds to the risk; dismissing reduces it. After remediation, the user risk is recalculated and may decrease over time if no new detections occur.
Important Exam Numbers and Defaults
License requirement: Azure AD Premium P2 for risk-based policies.
Risk levels: None, Low, Medium, High.
Default risk policy states: Disabled (must be enabled manually).
User risk expires after 30 days.
Impossible travel detection: minimum 10 minutes between sign-ins, distance > 500 km.
Leaked credentials: always high risk.
Self-remediation options: MFA or password change.
Maximum number of risk detections stored per user: 90 days.
Common Misconfigurations
Enabling risk policies without MFA registration: Users will be blocked if they cannot complete MFA. Always ensure users are registered for MFA first.
Setting risk policies to 'Block' for high risk without a fallback: This can lock out legitimate users. Use 'Require MFA' instead for high risk, and 'Block' only for extreme cases.
Not excluding break-glass accounts: Always exclude emergency access accounts from risk policies to avoid lockout.
Relying solely on built-in policies without custom Conditional Access: The built-in policies are a good start, but custom policies allow more granularity (e.g., requiring MFA only for medium risk but blocking for high risk from non-corporate networks).
Enable Identity Protection in Tenant
Navigate to Azure Active Directory > Security > Identity Protection. Click 'Enable' for both user risk and sign-in risk policies. This activates the service and starts collecting risk signals. The default state is 'Disabled'. You must have Azure AD Premium P2 licenses assigned to users who will be evaluated. The service will then begin processing sign-in logs and threat intelligence feeds to generate risk detections.
Configure Risk Policies
In the Identity Protection blade, click 'User risk policy' or 'Sign-in risk policy'. Set the policy state to 'Enabled'. Choose the risk level that triggers the policy (Low, Medium, High). Then select the action: 'Allow access' (no action), 'Allow access but require MFA', or 'Block access'. For exam purposes, remember that 'Require MFA' is the recommended action for medium and high risk. Click 'Save'. The policy is now a Conditional Access policy that will be evaluated at sign-in.
Exclude Break-Glass Accounts
In the policy configuration, under 'Exclude', add the emergency access accounts (break-glass accounts) that should never be blocked. These are typically two cloud-only global administrator accounts with long passwords and no MFA registration, used only for break-glass scenarios. Excluding them ensures you can always access the tenant even if policies misbehave. Also exclude service accounts that cannot perform MFA.
Test with a Pilot Group
Before rolling out to all users, assign the policy to a test group. Use a group of IT administrators or pilot users. Sign in with a test account from a known risky IP (e.g., Tor browser) to verify that the policy triggers correctly. Check the 'Risky sign-ins' report to see the detection. Confirm that MFA is prompted or access is blocked as configured. Adjust risk levels if necessary.
Monitor and Remediate Risks
Regularly review the 'Risky users' and 'Risk detections' reports in Identity Protection. For each detected risk, decide whether to confirm compromise (if you believe the user is indeed compromised) or dismiss risk (if it's a false positive). You can also trigger automatic remediation via Conditional Access policies (e.g., require password change). Use the 'User risk policy' to force users to change their password when user risk is high. This can be done by setting the policy action to 'Require password change' (available in the policy).
Enterprise Scenario 1: Global Company with Remote Workforce
A multinational corporation with 50,000 users deploys Entra ID Protection to combat credential theft. They enable both user risk and sign-in risk policies. For sign-in risk, they set medium and high to require MFA. For user risk, high risk triggers a password change. They exclude break-glass accounts and a pilot group of 500 IT staff. After one week, they detect 200 risky sign-ins, mostly from anonymous IPs (Tor) and impossible travel. 10 users are flagged as high user risk due to leaked credentials. The helpdesk receives calls from users who cannot sign in because they are blocked by the sign-in risk policy. The team realizes they need to educate users about MFA registration and ensure all users are registered. They also adjust the policy to allow low risk without action, reducing user friction. The system learns over time: after three months, false positives from unfamiliar locations drop as users' patterns are established.
Enterprise Scenario 2: Financial Institution with Strict Compliance
A bank uses Identity Protection to meet regulatory requirements for multi-factor authentication on all high-risk sign-ins. They configure custom Conditional Access policies that combine risk level with location: for high-risk sign-ins from outside the corporate network, block access entirely. For medium risk, require MFA. They also integrate with Microsoft Defender for Cloud Apps to detect anomalous file downloads. A user's account is compromised; the attacker uses a VPN from a new location. The sign-in risk is medium (unfamiliar properties) and MFA is prompted. The attacker cannot complete MFA, so the sign-in fails. The user risk later becomes high when leaked credentials are detected. The user is forced to change password at next sign-in. The bank avoids a data breach.
Common Pitfalls in Production
Overblocking: Setting policies too aggressively (e.g., blocking all medium risk) can lock out legitimate users, especially those traveling. Use 'Require MFA' instead of 'Block' for medium risk.
Underblocking: Not enabling policies at all leaves the tenant vulnerable. Many organizations only enable after an incident.
Ignoring user risk: Some admins focus only on sign-in risk, but user risk is equally important for detecting compromised accounts that may have been used for a while.
Not using self-remediation: Without self-remediation, users must contact helpdesk to unblock, increasing support costs. Enable password change and MFA self-service.
What MS-102 Tests on This Topic
Objective 2.3 covers 'Implement and manage identity protection and risk policies'. The exam expects you to:
Configure user risk and sign-in risk policies.
Understand the difference between user risk and sign-in risk.
Know the licensing requirements (Azure AD Premium P2).
Identify common risk detection types (especially leaked credentials, impossible travel, anonymous IP, unfamiliar sign-in properties).
Explain the remediation options (MFA, password change, block, dismiss).
Know the default risk levels and how they map to actions.
Understand the interaction with Conditional Access.
Common Wrong Answers and Why
'Risk policies require Azure AD Premium P1' – Wrong. P1 allows Conditional Access but not risk-based policies. P2 is required for Identity Protection risk policies.
'User risk and sign-in risk are the same' – Wrong. User risk is an aggregate over time; sign-in risk is per-event. The exam tests this distinction.
'Blocking high-risk sign-ins is always the best action' – Wrong. The recommended action is to require MFA, not block, because high risk can be false positive. Blocking should be reserved for extreme cases.
'Risk policies are enabled by default' – Wrong. They are disabled by default.
'Impossible travel detection requires a minimum of 1 hour between sign-ins' – Wrong. The actual minimum is 10 minutes.
Specific Numbers and Terms That Appear Verbatim
'Leaked Credentials' is always high risk.
'Anonymous IP address' is a sign-in risk detection.
'User risk expires after 30 days'.
'Azure AD Premium P2' for risk policies.
'Risk levels: Low, Medium, High'.
'Self-remediation options: MFA or password change'.
Edge Cases the Exam Loves
What happens if a user is blocked by a risk policy but also has a Conditional Access policy that grants access? The risk policy is evaluated as part of Conditional Access. If the risk policy blocks, the sign-in is blocked regardless of other grant controls.
Can you use risk policies without Conditional Access? No, they are a type of Conditional Access policy. Conditional Access must be enabled for the tenant.
What if a user's risk is dismissed but the same user triggers a new risk? The new risk is evaluated independently. Dismissing does not prevent future detections.
What is the difference between 'Confirm user compromised' and 'Dismiss user risk'? Confirming adds to user risk (makes it high); dismissing reduces risk. The exam tests that confirming compromise is a manual action that increases risk.
How to Eliminate Wrong Answers
If the question mentions 'risk-based policy' and 'Azure AD Premium', eliminate any option that says P1.
If the question asks about 'user risk', look for aggregate/time-based concepts. If 'sign-in risk', look for per-event.
If the question says 'block access', check if the scenario justifies blocking vs MFA. Usually MFA is safer.
If the question lists detection types, know that 'leaked credentials' is always high risk; others can be low/medium.
Entra ID Protection requires Azure AD Premium P2 licenses for risk-based Conditional Access policies.
User risk aggregates multiple detections over time and expires after 30 days; sign-in risk is per-event.
Leaked Credentials detection always results in High user risk.
Impossible travel detection requires a minimum of 10 minutes between sign-ins and distance > 500 km.
Risk policies are disabled by default and must be manually enabled.
Always exclude break-glass accounts from risk policies to prevent lockout.
Self-remediation options include MFA and password change; both require user registration.
The recommended action for high risk is to require MFA, not block access.
Risk policies are a type of Conditional Access policy and require Conditional Access to be enabled.
Confirming a user as compromised increases user risk; dismissing risk decreases it.
These come up on the exam all the time. Here's how to tell them apart.
User Risk Policy
Evaluates the overall risk of a user account based on historical detections (e.g., leaked credentials, multiple risky sign-ins).
Risk levels: Low, Medium, High based on aggregate signals over time.
Actions: Allow, Require MFA, Block, or Require password change (for high user risk).
User risk expires after 30 days of no new detections.
Commonly used to force password reset when a user is likely compromised.
Sign-In Risk Policy
Evaluates risk of a specific sign-in attempt based on real-time signals (e.g., anonymous IP, impossible travel).
Risk levels: Low, Medium, High per single sign-in event.
Actions: Allow, Require MFA, or Block. No password change option.
Risk is tied to the sign-in event and does not expire; it is evaluated at sign-in time.
Commonly used to require MFA for suspicious sign-ins without affecting the user's account status.
Mistake
Risk policies are available in all Azure AD editions.
Correct
Risk-based Conditional Access policies require Azure AD Premium P2 licenses. P1 allows Conditional Access but not risk conditions. Azure AD Free provides only risk reports without policy enforcement.
Mistake
User risk and sign-in risk are the same thing.
Correct
User risk is an aggregate of all risk detections associated with a user account over time (e.g., multiple compromised sign-ins). Sign-in risk is evaluated per individual sign-in event based on characteristics of that specific authentication attempt.
Mistake
Impossible travel detection requires a minimum of one hour between sign-ins.
Correct
The actual minimum time window is 10 minutes. If two sign-ins occur from locations more than 500 km apart within 10 minutes, it triggers an impossible travel detection.
Mistake
Once a user risk is dismissed, it never comes back.
Correct
Dismissing user risk only clears the current risk score. If new risk detections occur (e.g., another leaked credential), the user risk will increase again. Dismissal does not prevent future detections.
Mistake
Blocking high-risk sign-ins is always the best security practice.
Correct
Blocking can cause lockouts for legitimate users who trigger false positives (e.g., traveling to a new country). The recommended action for high risk is to require MFA, which provides an additional verification step without blocking access entirely.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure AD Premium P2 licenses are required to create and enforce risk-based Conditional Access policies. Azure AD Premium P1 allows Conditional Access but does not include risk conditions. Azure AD Free provides read-only access to risk reports but no policy enforcement. Each user who will be subject to risk policies must have a P2 license assigned.
Navigate to Azure Active Directory > Security > Identity Protection. Under 'User risk policy' and 'Sign-in risk policy', set the policy state to 'Enabled'. Choose the risk level(s) that trigger the policy (e.g., Medium and High). Select the action (Allow, Require MFA, Block). Save the policy. The policies are disabled by default. You must also ensure Conditional Access is enabled for the tenant.
User risk is a cumulative score of all risk detections linked to a user account over time, such as leaked credentials or multiple suspicious sign-ins. It indicates the likelihood that the user's identity has been compromised. Sign-in risk is specific to a single authentication attempt and is based on characteristics of that attempt (e.g., anonymous IP, impossible travel). User risk can trigger actions like password change; sign-in risk can trigger MFA or block.
No. Risk policies are a type of Conditional Access policy. They appear in the Conditional Access blade once enabled in Identity Protection. Conditional Access must be enabled for the tenant (it is enabled by default for most tenants). If Conditional Access is disabled, risk policies will not be evaluated.
The user receives an 'access denied' message and cannot sign in. They can self-remediate if the administrator has enabled self-remediation options (MFA or password change). Alternatively, an administrator can manually dismiss the risk or confirm the user as compromised (which increases risk). To unblock, the admin can also temporarily exclude the user from the policy.
User risk expires after 30 days if no new risk detections occur. If a user has a high user risk but no new detections for 30 days, the risk level will decrease. However, if the user is confirmed as compromised, the risk remains until dismissed. Sign-in risk does not expire; it is evaluated per event.
The exam frequently tests: Leaked Credentials (always high risk), Impossible Travel (requires 10+ min and 500+ km), Anonymous IP Address (Tor/proxy), Unfamiliar Sign-in Properties (new device/location), and Malware Linked IP Address. Know the minimum thresholds for Impossible Travel.
You've just covered Entra ID Protection and Risk Policies — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?