mcpField
E
entra-id-protection

entra-id-protection

github.com/vinayaklattheSecurity17885 installsUpdated 19w ago
Repository

About entra-id-protection

A Microsoft Entra ID Protection skill for security teams, covering responses to sign-in and user risk, investigations, and streaming signals to Sentinel. It helps align risk detection with Conditional Access and SOC workflows.

Key features

  1. 01Plan risk-based Conditional Access
  2. 02Set risk thresholds and responses
  3. 03Investigate risky users and sign-ins
  4. 04Stream risk events to Sentinel

Use cases

  1. 01Require MFA for high-risk sign-ins
  2. 02Require secure password changes for high-risk users
  3. 03Investigate and remediate risky users
  4. 04Bring risk events into Sentinel SOC analysis

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-id-protection

After installing, type/entra-id-protectionin Claude Code to confirm it loaded.

Details

From the project README

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 typeExamplesRecommended response
Sign-in risk (this request)Anonymous IP, atypical travel, malware-linked IP, unfamiliar sign-in propertiesRisk-based CA → require MFA
User risk (this identity)Leaked credentials (TI feeds), Microsoft / partner-reported compromiseRisk-based CA → require secure password change
Both medium+ on same userActive session takeover indicatorsBlock + 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

Comments

Markdown supported