SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsentra-id-protection

entra-id-protection

Security & auditing

View repository

Updated 10-16 01:12

About this skill

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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