2.3.1. User Risk and Sign-In Risk
💡 First Principle: Two different questions get two different scores. Sign-in risk: "is this authentication attempt really the owner?" — scored per event, often in real time. User risk: "is this account compromised?" — a persistent state on the identity, accumulating from evidence like credentials found in a breach dump. The remediation differs because the diagnosis differs: challenge the event with MFA; cure the account with a secure password change.
| Sign-in risk | User risk | |
|---|---|---|
| Question | Is this attempt legitimate? | Is this account compromised? |
| Attached to | A single sign-in event | The user object (persists) |
| Example detections | Anonymous IP, impossible/atypical travel, unfamiliar sign-in properties, password spray, token anomaly | Leaked credentials, threat-intel flags of user compromise |
| Timing | Real-time or near-real-time (some offline) | Mostly offline/aggregated |
| Standard remediation | Require MFA | Require secure password change |
| Levels | Low / Medium / High | Low / Medium / High |
Detections worth recognizing by name: anonymous IP address (Tor/anonymizer), impossible travel (two sign-ins geographically impossible to connect), unfamiliar sign-in properties (deviation from the user's learned pattern), password spray, token anomaly/replay, leaked credentials (Microsoft finds the user's credential pair in the wild — drives user risk straight to high). Real-time detections can raise sign-in risk during the sign-in so a CA policy catches it live; offline detections may land minutes later — which is one reason user-risk policies matter even with sign-in-risk policies in place.
Licensing note the exam checks: full risk detail and risk-based policy require P2; P1 tenants see limited information.
⚠️ Exam Trap: Successful MFA on a risky sign-in remediates that sign-in's risk — but it does not clear user risk. A high-risk user keeps their state until a secure password change, admin dismissal, or confirmed-safe determination.
Reflection Question: Leaked-credentials detection fires for a user who is on vacation and hasn't signed in for a week. Which risk type rises, why is MFA-at-next-sign-in an insufficient response, and what should policy demand instead?
