What is a Risky User?
A Risky User is a Microsoft Entra ID Identity Protection classification indicating that a user's account is likely compromised. Learn how risk is calculated and how to respond.
What is a Risky User?
Definition
A Risky User is a classification in Microsoft Entra ID Identity Protection indicating that a user's account is likely compromised — based on aggregated risk detections from sign-ins, leaked credentials, anomalous behavior, and threat intelligence.
User risk is reported as Low, Medium, or High, and persists until remediated (password reset, dismissal, or admin action).
In simple terms:
A Risky User is Microsoft saying: "we think this account is in trouble — do something."
Why Risky Users Matter
- Identity Protection signals are derived from trillions of authentication events across Microsoft.
- Acting on risky users is one of the highest-ROI security actions in Entra ID.
- Compromised user accounts are the entry point for most cloud breaches.
- Conditional Access can automatically respond to user risk.
How User Risk Is Calculated
User risk is aggregate across sign-ins and detections over time. Inputs include:
- Risky sign-in detections.
- Leaked credentials (Microsoft sees them on dark web / breach data).
- Threat intelligence matches.
- Anomalous travel (impossible travel).
- Atypical sign-in properties.
- Malware-linked IP sign-ins.
- Anonymous IP sign-ins (TOR, anonymizers).
- Unfamiliar sign-in properties.
- Password spray detections.
- Suspicious browser detections.
The risk engine uses Microsoft's threat intelligence and ML to compute a level.
Risk Levels
- Low — unusual but not strongly suspicious.
- Medium — suspicious patterns observed.
- High — strong indicators of compromise (e.g., confirmed leaked credentials).
Sign-in Risk vs User Risk
- Sign-in risk is real-time per sign-in event.
- User risk is cumulative across the user's history.
A user can be flagged risky without any single sign-in being risky (e.g., from leaked credential detection); a single sign-in can be risky without making the user risky (e.g., one-off anomaly).
Risky User Lifecycle
- Detected — Identity Protection flags risk.
- Reported — appears in Risky Users dashboard.
- Remediated — password reset by user (after risk-based prompt), admin reset, or self-remediation via secure password change.
- Dismissed — admin marks as not compromised.
- Confirmed compromised — admin marks as compromised; triggers automated response.
Responding to Risky Users
Manual Actions
- Reset password.
- Confirm user compromised (triggers Conditional Access remediation).
- Dismiss user risk.
- Block user.
- Investigate via sign-in logs.
Automated Actions (Conditional Access)
- Require password change on Medium/High user risk.
- Block sign-in on High risk.
- Require MFA on Medium sign-in risk.
- Require strong authentication on any risk.
Policy Pattern
If user risk = High → Block + force secure password reset.
If sign-in risk = High → Block.
If sign-in risk = Medium → Require MFA.
Real-World Examples
1. Leaked Credentials
User's password appears in a breach database. Identity Protection detects via Microsoft's intel feed. User flagged High. Conditional Access requires immediate secure password reset.
2. Impossible Travel
Sign-in from New York at 09:00, then Singapore at 09:30. CA requires MFA; suspicious sign-in flagged.
3. Password Spray
Mass password spray attack detected by Microsoft globally. Affected users flagged. Defender for Identity / SOC investigates.
4. Anonymous IP Sign-In
User signs in via TOR (legitimate or not). Sign-in flagged risky; CA requires MFA + compliant device.
5. After-Hours Sign-In Anomaly
Unfamiliar browser + new country at 03:00. ML-detected anomaly. CA forces MFA + flags for SOC review.
Common Pitfalls
- Risky users not actioned. Dashboard shows hundreds; nobody acts.
- No CA policy on user risk. Manual workflow only.
- Auto-dismiss without investigation.
- No SOC integration. Risk events should flow to SIEM.
- Risk thresholds too aggressive — alert fatigue.
- No coverage for service accounts (workload identity risk requires separate features).
Best Practices
- Enable Identity Protection (Entra ID P2).
- CA policy on User Risk = High → require password change (or block + admin remediation).
- CA policy on Sign-in Risk = Medium/High → require MFA / block.
- Stream Identity Protection events to SIEM (Microsoft Sentinel native).
- Define remediation SLAs for SOC.
- Investigate before dismissing any High-risk user.
- Use Sentinel playbooks / Logic Apps to automate response.
- Combine with Continuous Access Evaluation (CAEP) for fast revocation.
- Workload Identities risk features for service principals (separate license).
- Periodic review of dismissed risk decisions.
Risky User Checklist
- Identity Protection enabled and licensed?
- Conditional Access policies on User and Sign-in risk in place?
- Risky users investigated within SLA?
- Risk events streamed to SIEM?
- SOC playbook for risky user response?
- Workload identities risk addressed (where licensed)?
- Quarterly review of dismissals?
- MFA / Conditional Access strong enough to make remediation effective?
How Forestall Helps
Forestall correlates Identity Protection risk with privilege and reachability:
- Risky users with privileged role membership surface first.
- Risky users with paths to Tier 0 are escalated.
- Coverage gaps (privileged users without Identity Protection visibility) flagged.
- Trend data over time.
This focuses limited SOC time on the risky users that matter most.
Frequently Asked Questions
Do I need Entra ID P2 for Risky Users?
Risk reporting and risk-based Conditional Access require Entra ID P2.
Are risky users always compromised?
Not always. Investigate before acting destructively, but treat High risk as likely compromise until proven otherwise.
Can I auto-respond to risky users?
Yes, via Conditional Access (require password change, block) and Sentinel playbooks for additional actions.
Does Identity Protection cover guests?
Some signals do, with limitations based on home tenant data.
What about workload identities?
Workload Identities risk features cover service principal risk (extra license required).
Conclusion
The Risky User dashboard in Microsoft Entra Identity Protection is one of the most valuable signals available to defenders — a real-time, ML-powered view of likely compromise. Treat it like any other high-priority alert: define ownership, automate response with Conditional Access, integrate with SIEM, and never let a high-risk user sit unactioned. Combined with privilege and attack-path context, risky users become an early-warning system instead of an unread inbox.
Don't let risky users sit unactioned.
Forestall correlates Identity Protection risk with privilege and reachability — surfacing the most urgent risky users first.