8.1 User Risk & Sign-in Risk
Key Takeaways
- Microsoft Entra ID Protection calculates two separate scores: user risk (likelihood the identity is compromised) and sign-in risk (likelihood a specific authentication is not legitimate).
- Risk levels—Low, Medium, High (and None/Hidden depending on view)—drive risk-based Conditional Access policies such as require MFA, require password change, or block access.
- Investigate risky users and risky sign-ins in the Entra admin center or Microsoft Graph; confirm compromised, confirm safe, or dismiss user risk based on evidence—not guesswork.
- Self-remediation (for example secure password change after MFA) can clear risk when policies allow it; admin confirm/dismiss remains required when the account is still under attacker control or evidence is conclusive.
- ID Protection detections (impossible travel, anonymous IP, atypical travel, malware-linked IP, password spray, leaked credentials, and others) are inputs to risk—not standalone policies you invent per detection name.
Why Identity Protection matters on SC-300
Domain 2—Implement authentication and access management—expects you to protect identities with more than static MFA. Microsoft Entra ID Protection (historically Azure AD Identity Protection) continuously evaluates signals about users and individual sign-ins, produces risk, and lets you respond with investigation tools and Conditional Access.
SC-300 identity admins must:
- Explain user risk versus sign-in risk.
- Choose risk-based Conditional Access controls that match organizational tolerance.
- Investigate risky users and risky sign-ins using reports and detections.
- Remediate—self-service secure change, force password reset, block, confirm compromised, dismiss risk—correctly for the scenario.
Licensing note at exam depth: risk-based Conditional Access and full ID Protection reporting typically require Microsoft Entra ID P2 (or suites that include it, such as Microsoft 365 E5). When a stem emphasizes P2 and automated risk response, ID Protection + CA is the intended design—not Security defaults alone.
User risk versus sign-in risk
These are different calculations. Mixing them is a classic exam trap.
| Dimension | User risk | Sign-in risk |
|---|---|---|
| Question answered | How likely is this identity compromised? | How likely is this authentication attempt illegitimate? |
| Scope | Accumulates across signals for the user object | Evaluated for a single sign-in event |
| Typical drivers | Leaked credentials, anomalous patterns, confirmed compromise history, aggregate detections | Impossible travel, anonymous IP, unfamiliar features, malware-linked IP, token anomalies, atypical properties of this attempt |
| Policy examples | Require password change; block user until remediated; force re-registration flows | Require MFA for medium/high sign-in risk; block high sign-in risk |
| Remediation focus | Clean the account (password, sessions, methods, admin confirm) | Challenge or block this attempt; may feed user risk over time |
User risk is sticky: a user can sit at High until something remediates or an admin dismisses/confirms. Sign-in risk is per attempt: one sign-in can be High while the user’s overall risk is still Medium, and the next legitimate sign-in can be Low.
Mental model:
- Sign-in risk → “Should we trust this session request right now?”
- User risk → “Is the credential identity itself believed compromised?”
Risk levels
ID Protection surfaces risk with levels you use in reports and Conditional Access conditions:
| Level | Operational meaning (exam-level) |
|---|---|
| High | Strong indication of compromise or highly suspicious attempt; often block or force strong remediation |
| Medium | Elevated concern; commonly require MFA and/or password change depending on policy design |
| Low | Some anomalous signal; many orgs allow with MFA or monitor without hard block |
| None / no risk | No elevated risk detected for that entity/event |
Policies can target High, Medium and above, or Low and above depending on how aggressive you want enforcement. SC-300 design answers usually:
- High user risk → require password change (and MFA where needed) or block until admin investigation.
- Medium or high sign-in risk → require MFA (or authentication strength).
- High sign-in risk alone → some orgs block (especially for privileged apps).
Do not invent custom “critical” levels; stick to Microsoft’s risk vocabulary.
Risk detections (inputs, not the policy)
You will see named detections in the portal. Know them as signals that contribute to risk, not as separate products.
| Detection family (examples) | Typically influences |
|---|---|
| Leaked credentials (found in dark web / breach dumps correlated by Microsoft) | User risk strongly |
| Anonymous IP address (Tor, anonymizers) | Sign-in risk |
| Atypical travel / impossible travel | Sign-in risk (and may raise user concern) |
| Unfamiliar sign-in properties | Sign-in risk |
| Malware-linked IP address | Sign-in risk |
| Password spray / credential stuffing patterns | Sign-in and/or user risk depending on correlation |
| Admin-confirmed compromised user | User risk (confirmed state) |
| Anomalous token / session anomalies (as Microsoft evolves detections) | Sign-in / session confidence |
Exam stems rarely require memorizing every detection string. They require: “leaked password found for the user” → user risk / password remediation; “sign-in from anonymizing proxy” → sign-in risk / MFA or block.
Risk-based Conditional Access
Modern enforcement uses Conditional Access conditions:
- User risk condition (levels)
- Sign-in risk condition (levels)
Combined with grant controls:
| Goal | Typical CA design |
|---|---|
| Stop silent use of stolen passwords | Sign-in risk medium+ → Require MFA |
| Force cleanup of compromised identities | User risk high → Require password change (often with MFA already satisfied) |
| Deny when confidence is too low | Sign-in risk high → Block access for sensitive apps |
| Protect Tier-0 | Stricter levels + phishing-resistant authentication strength + device compliance |
Recommended enterprise pattern (SC-300 style):
- Deploy authentication methods and drive registration first (see section 8.2 and earlier MFA chapters).
- Create report-only risk policies; review impact in What If / Insights and ID Protection reports.
- Pilot on non-break-glass groups; exclude carefully monitored emergency accounts per your CA design.
- Move to on for production; pair with investigation runbooks.
- For hybrid users, ensure password writeback if cloud password change must update on-premises AD (otherwise remediation fails operationally).
Exam distinction: Security defaults are not fine-grained risk policies. If the stem wants “require MFA only when sign-in risk is medium or high,” answer Conditional Access with sign-in risk condition, which needs ID Protection/P2 capabilities—not Security defaults.
Legacy ID Protection user/sign-in risk policies blades historically existed as product-native policies; Microsoft’s direction emphasizes Conditional Access as the control plane. On the exam, prefer CA risk conditions for modern design answers unless the stem explicitly points at a legacy policy surface.
Investigate risky users and risky sign-ins
Admin workflow lives under Microsoft Entra admin center Protection > Identity Protection (labels evolve):
| Report / blade | Use it to |
|---|---|
| Risky users | See users with elevated user risk, risk level, risk detail, last update |
| Risky sign-ins | See individual authentications with sign-in risk, detection reasons, location, app, client |
| Risk detections | Drill into raw detection events feeding scores |
| Sign-in logs (Entra monitoring) | Correlate IP, device, CA result, failure reasons alongside risk |
Investigation checklist for a risky user:
- Open the user → review risk history and contributing detections.
- Review recent risky sign-ins and normal sign-in logs (geo, ASN, device ID, legacy vs modern auth).
- Check whether MFA was satisfied, interrupted, or failed (push bombing, MFA fatigue).
- Determine business context (travel, VPN, new laptop, shared kiosk).
- Decide remediation path (below).
- Document for SOC handoff if your org splits identity ops and security ops.
Investigation checklist for a risky sign-in:
- Was the attempt blocked by CA already, or did it succeed?
- Which detections fired (anonymous IP vs impossible travel vs leaked creds correlation)?
- Is the device compliant/known? Hybrid joined? Token claims anomalous?
- Does the same user show a rising user risk trend?
- If successful and malicious: block sign-in, revoke sessions, reset credentials/methods, then mark confirm compromised if confirmed.
Remediation: self-remediation versus admin actions
Self-remediation
When policies allow, users can self-remediate risk by completing a secure action:
| Self-remediation path | What it typically clears / reduces |
|---|---|
| Complete MFA challenge on a risky sign-in | Allows the legitimate user through; improves confidence in that attempt |
| Secure password change after strong auth (policy-required) | Addresses user risk driven by credential exposure when the real user can still prove MFA |
| Re-register methods after admin/TAP recovery | Restores healthy authentication posture post-incident |
Self-remediation only works if the legitimate user still controls a strong factor. If the attacker has the password and the MFA method (SIM swap, stolen phone, session cookie), self-service is insufficient—use admin containment.
Admin remediation and risk disposition
| Admin action | When to use |
|---|---|
| Block sign-in | Active compromise; stop new auth immediately |
| Revoke sessions / invalidate refresh tokens | Token theft or post-compromise session kill |
| Reset password / expire password | Credential theft; pair with writeback for hybrid |
| Revoke MFA sessions / require re-register | Authenticator or phone factor may be attacker-controlled |
| Confirm user compromised | Evidence shows real compromise; elevates response and risk state handling |
| Confirm sign-in compromised (where available) | Specific authentication confirmed malicious |
| Dismiss user risk | Investigation shows false positive (known travel, corporate VPN egress misclassified, etc.) |
| Confirm safe on a sign-in (where offered) | This attempt was legitimate; helps feedback loops |
Confirm compromised is not cosmetic: it signals Microsoft and your operational process that the identity was attacked, drives appropriate risk treatment, and should pair with hard containment (block, revoke, reset, method hygiene). Dismiss user risk is for false positives after investigation—not for “we are too busy to look.”
Decision tree (memorize for stems)
- Attack still possible? → Block + revoke sessions first.
- User is legitimate and can MFA? → Prefer policy-driven password change / self-remediation for credential user risk.
- User cannot prove identity or attacker has MFA? → Admin reset, TAP after out-of-band proofing, re-register methods; confirm compromised if proven.
- No compromise, noisy detection? → Dismiss user risk / confirm sign-in safe; tune CA aggressiveness if systemic.
- Hybrid? → Ensure on-premises disable/password writeback as needed so remediation is authoritative everywhere.
Putting investigation and CA together
Example enterprise package:
- CA policy A: Sign-in risk ≥ Medium → Require MFA for all users, all cloud apps (exclude break-glass carefully).
- CA policy B: User risk = High → Require password change (+ MFA).
- CA policy C: Sign-in risk = High on admin portals → Block or require phishing-resistant strength + compliant device.
- Weekly review of Risky users report; SLA to investigate High within hours.
- Incident runbook: block → revoke → reset → confirm compromised → re-enable only after clean registration.
Common SC-300 traps
- Treating user risk and sign-in risk as synonyms.
- Answering Security defaults for granular risk-based MFA.
- Dismissing risk without investigation when the stem shows leaked credentials.
- Requiring password change for high sign-in risk when the better control is MFA/block for that attempt.
- Forgetting revoke sessions after confirming compromise.
- Ignoring password writeback so cloud remediation never fixes hybrid logons.
Microsoft reports that a user's password appears in a leaked credentials dump, elevating the identity's overall compromise likelihood. Which ID Protection concept does this primarily raise?
You need medium or high sign-in risk attempts to complete multifactor authentication before accessing Microsoft 365. What is the modern control to implement?
Investigation proves a risky user account was taken over by an attacker who may still hold refresh tokens. Besides resetting credentials, which admin pair is most appropriate?
When should an identity admin dismiss user risk rather than confirm the user compromised?