Microsoft Entra ID Protection
Microsoft Entra ID Protection uses Microsoft's threat intelligence and ML to detect identity
risk (user risk and sign-in risk), automate remediation, and surface a queue of risky users
and sign-ins for investigation. Requires Entra ID P2 to enable risk policies.
When to use
Adding risk-based, adaptive protection on top of Entra ID and Conditional Access. Use this skill
to choose risk thresholds, decide between self-remediation and SOC investigation, and stream
signals to Sentinel.
Do not use this skill for on-prem AD attack detection (defender-for-identity), authoring
plain CA policies (conditional-access-mfa), or PIM activation (azure-pim).
Map the risk signal to the response
| Risk type |
Examples |
Recommended response |
| Sign-in risk (this request) |
Anonymous IP, atypical travel, malware-linked IP, unfamiliar sign-in properties |
Risk-based CA → require MFA |
| User risk (this identity) |
Leaked credentials (TI feeds), Microsoft / partner-reported compromise |
Risk-based CA → require secure password change |
| Both medium+ on same user |
Active session takeover indicators |
Block + force secure password change + analyst review |
Rule of thumb: start risk policies at High threshold, run for 30 days, then expand to
Medium once user registration and remediation flows are proven. Starting at Medium without
SSPR + MFA registration causes lockouts.
Approach
Confirm prerequisites — Entra ID P2 licensing, MFA + SSPR registration enforced for the
target user scope (registration policy in Authentication methods).
Verify: Authentication methods activity report shows > 95% of in-scope users registered
for at least one strong method.
Use risk-based Conditional Access, not legacy built-in risk policies — Author CA
policies with Sign-in risk and User risk conditions. Legacy "User risk policy" /
"Sign-in risk policy" toggles are deprecated in favour of CA.
Verify: no legacy risk policies enabled; risk conditions appear in CA What-If results.
Tier 1 - High risk only — First policy set: High sign-in risk → require MFA; High user
risk → require secure password change. Exclude break-glass accounts from every risk policy.
Verify: report-only for 14 days shows < 5 false positives per 1,000 sign-ins before
enforcing.
Tier 2 - Medium expansion — After 30 days of clean Tier 1 metrics, expand to Medium
sign-in risk → MFA. Don't extend user risk to Medium without an analyst review queue.
Investigate the queue — Triage Risky users, Risky sign-ins, Risk detections
daily. Confirm compromise (forces remediation + trains the model) or dismiss false positives.
Never bulk-dismiss without review - dismisses teach the model wrong signal.
Verify: weekly risky-user queue < 1% of monthly active users in a healthy tenant.
Stream to Sentinel — Diagnostic settings → send RiskyUsers, UserRiskEvents,
RiskyServicePrincipals to a Log Analytics workspace. Correlate with MDI and MDE in
Defender XDR incidents.
Guardrails
- Break-glass accounts excluded from every risk policy. A leaked-credential detection on
the wrong account can lock you out of the tenant.
- MFA + SSPR registration first. Self-remediation only works when users can complete it.
Without registration, risk policies become lockouts.
- Start at High, expand to Medium. Medium thresholds without tuning generate noise and
user friction.
- Don't dismiss bulk false positives. Dismiss = "this was safe" which trains the model.
Use confirm-safe / confirm-compromise deliberately, not as a queue cleanup tool.
- Workload identity risk is separate. Service principals have their own risk detections
- cover them with a parallel policy.
Common anti-patterns
- "Use the legacy User risk / Sign-in risk policy toggles" - Deprecated. Use CA risk
conditions which support broader controls and exclusions.
- "Risk policy on All users at Medium on day one" - Lockout event. Pilot at High first.
- "Bulk-dismiss the risky user queue weekly to clear noise" - Trains the detector
incorrectly and erodes future precision.
- "Risk events stay in Entra portal" - No SOC correlation. Stream to Sentinel and
Defender XDR.
Example prompts
Configure risk-based Conditional Access for sign-in risk and user risk in Entra ID Protection.Set up self-remediation - MFA for sign-in risk, secure password change for user risk.Investigate a user flagged as risky and confirm compromise or dismiss safely.Stream Entra ID Protection risk events to Sentinel for SOC correlation.Why are we getting too many medium-risk alerts - how do I tune?
Microsoft Learn
1---2name: entra-id-protection3description: Guidance for Microsoft Entra ID Protection — risk-based identity security that detects user and sign-in risk and automates remediation. Covers risk detections, risk-based Conditional Access, self-remediation via MFA / secure password change, risky-user investigation, and streaming risk to Sentinel. WHEN: Entra ID Protection, identity risk policy, risky users, risky sign-ins, user risk policy, sign-in risk policy, risk-based Conditional Access, leaked credentials, anonymous IP detection, atypical travel, automate identity remediation, alert about leaked credentials, user flagged as risky, force password reset for compromised accounts, block sign-in when identity risk is high, EID P2 risk policy. DO NOT USE for on-prem AD attack detection (use defender-for-identity), CA policy authoring without risk signals (use conditional-access-mfa), or PIM activation (use azure-pim).4license: MIT5---67# Microsoft Entra ID Protection89Microsoft Entra ID Protection uses Microsoft's threat intelligence and ML to detect identity10risk (user risk and sign-in risk), automate remediation, and surface a queue of risky users11and sign-ins for investigation. Requires **Entra ID P2** to enable risk policies.1213## When to use14Adding risk-based, adaptive protection on top of Entra ID and Conditional Access. Use this skill15to choose risk thresholds, decide between self-remediation and SOC investigation, and stream16signals to Sentinel.1718**Do not use this skill** for on-prem AD attack detection (`defender-for-identity`), authoring19plain CA policies (`conditional-access-mfa`), or PIM activation (`azure-pim`).2021## Map the risk signal to the response2223| Risk type | Examples | Recommended response |24|---|---|---|25| **Sign-in risk** (this request) | Anonymous IP, atypical travel, malware-linked IP, unfamiliar sign-in properties | Risk-based CA → require MFA |26| **User risk** (this identity) | Leaked credentials (TI feeds), Microsoft / partner-reported compromise | Risk-based CA → require secure password change |27| Both medium+ on same user | Active session takeover indicators | Block + force secure password change + analyst review |2829> **Rule of thumb:** start risk policies at **High** threshold, run for 30 days, then expand to30> **Medium** once user registration and remediation flows are proven. Starting at Medium without31> SSPR + MFA registration causes lockouts.3233## Approach34351. **Confirm prerequisites** — Entra ID P2 licensing, MFA + SSPR registration enforced for the36 target user scope (registration policy in Authentication methods).37 *Verify: `Authentication methods activity` report shows > 95% of in-scope users registered38 for at least one strong method.*39402. **Use risk-based Conditional Access, not legacy built-in risk policies** — Author CA41 policies with **Sign-in risk** and **User risk** conditions. Legacy "User risk policy" /42 "Sign-in risk policy" toggles are deprecated in favour of CA.43 *Verify: no legacy risk policies enabled; risk conditions appear in CA What-If results.*44453. **Tier 1 - High risk only** — First policy set: High sign-in risk → require MFA; High user46 risk → require secure password change. Exclude break-glass accounts from every risk policy.47 *Verify: report-only for 14 days shows < 5 false positives per 1,000 sign-ins before48 enforcing.*49504. **Tier 2 - Medium expansion** — After 30 days of clean Tier 1 metrics, expand to Medium51 sign-in risk → MFA. Don't extend user risk to Medium without an analyst review queue.52535. **Investigate the queue** — Triage **Risky users**, **Risky sign-ins**, **Risk detections**54 daily. Confirm compromise (forces remediation + trains the model) or dismiss false positives.55 Never bulk-dismiss without review - dismisses teach the model wrong signal.56 *Verify: weekly risky-user queue < 1% of monthly active users in a healthy tenant.*57586. **Stream to Sentinel** — Diagnostic settings → send `RiskyUsers`, `UserRiskEvents`,59 `RiskyServicePrincipals` to a Log Analytics workspace. Correlate with MDI and MDE in60 Defender XDR incidents.6162## Guardrails63- **Break-glass accounts excluded from every risk policy.** A leaked-credential detection on64 the wrong account can lock you out of the tenant.65- **MFA + SSPR registration first.** Self-remediation only works when users can complete it.66 Without registration, risk policies become lockouts.67- **Start at High, expand to Medium.** Medium thresholds without tuning generate noise and68 user friction.69- **Don't dismiss bulk false positives.** Dismiss = "this was safe" which trains the model.70 Use confirm-safe / confirm-compromise deliberately, not as a queue cleanup tool.71- **Workload identity risk is separate.** Service principals have their own risk detections72 - cover them with a parallel policy.7374## Common anti-patterns75- **"Use the legacy User risk / Sign-in risk policy toggles"** - Deprecated. Use CA risk76 conditions which support broader controls and exclusions.77- **"Risk policy on All users at Medium on day one"** - Lockout event. Pilot at High first.78- **"Bulk-dismiss the risky user queue weekly to clear noise"** - Trains the detector79 incorrectly and erodes future precision.80- **"Risk events stay in Entra portal"** - No SOC correlation. Stream to Sentinel and81 Defender XDR.8283## Example prompts84- `Configure risk-based Conditional Access for sign-in risk and user risk in Entra ID Protection.`85- `Set up self-remediation - MFA for sign-in risk, secure password change for user risk.`86- `Investigate a user flagged as risky and confirm compromise or dismiss safely.`87- `Stream Entra ID Protection risk events to Sentinel for SOC correlation.`88- `Why are we getting too many medium-risk alerts - how do I tune?`8990## Microsoft Learn91- Overview: https://learn.microsoft.com/entra/id-protection/overview-identity-protection92- Risk policies (deprecation note): https://learn.microsoft.com/entra/id-protection/concept-identity-protection-policies93- Risk-based Conditional Access: https://learn.microsoft.com/entra/id-protection/howto-identity-protection-configure-risk-policies94- Investigate risk: https://learn.microsoft.com/entra/id-protection/howto-identity-protection-investigate-risk95- Risk detections reference: https://learn.microsoft.com/entra/id-protection/concept-identity-protection-risks96- Stream to Sentinel: https://learn.microsoft.com/entra/id-protection/howto-export-risk-data
vinayaklatthe