This chapter covers Microsoft Entra Identity Protection, a critical security tool for detecting and responding to identity-based risks in Azure AD. For the AZ-500 exam, this topic appears in roughly 10-15% of questions under objective 1.4 (Manage identity protection). You must understand how risk detection works, the difference between user and sign-in risk, and how to configure risk-based conditional access policies. This chapter provides the deep technical knowledge you need to answer exam questions confidently and to implement identity protection in real-world environments.
Jump to a section
Microsoft Entra Identity Protection works like a bank's credit card fraud detection system. The bank knows your typical spending patterns: where you shop, at what times, and for how much. When a transaction deviates — say a $2,000 purchase at 3 AM in a foreign country — the system flags it as risky. It doesn't automatically block it; instead, it may send you an SMS to verify, or temporarily decline the transaction until you confirm. Similarly, Entra ID Protection continuously learns what 'normal' sign-in behavior looks like for each user: typical locations, devices, and times. When a sign-in deviates — like from an anonymous IP or an unfamiliar location — it assigns a risk level (low, medium, high). Based on policies you configure, it can require MFA, block the sign-in, or force a password reset. Just as the bank updates its fraud models with new data, Entra ID Protection uses machine learning to adapt to evolving threats. The key mechanism is risk-based conditional access: the system evaluates risk in real-time and enforces the appropriate control, much like the bank's real-time authorization system that decides whether to approve, decline, or challenge a transaction.
What is Microsoft Entra Identity Protection?
Microsoft Entra Identity Protection (formerly Azure AD Identity Protection) is a cloud-based security service that uses machine learning and heuristics to detect, investigate, and remediate identity-based risks. It continuously analyzes billions of sign-in events and user behaviors to identify suspicious activity. The service is part of Microsoft Entra (the new name for Azure Active Directory) and is available in Azure AD Premium P2 licenses.
Why It Exists
Traditional perimeter-based security is ineffective in a cloud-first, mobile-first world. Attackers often compromise credentials through phishing, password spraying, or credential stuffing. Identity Protection provides a dynamic, risk-based approach: instead of always blocking or always allowing, it evaluates the risk level of each sign-in and user, then applies appropriate controls (e.g., require MFA, block access, force password reset). This balances security and user productivity.
How It Works Internally
Identity Protection relies on two primary risk types: - Sign-in risk: Probability that a given authentication request is not authorized by the identity owner. - User risk: Probability that a user's identity has been compromised.
Risk is calculated using real-time and offline detections: - Real-time detections: These occur during sign-in and include risks like anonymous IP address, unfamiliar sign-in properties, and atypical travel (impossible travel). Real-time detections are evaluated before authentication completes. - Offline detections: These are processed after the sign-in event, using machine learning models that analyze patterns over time. Examples include leaked credentials, password spray, and malware-linked IP addresses.
Key Components and Defaults
Risk Levels: Low, Medium, High. Each detection type has a predefined severity. For example, 'Leaked Credentials' is always High risk. 'Unfamiliar sign-in properties' can be Low, Medium, or High depending on confidence.
Risk Detections: A list of all detected risks. Each detection has a detection type, risk level, date, and associated user/sign-in.
Risky Users: Users with one or more risk detections. The user risk level is the highest risk level among their detections.
Risky Sign-ins: Sign-in events that have been flagged as risky.
Risk-Based Conditional Access Policies: These policies are triggered by user or sign-in risk level. They can enforce actions like requiring MFA, requiring password change, or blocking access.
Configuration and Verification
To configure Identity Protection: 1. Navigate to Microsoft Entra admin center > Protection > Identity Protection. 2. Under Risk detections, you can review detections. 3. Under Risky users and Risky sign-ins, you can investigate. 4. To create a risk-based policy: Conditional Access > Policies > New policy. Under Assignments > Conditions > User risk or Sign-in risk, select the risk level(s). Under Access controls, choose the action (e.g., Block, Require MFA, Require password change). 5. Enable the policy.
Verification commands using Microsoft Graph PowerShell:
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All", "IdentityRiskyUser.Read.All"
# Get risky users
Get-MgRiskyUser -Top 10
# Get risk detections for a user
Get-MgRiskyUserHistory -RiskyUserId "user-id"
# Get risky sign-ins
Get-MgRiskySignIn -Top 10Interaction with Related Technologies
Conditional Access: The primary enforcement mechanism. Risk levels are used as conditions in Conditional Access policies.
Microsoft Defender for Cloud Apps: Can feed additional risk signals (e.g., impossible travel from cloud apps) into Identity Protection.
Microsoft 365 Defender: Correlates identity risks with other signals (e.g., email phishing) for a unified incident.
Azure AD P2 Licensing: Required for risk-based policies and user risk remediation.
Detection Types (Key for Exam)
Leaked Credentials: Credentials found in public data breaches. Always High risk.
Anonymous IP Address: Sign-in from an anonymous proxy or Tor network. Medium risk.
Atypical Travel: Sign-in from a location that is not typical for the user, indicating impossible travel. High risk.
Unfamiliar Sign-in Properties: Sign-in with properties (e.g., IP, device, location) not seen before for that user. Low/Medium/High.
Malware Linked IP Address: IP address known to be associated with botnets. Medium risk.
Password Spray: Multiple accounts attacked with same password. High risk.
Suspicious Browser: Browser that exhibits suspicious characteristics. Medium risk.
Token Issuance Anomaly: Unusual token issuance pattern. Medium risk.
Timers and Expiration
User risk expires after 30 days if no new detections. After that, the user is no longer considered risky.
Sign-in risk is evaluated per event and does not expire; each sign-in has its own risk assessment.
Remediation actions (e.g., password reset) reduce user risk to zero.
Summary of Mechanism
User attempts to sign in.
Identity Protection evaluates real-time detections (e.g., anonymous IP, unfamiliar location).
If a risk is detected, a risk level is assigned.
Conditional Access policy checks if the risk level matches the policy condition.
If matched, the policy applies the access control (e.g., block, require MFA).
After sign-in, offline detections may generate new risks, updating user risk.
Admins can review risks and take manual actions (confirm compromise, dismiss risk).
This continuous cycle ensures that identities are protected in real-time and after the fact.
User Initiates Sign-In
The user enters their credentials on an application (e.g., Office 365, custom app). The authentication request is sent to Microsoft Entra ID (Azure AD). At this point, the sign-in is not yet complete; Identity Protection begins evaluating the request in real-time.
Real-Time Risk Detection
Identity Protection checks the sign-in against real-time detection models. It examines the IP address, device fingerprint, location, and other properties. For example, if the IP is from an anonymous proxy, a detection is created. Each detection has an associated risk level (Low, Medium, High). The system aggregates all real-time detections into a single sign-in risk level.
Conditional Access Policy Evaluation
The sign-in risk level is passed to Conditional Access. If a policy exists that targets this risk level (e.g., 'Require MFA for Medium and High risk sign-ins'), the policy is triggered. The policy may also include other conditions (user, location, app). If the policy requires blocking, the sign-in is denied immediately. If it requires MFA, the user is prompted for additional verification.
Post-Sign-In Offline Detection
After the sign-in completes (or is blocked), offline detections are processed. These include leaked credentials, password spray, and atypical travel (which requires comparing with previous sign-ins). These detections are added to the user's risk profile. If a high-risk detection like leaked credentials is found, the user risk level is elevated to High.
User Risk Remediation
If user risk reaches a threshold (e.g., High), a Conditional Access policy can force a password reset on next sign-in. Alternatively, an admin can manually dismiss or confirm compromise. If the user resets their password, the user risk is reset to zero. The system also automatically remediates some risks (e.g., after a password change, leaked credentials risk is cleared).
Enterprise Scenario 1: Large Multinational Corporation
A company with 50,000 employees uses Azure AD P2 licenses. They enable Identity Protection with risk-based Conditional Access policies. They configure a policy that requires MFA for any sign-in with medium or high risk. They also configure a user risk policy that forces password reset for high-risk users.
Problem solved: Employees frequently travel, and their accounts are targeted by phishing. The risk-based approach ensures that only suspicious sign-ins are challenged, not all sign-ins. This reduces MFA fatigue.
Configuration: They enable all default risk detections. They create a Conditional Access policy named 'Require MFA for risky sign-ins' with condition 'Sign-in risk: Medium and High' and grant control 'Require MFA'. They also create a policy 'Require password change for risky users' with condition 'User risk: High' and grant control 'Require password change'.
Performance: The system processes millions of sign-ins daily. Real-time detections add minimal latency (milliseconds). Offline detections are processed within minutes.
Common misconfiguration: Setting sign-in risk policy to 'Block' for medium risk. This can block legitimate users who use a VPN (which may appear as anonymous IP). Best practice is to use 'Require MFA' rather than block for medium risk.
Scenario 2: Small Business with Limited IT Staff
A 200-employee company uses Azure AD P1 (no Identity Protection). They want to implement risk-based security but lack budget for P2. They rely on third-party MFA and manual review of sign-in logs.
What goes wrong: They cannot automate remediation. When a user's credentials are leaked, they only find out after a breach. They cannot enforce password reset automatically.
Solution: They upgrade to P2 to use Identity Protection. They configure a single policy: 'Block sign-ins for high-risk users'. This minimizes administrative overhead.
Scenario 3: Healthcare Organization with Compliance Needs
A hospital must comply with HIPAA. They use Identity Protection to detect impossible travel and leaked credentials. They configure alerts for high-risk detections to be sent to the security team.
Scale: They have 10,000 users. They use Identity Protection reports for audit evidence.
Misconfiguration pitfall: They initially set the user risk policy to 'Block' for medium risk, which blocked several doctors using remote desktops from home (unfamiliar sign-in properties). They changed to 'Require MFA' to avoid blocking legitimate access.
Key lesson: Always test policies in 'Report-only' mode first before enforcing them.
Exactly What AZ-500 Tests
Objective 1.4: Manage identity protection. You must know:
The two risk types: user risk and sign-in risk.
The default risk detection types and their risk levels (e.g., Leaked Credentials = High, Anonymous IP = Medium).
How to configure risk-based Conditional Access policies (conditions: user risk, sign-in risk).
The difference between real-time and offline detections.
Remediation actions: password reset (for user risk), MFA (for sign-in risk), blocking.
Licensing requirements: Azure AD Premium P2 for risk-based policies.
Common Wrong Answers and Why
'Identity Protection requires Azure AD P1' – Wrong. P1 does not include risk-based policies. P2 is required.
'User risk is evaluated in real-time during sign-in' – Wrong. User risk is calculated from offline detections and is not evaluated in real-time. Sign-in risk is real-time.
'You can use Identity Protection without Conditional Access' – Wrong. Identity Protection detects risks, but enforcement requires Conditional Access policies (or manual actions).
'Block is the best action for medium sign-in risk' – Wrong. Block is too aggressive for medium risk; MFA is recommended.
Specific Numbers and Terms
Risk levels: Low, Medium, High.
Detection types: Leaked Credentials, Anonymous IP, Atypical Travel, Unfamiliar Sign-in Properties, Malware Linked IP, Password Spray, Suspicious Browser, Token Issuance Anomaly.
Default risk level for Leaked Credentials: High.
Default risk level for Anonymous IP: Medium.
User risk expires after 30 days.
Licensing: Azure AD Premium P2.
Edge Cases
What happens if a user is high risk but the policy is set to 'Require MFA'? The user will be prompted for MFA on next sign-in, but the risk remains until remediated.
What if a sign-in is blocked but the user is legitimate? The user must contact IT. IT can review the risk detection and dismiss it if false positive.
Can Identity Protection detect risks for on-premises users? Only if they are synced to Azure AD and using cloud authentication (PHS or PTA).
How to Eliminate Wrong Answers
If the question mentions 'real-time' and 'user risk', it's wrong. User risk is offline.
If the question asks for licensing, P2 is always the answer for risk-based policies.
If the question asks about enforcement, look for Conditional Access in the answer.
If the question mentions 'block' for low or medium risk, it's likely wrong unless the scenario specifies extreme caution.
Identity Protection detects two types of risk: user risk (offline) and sign-in risk (real-time).
Risk levels are Low, Medium, and High; each detection type has a default severity (e.g., Leaked Credentials = High).
Enforcement requires Conditional Access policies; Identity Protection alone does not block or challenge.
Azure AD Premium P2 licensing is required for risk-based Conditional Access policies.
User risk expires after 30 days with no new detections.
Real-time detections include anonymous IP, unfamiliar sign-in properties, and atypical travel (though atypical travel is also offline).
Offline detections include leaked credentials, password spray, and malware-linked IP.
Common remediation actions: password reset (user risk), MFA (sign-in risk), block (sign-in risk).
Always test risk policies in Report-only mode before enforcing.
Identity Protection integrates with Microsoft Defender for Cloud Apps and Microsoft 365 Defender.
These come up on the exam all the time. Here's how to tell them apart.
User Risk Policy
Triggers on user risk level (Low, Medium, High).
Evaluated on every sign-in after offline detections update user risk.
Common action: Require password change.
Remediation reduces user risk to zero.
Best for responding to compromised credentials.
Sign-In Risk Policy
Triggers on sign-in risk level (Low, Medium, High).
Evaluated in real-time during each sign-in.
Common action: Require MFA or block.
No persistent risk; each sign-in is assessed independently.
Best for blocking or challenging suspicious sign-ins.
Mistake
Identity Protection automatically blocks risky sign-ins.
Correct
Identity Protection only detects and assigns risk. Enforcement (block, MFA, password reset) requires Conditional Access policies. Without policies, no action is taken.
Mistake
User risk and sign-in risk are the same thing.
Correct
User risk is the probability that the user's identity is compromised (based on offline detections). Sign-in risk is the probability that a specific sign-in is unauthorized (based on real-time detections). They are separate concepts with separate policies.
Mistake
All risk detections are evaluated in real-time.
Correct
Only some detections are real-time (e.g., anonymous IP, unfamiliar sign-in properties). Others are offline (e.g., leaked credentials, password spray). Real-time detections affect sign-in risk; offline detections affect user risk.
Mistake
You need Azure AD P1 to use Identity Protection risk policies.
Correct
Identity Protection risk policies (user risk and sign-in risk policies) require Azure AD Premium P2. P1 only provides basic Identity Protection reports without automated remediation.
Mistake
If a user's risk is dismissed, the risk detections are deleted.
Correct
Dismissing a risk does not delete the detection; it marks it as dismissed. The detection remains in the logs for auditing. The user's risk level is reset to None, but the detection record persists.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
User risk indicates the likelihood that a user's identity has been compromised, based on offline detections like leaked credentials. Sign-in risk indicates the likelihood that a specific sign-in attempt is unauthorized, based on real-time detections like anonymous IP. User risk persists across sign-ins until remediated; sign-in risk is per event. Both can trigger Conditional Access policies, but user risk policies typically force password reset, while sign-in risk policies require MFA or block.
Yes, risk-based Conditional Access policies (user risk and sign-in risk policies) require Azure AD Premium P2 licenses. Azure AD P1 provides access to Identity Protection reports and manual risk review but not automated remediation. Without P2, you cannot create policies that automatically require MFA or password reset based on risk.
Go to Microsoft Entra admin center > Protection > Conditional Access > New policy. Name it, assign users/groups, under Conditions > Sign-in risk, select Medium and High. Under Grant, select 'Require multifactor authentication'. Enable the policy. This policy will trigger MFA only when the sign-in risk is medium or high, not on every sign-in.
The user sees a message on next sign-in that they must change their password. After successful password change, the user's risk level is reset to None, and the risk detections are cleared (or marked as remediated). The user can then access resources as normal. This is the most common remediation for high user risk.
Yes, but only if the federated identity provider passes the sign-in to Azure AD for authentication. If the federation provider handles authentication entirely on-premises (e.g., ADFS without Azure AD sign-in), Azure AD cannot evaluate risk. For cloud-managed authentication (PHS, PTA), Identity Protection works fully.
Atypical travel detects impossible travel: two sign-ins from locations that are far apart within a time frame that makes travel between them impossible. It uses machine learning to establish a baseline of the user's typical locations. This detection is both real-time and offline. It is High risk and often indicates credential theft.
User risk persists until remediated (e.g., password reset) or until 30 days have passed with no new risk detections. After 30 days, the user's risk level automatically resets to None. However, the risk detections remain in logs for auditing.
You've just covered Microsoft Entra Identity Protection — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?