🚨🧑💼IP - Sign-in Risk Policy
What this policy is about 🚨
Entra Identity Protection watches every sign-in to your tenant in real time and decides whether the attempt looks legitimate or compromised. Atypical travel. Anonymous IP. Token replay. Leaked credentials in the wild. Each sign-in gets a risk score: None, Low, Medium, High.
The Sign-in Risk Policy is the part that acts on that score. By default Microsoft does nothing with it. You have to build a policy that says "when the score is High, block. When Medium, require MFA. When Low, log it for review." 🚦
This is one of the highest-leverage controls in the whole Entra stack. It is also tier-up territory. It requires Entra ID P2. Business Premium ships with P1. So this doc is for tenants who have made the conscious decision to add P2 (via E5, Entra ID P2 add-on, or M365 E5 Security).
Why this matters 🎭
Without a Sign-in Risk Policy, a textbook "credentials phished in Brazil, signed in from Brazil at 03:00 to an account whose owner is asleep in Apeldoorn" sign-in event will:
- Be detected by Identity Protection (it shows up in the Risky Sign-ins report)
- Be scored High risk
- Sign in successfully anyway
The detection happens. The response doesn't. Risk-based CA is the response. ⚡
With a Sign-in Risk Policy in place, the same scenario goes:
- Detected by Identity Protection
- Scored High risk
- Sign-in blocked. User shown a generic "couldn't sign you in" page. Admins get an alert.
The legitimate-but-traveling user who occasionally trips the risk engine for low/medium risk gets bumped through an MFA challenge and continues. The attacker on phished credentials hits a brick wall.
The cost is some false positives. A real user on a real holiday occasionally gets blocked. The mitigation is good user education plus a self-service reset path (which Identity Protection ships with). The win is automatic, in-the-moment response to credential-theft scenarios that otherwise reach the helpdesk three days later. 🧱
🛠️ Configuration Settings
Configured as a Conditional Access policy under Protection → Conditional Access (yes, Identity Protection policies are now expressed as CAs in the modern Entra blade; the legacy "Identity Protection → Sign-in risk policy" page is being retired). Tenant-scope, applies to all interactive sign-ins.
Assignments
| Setting | Value | Why |
|---|---|---|
| Users | All users | The risk engine doesn't care who you are. |
| Excluded users | 🛡️🧑💼⛓️🔓🚦Group - Break the Glass solution | The BTG accounts get blocked exactly when you most need them. Always exclude. |
| Cloud apps | All cloud apps | Risk evaluation applies on every sign-in, not just specific apps. |
| Conditions: Sign-in risk levels | High, Medium | Two policies (or one with branching), but the model is: High → block. Medium → require MFA. |
Grant controls
High-risk sign-in
| Setting | Value | Why |
|---|---|---|
| Block access | Enabled | High risk means Identity Protection has high confidence the credentials are compromised. Block. The user can self-remediate via password reset + MFA if they're actually legitimate. |
Medium-risk sign-in
| Setting | Value | Why |
|---|---|---|
| Grant access | Require MFA | The risk is real but not high enough to block legitimate access. MFA challenge filters compromised sessions where the attacker has the password but not the MFA factor. |
| Authentication strength | 🔐🧑💼AS - Authentication Strengths → Phishing-Resistant | Don't accept SMS for a medium-risk sign-in. The whole point is to challenge with something a phisher can't intercept. |
| Sign-in frequency | 1 hour | Force re-auth more often on medium-risk sessions. |
Session controls
| Setting | Value | Why |
|---|---|---|
| Persistent browser session | Never persistent on risk-flagged sign-in | Don't let a medium-risk session establish a persistent browser cookie. CAE handles the live revocation; this stops new persistence. |
Caveats ⚠️
License fit. This is the big one. Sign-in Risk Policy requires Entra ID P2. M365 Business Premium includes Entra ID P1 only. So this policy is a tier-up for the typical MKB tenant. Paths to P2 in 2026:
- Entra ID P2 add-on (~per-user/month, add to Business Premium directly)
- M365 E5 Security (includes Entra ID P2 + Defender for Identity + Defender for Cloud Apps + Defender for Endpoint P2)
- M365 E5 (includes everything in Business Premium plus E5 Security, E5 Compliance, and the productivity bits)
For an MKB tenant whose primary identity threat is credential phishing (most of them), Entra ID P2 add-on is the cheapest path to risk-based response. The MSP-side argument is: "the cost of P2 across your fleet for a year is less than the cost of one incident response engagement." It's a defensible argument. 💰
Risk detection without response. A tenant on P1 (Business Premium) gets the detection of risky sign-ins. You can see them in the Risky Sign-ins report. You cannot automate the response. So a tenant without P2 gets the diagnosis without the medicine. That's worse than knowing in a useful way; it's "knowing about a fire while watching it spread." 🔥
False positives. They happen. A real user on a real holiday in a country they've never been to before, signing in from a hotel Wi-Fi over a VPN, on a personal phone, will trip the risk engine. The mitigation:
- Self-service password reset is enabled and well-documented
- User education includes "if you get a 'we couldn't sign you in' message while traveling, follow the SSPR link"
- The MSP-side alert for blocked sign-ins includes the user's display name and a quick "is this person traveling?" check before any further action
The false-positive rate at recommended thresholds is low (single-digit percentage of risky-flagged sign-ins). Acceptable trade. 🛫
User Risk Policy is separate. This policy is Sign-in Risk — the risk score for a specific sign-in event. There is also User Risk (the risk score for the user account, aggregated over time). Both are recommended. User Risk is documented separately.
Reversibility. The policy is a CA, so it follows CA reversibility rules: clean-revert. Disabling stops further enforcement on the next sync. No tattooed registry values. None of the Update-CSP-style "the value sticks" problems.
💡 SuperVision tip
Baseline policy when the tenant is on P2. Golden Master → Entra → Identity Protection → Sign-in Risk Policy.
Tag candidates:
- P2 licensed? binary, per-tenant. Drives whether this policy is deployed at all on a given tenant.
- Risk-threshold tolerance per-tenant (some customers genuinely want Low risk to also require MFA; default is Medium-and-up, but the Low → MFA stance is a documented opt-in).
Drift detection. Two surfaces:
- Excluded users on this CA. The only legitimate excluded group is BTG. Any other excluded user is a finding.
- Block action getting downgraded to "require MFA" on High risk. Someone trying to reduce helpdesk pain by softening the response is making the wrong trade. Alert. Investigate.
Onboarding. When upgrading a tenant from P1 to P2, the Sign-in Risk Policy is the first new policy to deploy. Before User Risk. The reason: Sign-in Risk catches the real-time attack, User Risk catches the aggregated pattern over time. You want the real-time response first.
Multi-tenant scaling. Policy is identical across all P2 tenants. The variable is whether the tenant has P2 at all. SuperVision should track P2 licensing per tenant and apply / skip this policy based on the binary.
👥 Group Assignments
✅ Included groups:
- All users
❌ Excluded groups:
🔗 Related
- 🚨🧑💼IP - User Risk Policy (the aggregated-over-time companion)
- 🔐🧑💼AS - Authentication Strengths (Medium-risk MFA challenge uses Phishing-Resistant)
- 🛡️🧑💼⛓️🔓🚦Group - Break the Glass solution (always excluded)
🚨 Detection without response is just watching the fire spread.