AD1.7 Entra ID Protection: Risk-Based Policies
Figure AD1.7 — Entra ID Protection detects two types of risk: sign-in risk (real-time, evaluated during authentication) and user risk (offline, accumulated from breach databases and threat intelligence). E3 tenants see these detections in reports and logs. E5/P2 tenants can build conditional access policies that respond automatically.
What E3 gives you — and what P2 adds
With E3 (Entra ID P1), you get visibility into risk detections. Navigate to entra.microsoft.com → Protection → Identity Protection → Risk detections. This report shows every risk detection Microsoft has identified for your users — leaked credentials, atypical travel, anonymous IP usage, and more. Each detection shows the user, the risk level, the detection type, and the timestamp.
What E3 doesn’t give you is automated response. You can see that j.morrison’s credentials appeared in a breach database, but you can’t create a conditional access policy that automatically forces a password change. With E3, your response to risk detections is manual: check the report weekly, investigate flagged accounts, and reset passwords for confirmed compromises.
With P2 (available as an add-on for specific users — you don’t need P2 for all 210 users), you can create risk-based conditional access policies: “When sign-in risk is high, block access.” “When user risk is medium or high, require password change.” These policies respond in real-time or near-real-time, closing the gap between detection and response from hours (manual) to seconds (automated).
Configuring risk-based policies (P2 only)
If you have Entra ID P2 (for all users or as an add-on for administrators), you can build conditional access policies that respond to risk automatically. Navigate to entra.microsoft.com → Protection → Conditional Access → New policy.
For sign-in risk: Name the policy “CA004 - Block High Risk Sign-ins.” Users: All users, exclude break-glass. Cloud apps: All cloud apps. Conditions: Sign-in risk → High. Grant: Block access. This policy blocks any sign-in that Microsoft classifies as high risk — anonymous IP, malware-linked IP, impossible travel from unknown device, or token issuer anomaly. The user can re-authenticate from a clean device to regain access.
For user risk: Name the policy “CA005 - Require Password Change on High User Risk.” Users: All users, exclude break-glass. Cloud apps: All cloud apps. Conditions: User risk → High. Grant: Require password change. This policy forces an immediate password change when Microsoft detects that a user’s credentials appeared in a breach database. The user is prompted to change their password on their next sign-in — no admin intervention needed. This is the automated equivalent of the manual process you learned for E3: check the leaked credentials report, identify affected users, reset their passwords.
Both policies can be deployed in report-only mode first to measure the impact before enforcement. In report-only mode, check the sign-in log for entries that would have been blocked or would have required password change — this tells you how often the policies would trigger in your environment.
One important operational detail: after investigating a risky sign-in, you should set its risk state to either “Confirmed compromised” (triggers immediate remediation if P2 policies are active) or “Dismissed” (clears the risk flag for false positives). Leaving risk detections in the “At risk” state indefinitely creates noise that makes the report unusable over time. Navigate to Identity Protection → Risky sign-ins → click the detection → set state. Make this part of your investigation workflow: investigate, decide, and set the state. A clean risk report with all detections resolved is far more useful than a report with hundreds of unresolved detections from six months of accumulation. The practical recommendation for E3 environments: add the risky sign-ins report to your Monday morning review. Navigate to Protection → Identity Protection → Risky sign-ins. Filter by “Risk level: High.” If you see any entries, investigate the affected account using the sign-in log (check the source IP, device, and location). If the risk is confirmed, reset the password and revoke sessions.
If you have budget for a single P2 add-on, apply it to your administrator accounts. Admin accounts with P2 get risk-based conditional access — which means a compromised admin password from a breach database triggers an automatic password change requirement before the attacker can use it. At approximately £7/user/month for the P2 add-on, protecting 4-5 admin accounts costs under £35/month. The cost of a single compromised Global Administrator account dwarfs this.
Reading the risky sign-ins report
The risky sign-ins report at Protection → Identity Protection → Risky sign-ins is the most actionable report for an E3 administrator. Each row shows a sign-in that Microsoft flagged as suspicious. The key columns are:
Risk level — Low, Medium, or High. Focus on High first, then Medium during your weekly review. Low detections are usually noise (VPN usage, shared IP addresses).
Risk detection — The specific reason the sign-in was flagged. “Atypical travel” means the user signed in from two locations that are geographically impossible to travel between in the time gap. “Anonymous IP address” means the sign-in came from a VPN or Tor exit node. “Leaked credentials” means the user’s password appeared in a known breach database. “Password spray” means the sign-in was part of a detected spray attack.
User — The affected account. Click the user to see their full sign-in history and risk profile.
IP address and Location — Where the sign-in came from. Cross-reference with the user’s expected location.
For each high-risk detection, the investigation takes 3-5 minutes: check the user’s recent sign-in log for the flagged IP, determine if the sign-in was from a location/device the user actually uses, and make the call — legitimate (dismiss the risk) or compromised (reset password, revoke sessions, investigate further).
Investigating an “impossible travel” detection
Impossible travel is the most common risk detection and also the most common false positive. Microsoft flags it when a user signs in from London at 09:00 and from New York at 09:15 — a physical impossibility. But it’s not always malicious. A user connecting through a VPN that exits in another country triggers impossible travel. A user whose phone is on a mobile network in one location while their laptop is on a corporate VPN in another triggers it. Cloud services that authenticate on behalf of the user from their data center location trigger it.
The investigation is straightforward. Check the sign-in log for both sign-ins. Look at the device info — are both from the same registered device? Look at the client app — is one from “Browser” and the other from “Mobile Apps and Desktop Clients”? If both sign-ins are from known devices with the same client app, it’s likely a VPN or network routing issue. If one sign-in is from an unknown device with a different client app, investigate further — check with the user whether they were in both locations.
For organisations where remote work and VPN usage make impossible travel alerts frequent false positives, the pragmatic approach is to focus on impossible travel detections that also have a second risk indicator: unfamiliar device, new client app, or post-sign-in configuration changes. An impossible travel detection from a known device is usually a false positive. An impossible travel detection from an unknown device followed by inbox rule creation is almost certainly an attack.
The risky sign-ins report shows a “Leaked credentials” detection for s.chen@northgateeng.com — Microsoft found s.chen’s password in a newly published breach database. The sign-in log shows no unusual sign-in activity from s.chen’s account. No failed sign-ins from unknown IPs, no sign-ins from unexpected locations. The credentials were leaked but haven’t been used against your tenant yet. What do you do?
Option A: Nothing — the credentials haven’t been exploited and there’s no sign of compromise.
Option B: Reset s.chen’s password immediately, notify the user, and monitor the account for 30 days.
Option C: Wait to see if an attacker tries to use the credentials, then respond.
The correct answer is Option B. Leaked credentials are a ticking clock. The fact that no attacker has used them yet doesn’t mean they won’t — credential lists circulate between attackers, and the usage may be delayed by hours, days, or weeks. Reset the password proactively, notify the user that their password was found in a breach database and they should change passwords on any other services where they used the same password, and add the account to your monitoring list for 30 days. With P2, this response would be automated — the conditional access policy would force a password change on the next sign-in. With E3, you do it manually, but you do it now — not after the attacker gets there first.
Try it: Check your risky sign-ins report
Navigate to entra.microsoft.com → Protection → Identity Protection → Risky sign-ins. Set the time range to the last 30 days. Note the total count and filter by risk level.
If you see High risk detections, click on one. Read the detection type, the user, the source IP, and the location. Check the user’s sign-in log for that time period. Can you determine whether the sign-in was legitimate or suspicious?
If you see “Leaked credentials” detections, these are accounts whose passwords appeared in known breach databases. Even if the accounts have MFA (which stops the attacker from using the password alone), the user is likely reusing that password on other services — inform them so they can change it everywhere.
If you see zero detections, that’s normal for a small tenant with MFA enforced — most risk detections are for credential-based attacks that MFA blocks before the sign-in succeeds. The detections that do appear are typically leaked credentials (detected offline from breach databases, not from actual sign-in attempts) and atypical travel (often VPN-related false positives).
You're reading the free modules of M365 Security: From Admin to Defender
The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.