Home / Defender XDR / Entra ID Protection
🛡️

Microsoft Entra ID Protection

Cloud identity risk detection, risky sign-in policies, and automated remediation

What is Entra ID Protection?

Uses Microsoft's position across consumer and enterprise identities to detect identity-based risks. Automate detection of risky sign-ins, leaked credentials, and suspicious behaviour with Conditional Access integration.

Core Capabilities

Entra ID Protection Labs

Configure risk-based policies, investigate risky users and sign-ins, and integrate identity risk signals with Defender XDR.

Entra ID Scripts

Ready-to-run PowerShell scripts for lab simulations. View all scripts →

ScriptDescriptionLevelParameters
Invoke-EntraRiskAssessment.ps16-phase identity posture: risky users, CA audit, MFA, legacy auth, dashboardsIntermediate-Action [Assess|RiskyUsers|CAPolicies|LegacyAuth|Report]
Invoke-EntraRiskSimulation.ps1Risk policy validation: verify CA enforcement, sign-in risk checksIntermediate-Scenario [VerifyPolicies|CheckSignIns|ReviewDetections]

Entra ID Protection Resources

Entra ID Protection FAQ

What identity risks does Entra ID Protection detect?

Entra ID Protection uses Microsoft's position across billions of daily authentications to detect identity-based risks in two categories:

Sign-in risk (real-time):

  • Anonymous IP address (Tor, VPN anonymisers)
  • Atypical travel (impossible travel between locations)
  • Malware-linked IP address
  • Unfamiliar sign-in properties (unusual browser, OS, location for the user)
  • Password spray (same password tried across many accounts)
  • Token issuer anomaly (abnormal token issuer characteristics)

User risk (offline):

  • Leaked credentials (username/password pairs found in dark web dumps)
  • Azure AD threat intelligence (Microsoft-identified compromised accounts)
  • Anomalous user activity (unusual volume or pattern of activity)
  • Suspicious API traffic (unusual application access patterns)
  • Suspicious inbox manipulation rules (forwarding rules indicating BEC)

Each detection has a risk level (low, medium, high) and contributes to the user's aggregate risk state. Risk levels directly drive Conditional Access enforcement.

Risk detections

What is the difference between sign-in risk and user risk?

These two risk types serve different purposes and require different response strategies:

  • Sign-in risk: Evaluated in real time during each authentication attempt. It reflects the probability that the specific sign-in is not performed by the legitimate account owner. Example: a sign-in from an anonymous IP is suspicious regardless of the user's history. Sign-in risk triggers immediate enforcement (MFA challenge, block).
  • User risk: Calculated offline and represents the cumulative likelihood that a user's identity has been compromised. It persists until remediated (password reset, admin dismiss). Example: if a user's credentials appear in a public data breach, their user risk stays high until they change their password.

Key difference in CA policies:

  • Sign-in risk policies should require MFA for medium risk and block for high risk
  • User risk policies should require password change + MFA for high risk (self-service remediation)

Risk policies

What licensing is required for Entra ID Protection?

Entra ID Protection features are tied to Entra ID licence tiers:

  • Entra ID Free / Microsoft 365 E3: Basic sign-in logs and user sign-in risk detection (limited). No Conditional Access risk-based policies.
  • Entra ID P1 (included in M365 E3): Conditional Access policies (not risk-based). Can create location-based, device-based, and app-based policies. Cannot use risk as a condition.
  • Entra ID P2 (included in M365 E5, EMS E5): Full Entra ID Protection: all risk detections, risk-based Conditional Access policies (sign-in risk and user risk conditions), risky users/sign-ins reports, risk investigation dashboard, vulnerability report, and automated remediation.

For risk-based security, Entra ID P2 is required. This is the most frequently misunderstood licensing requirement; many organisations have E3 (P1) and discover they cannot create risk-based CA policies.

Entra ID Protection overview

How do risk-based Conditional Access policies work?

Risk-based CA policies use Entra ID Protection's risk signals as real-time conditions for access decisions:

  1. User authenticates: The user provides credentials (password, biometric, etc.)
  2. Risk evaluation: Entra ID Protection evaluates the sign-in against known risk indicators (IP reputation, location, device, behaviour patterns)
  3. Policy matching: CA policies are evaluated in order. If the sign-in matches a risk-based policy (e.g., "sign-in risk = high"), the policy's controls are enforced.
  4. Enforcement: Depending on the policy, the user may be required to complete MFA, change their password, or be blocked entirely
  5. Self-remediation: For user risk policies requiring password change, the user is redirected to SSPR (Self-Service Password Reset) after MFA verification, automatically lowering their risk after compliance

Recommended policy set: Block high sign-in risk, require MFA for medium sign-in risk, require password change + MFA for high user risk. Always exclude break-glass emergency access accounts from all risk policies.

Risk-based CA policies

How does Entra ID Protection integrate with Defender XDR?

Entra ID Protection's identity risk signals flow directly into the Defender XDR unified incident pipeline, providing identity context for cross-product investigations:

  • Alert correlation: A risky sign-in detection from Entra ID is automatically correlated with related MDE endpoint alerts, MDO email alerts, and MDA cloud app alerts into a single unified incident
  • User entity page: The Defender portal's user page shows identity risk level, recent risky sign-ins, risk history, and all Entra ID Protection detections alongside endpoint and email activity
  • Advanced hunting: Identity logon data is available in AADSignInEventsBeta for KQL-based hunting that correlates identity risk with endpoint, email, and cloud app telemetry
  • Automated response: Defender XDR's AIR can automatically disable user accounts, revoke sessions, and require password reset when identity compromise is confirmed as part of a broader incident

This integration is critical: identity compromise is the initial access vector in 80%+ of breaches. Without Entra ID Protection signals in XDR, the SOC team misses the identity phase of the attack chain.

Investigate risk

How do I block legacy authentication?

Legacy authentication protocols (POP3, IMAP, SMTP, ActiveSync with basic auth, MAPI over HTTP) are the most exploited identity attack vector because they cannot enforce MFA:

  • Why block: An attacker with a user's password can bypass MFA entirely by authenticating via IMAP or POP3. Password spray attacks specifically target legacy protocols.
  • CA policy to block: Create a Conditional Access policy: Users = All users (exclude break-glass), Client apps = Exchange ActiveSync clients and Other clients, Grant = Block access
  • Migration steps: Before blocking, use the Entra ID sign-in logs to identify users and apps still using legacy auth. Migrate them to modern authentication (OAuth 2.0) before enabling the block policy.
  • Report-only first: Deploy the block policy in Report-only mode for 2–4 weeks to identify impact before enforcing

Blocking legacy authentication is recommended by Microsoft, CIS benchmarks, and every identity security framework. It is typically the single highest-impact identity security improvement an organisation can make.

Block legacy authentication

← Back to Defender XDR