Entra Identity Protection and Risk Policies
Plan and implement Microsoft Entra Identity Protection to detect risky sign-ins, flag compromised users, and automate risk-based responses.
Automated identity threat detection
Identity Protection is like a credit card fraud department for your user accounts.
When your bank sees a transaction from a country you’ve never visited, they flag it and may block the card. Identity Protection does the same for sign-ins — when a user suddenly signs in from an unusual location, an anonymous IP, or a device with malware, the system detects the risk and responds automatically (require MFA, block access, or force a password change).
You don’t wait for help desk calls to find compromised accounts. The system finds them for you.
Two types of risk
| Feature | Sign-in Risk | User Risk |
|---|---|---|
| What it measures | Likelihood this specific sign-in is illegitimate | Likelihood the user's account is compromised |
| Detection timing | Real-time (during sign-in) or offline | Accumulated over time from multiple signals |
| Example signals | Anonymous IP, impossible travel, malware-linked IP | Leaked credentials, anomalous user activity, suspicious sending patterns |
| Risk levels | None, Low, Medium, High | None, Low, Medium, High |
| Typical response | Require MFA for medium+, block for high | Force password change for medium+, block for high |
| Self-remediation | Complete MFA to prove identity | Change password to prove account control |
Risk detection signals
Sign-in risk detections
| Detection | What It Means | Real-time or Offline |
|---|---|---|
| Anonymous IP address | Sign-in from Tor, VPN, or known anonymiser | Real-time |
| Atypical travel | Sign-in from a location unusual for the user | Offline |
| Impossible travel | Sign-ins from two locations too far apart for travel time | Offline |
| Malware-linked IP | Sign-in from an IP known to communicate with bot servers | Offline |
| Unfamiliar sign-in properties | Sign-in with properties not seen before for the user | Real-time |
| Password spray | Multiple accounts targeted with common passwords | Offline |
| Anomalous token | Token with unusual characteristics | Real-time |
User risk detections
| Detection | What It Means |
|---|---|
| Leaked credentials | User’s credentials found in a known data breach (dark web monitoring) |
| Anomalous user activity | Unusual patterns in user behaviour |
| Suspicious sending patterns | Mailbox sending spam or phishing (may indicate compromised account) |
| User reported suspicious activity | User denies MFA prompt they didn’t initiate |
Implementing risk-based policies
Elena designs Identity Protection for MedGuard Health using Conditional Access policies with risk conditions:
Policy 1: Sign-in risk policy
- Condition: Sign-in risk = Medium or High
- Grant: Require multi-factor authentication
- Effect: Risky sign-ins must prove identity with MFA. Legitimate users complete MFA and continue. Attackers are blocked.
Policy 2: User risk policy
- Condition: User risk = High
- Grant: Require password change (and MFA)
- Effect: Accounts flagged as compromised must change their password. This invalidates any stolen credentials.
Exam tip: Risk policies are now Conditional Access policies
Microsoft has migrated Identity Protection risk policies into Conditional Access. The old “Identity Protection > Sign-in risk policy” and “User risk policy” pages still exist for backward compatibility, but the recommended approach is to create risk-based Conditional Access policies.
The exam may ask: “Where should Elena configure risk-based policies?” → Conditional Access (with sign-in risk or user risk as a condition). Not the legacy Identity Protection policy page.
Risk investigation
When Identity Protection flags a user:
- Review the risk detection — Entra > Protection > Identity Protection > Risk detections
- Investigate the sign-in — check location, device, IP, application
- Decide: legitimate (dismiss risk) or compromised (confirm risk)
- If compromised: force password change, revoke sessions, investigate further
- If legitimate: dismiss the detection (improves the ML model)
Deep dive: Bulk risk operations
At GlobalReach’s scale (20,000 users), Priya can’t investigate every risk detection individually. She uses:
- Automatic remediation via CA policies — most medium-risk sign-ins resolve themselves when users complete MFA
- Risk-based reports — filter by risk level, focus investigation on High-risk users
- Microsoft Graph API — programmatic access to risk detections for integration with SIEM tools
- Bulk dismiss — after investigation confirms false positives (e.g., a new VPN provider flagging as anonymous IP)
The goal is to investigate High-risk detections manually and let automation handle Medium and Low.
Key concepts to remember
Knowledge check
Elena notices that a MedGuard Health doctor's account has been flagged with High user risk. Identity Protection shows 'Leaked credentials' as the detection. The doctor confirms they haven't noticed any suspicious activity. What should Elena do?
Priya sees hundreds of Medium sign-in risk detections daily at GlobalReach. Most are from users accessing M365 from new locations during business travel. What is the most efficient way to handle this?
🎬 Video coming soon
Next up: Conditional Access and MFA Enforcement — the policy engine that ties everything together.