Skip to main content

🚨🧑‍💼IP - User Risk Policy

What this policy is about 🚨​

The Sign-in Risk Policy reacts to a single suspicious sign-in event. The User Risk Policy reacts to a pattern of evidence about the user account itself, aggregated over time. Different scope. Different response. 📊

User risk scores include:

  • Leaked credentials. Microsoft has found this user's username + password combo in a public credential dump. Critical.
  • Azure AD threat intelligence. Microsoft's research correlated this user account with known-bad activity.
  • Anomalous user activity detected over multiple sign-ins.
  • Sign-in risk events accumulated over time even when no single one was High.

When the aggregated User Risk hits High, the response is not "challenge this sign-in" (that's the Sign-in Risk Policy's job). The response is: the credentials themselves are no longer trustworthy. Force a password reset before this user signs in again. 🔁

Why this matters 🎭​

Sign-in Risk Policy is the smoke alarm. User Risk Policy is the diagnosis.

Imagine the same user account trips a Low-risk sign-in event four times in two days. None of them individually crosses the threshold for the Sign-in Risk Policy to block. But Identity Protection's machine learning is correlating them into an aggregated User Risk score that climbs from Low to Medium to High. The Sign-in Risk Policy never sees it. The User Risk Policy does. 🧠

Or: Microsoft's threat-intel pipeline finds this user's password in a Pastebin leak from a third-party breach. The user hasn't been compromised yet. Their sign-in events still look normal. But the credentials are now public, and any of the next 50 sign-in attempts could be the attacker. The Sign-in Risk Policy will trip when the attacker actually signs in, if their behavior is anomalous enough. The User Risk Policy doesn't wait for that. The credentials are burned; rotate them. 🔐

The doc you're reading is the policy that forces that rotation automatically, instead of waiting for someone to read the Risky Users report once a week.

🛠️ Configuration Settings​

Configured as a Conditional Access policy under Protection → Conditional Access. Tenant-scope.

Assignments​

SettingValueWhy
UsersAll usersThe risk engine evaluates every user regardless of role.
Excluded users🛡️🧑‍💼⛓️🔓🚦Group - Break the Glass solutionBTG accounts use only FIDO2; forcing a password reset on them doesn't make sense and would interfere with the emergency-access design.
Cloud appsAll cloud appsUser risk applies regardless of which app the user reaches for first.
Conditions: User risk levelHighOnly High user risk triggers this policy. Medium is informational; force-reset on every medium-risk user creates noise without proportional benefit.

Grant controls​

SettingValueWhy
Require password changeEnabledUser must reset their password before further sign-ins succeed. The reset itself requires MFA (because the Authentication Methods policy enforces MFA on SSPR), which means the attacker can't simply reset the password using only the leaked credentials.
Require MFAEnabled (paired with password change)Belt-and-suspenders. The MFA challenge during the reset is the actual control; the password change is the response.

What this looks like to the user​

On their next sign-in attempt, the user sees a Microsoft-branded screen that says "Your access has been blocked because we detected suspicious activity. Please reset your password." They go through the SSPR flow (which requires their MFA factor), set a new password, and continue. The whole flow is 60-90 seconds for a user who has Microsoft Authenticator set up. 🧭

For an attacker with phished credentials but no MFA factor: they can't complete the reset. They're locked out. The legitimate user can recover via SSPR. The attacker can't. 🚫

Caveats ⚠️​

License fit. Same as Sign-in Risk. Entra ID P2 required. See the Sign-in Risk Policy doc for the upgrade paths.

MFA registration is a hard prerequisite. This policy assumes the user has MFA factors registered, because the password reset flow uses them. If a user is on the policy but doesn't have MFA registered, the policy will block them and they cannot self-recover. They have to call the helpdesk. So User Risk Policy should be deployed only after the MFA registration CA and the Authentication Methods registration campaign have produced full MFA coverage. 📞

Don't apply to BTG accounts. Stated above but worth repeating. BTG accounts have no Microsoft Authenticator, no SMS, no email recovery. They have FIDO2 keys. Forcing a password reset would interact with that design in unpredictable ways. Always exclude.

Leaked credential detection has a delay. Microsoft adds leaked credentials to their detection pipeline asynchronously. A credential leak that happened on Monday might surface in Identity Protection on Tuesday or Wednesday. Don't expect minute-by-minute response on the leaked-credentials detection. The aggregated-over-time anomaly detection is more real-time. ⏱️

Service accounts. Service accounts that sign in via password should not be on this policy because they can't go through SSPR. Either exclude them via a group or migrate them to managed identities, which is the correct long-term answer anyway. Managed identities don't have passwords to leak. 🤖

User experience. A forced password reset is the most disruptive Identity Protection response. The user is interrupted mid-task. Communications matter:

  • The SSPR landing page should be branded with the customer's logo and a short "this is normal, follow the prompts" message
  • The MSP helpdesk should be notified of every User Risk Policy trigger so they can proactively reach out to the user
  • The user should be told what happened (their credentials were exposed, here's what we did) in plain language afterward

Reversibility. Standard CA. Clean-revert on policy disable. No tattooing.

💡 SuperVision tip​

Baseline policy when tenant is on P2. Same scoping as Sign-in Risk: deployed when the tenant is licensed, skipped when not.

Tag candidates:

  • P2 licensed? binary, per-tenant.
  • Service accounts excluded as a tagged group per tenant (typically named 🛡️🧑‍💼👈🔓Group - Service Accounts (no risk policies) or similar; varies per tenant).

Drift detection. Watch the excluded-users list. Legitimate exclusions: BTG (always), service accounts (per tenant). Anything else is a finding.

Onboarding sequence on a P2 tenant.

  1. Confirm MFA registration coverage is at or near 100% (via the Authentication Methods Activity report)
  2. Deploy Sign-in Risk Policy first (real-time response)
  3. Deploy User Risk Policy second (aggregated response)
  4. Pilot both for one week with notifications-only / report-only mode if available, then promote to enforce

Reporting. The Risky Users report in Identity Protection shows the User Risk evolution per user over time. Pull this weekly during the first month of deployment to calibrate; pull monthly thereafter.

Multi-tenant scaling. Identical policy across P2 tenants. The variable is the per-tenant Service Accounts exclusion group composition.

👥 Group Assignments​

✅ Included groups:​

  • All users

❌ Excluded groups:​

🔗 Related​

🔐 The credentials were burned. Rotate them automatically, before someone else does it for you.