Identity Protection

Microsoft Entra ID Identity Protection is the risk-detection engine that evaluates every sign-in and user account for compromise. It generates two kinds of risk signal: sign-in risk (this specific sign-in looks suspicious — impossible travel, anonymous IP, malware-linked IP) and user risk (this user's account is compromised — credentials found in known breaches, ongoing leaked-credential signals). Risk levels feed into Conditional Access policies that can block sign-in, require MFA, or force password reset. Available on Entra ID P2 and Microsoft 365 E5. Pairs naturally with Defender for Identity for on-premises identity risk.

Sign-in risk vs user risk

The distinction matters because the right response differs. Sign-in risk is about a single event: this particular attempt has characteristics (impossible travel — a sign-in from a location that couldn't be physically reached given a prior sign-in's time and place; an anonymous IP like a known VPN or Tor exit node; a token that matches a known malware-linked pattern) that make it look suspicious, independent of whether the account itself is otherwise fine. User risk is about the account over time: leaked-credential feeds (Microsoft continuously matches known breach dumps against tenant usernames), a pattern of risky sign-ins, or confirmed compromise from an admin or Microsoft security investigation. A single risky sign-in might just need a step-up MFA challenge to resolve; an elevated user risk score usually should force a password reset, because it implies the credential itself, not just one session, may be compromised.

Worked example

A user's laptop is used from Stockholm at 9am, and Identity Protection then sees a sign-in attempt from an IP that geolocates to Southeast Asia at 9:20am — twenty minutes apart, a distance that requires an eight-hour flight at minimum. That's flagged as impossible travel, a sign-in risk signal. A Conditional Access policy scoped to "sign-in risk: medium and above" can respond by requiring MFA before allowing the sign-in through — if it's really the legitimate user on a fast VPN switch or corporate proxy hairpin, they pass the MFA challenge and continue; if it's an attacker using stolen session cookies from a different continent, they're stopped at the MFA step they can't complete. Separately, if that same username later shows up in a leaked-credential feed from an unrelated breach, Identity Protection raises user risk for the account regardless of any individual sign-in looking normal, and a user-risk Conditional Access policy can force a password reset the next time they sign in — closing the door on the leaked password being reused here.

Feeding Conditional Access

Identity Protection doesn't act on its own — its risk scores are signals that Conditional Access policies consume. The standard pattern is two policies: one on sign-in risk (typically: medium or high risk requires MFA) and one on user risk (typically: high risk requires a secure password change). Both are Microsoft-recommended template policies in the Conditional Access template gallery, aimed specifically at making this pairing easy to deploy without hand-building the conditions.

Common pitfalls

Identity Protection risk detections need investigation, not just automated response — a tenant that only ever auto-remediates via Conditional Access and never reviews the underlying risk detections report loses the ability to spot patterns (a specific department being targeted, a specific country's traffic spiking) that would otherwise inform broader defensive changes. It's also worth knowing that risk state persists per user until explicitly dismissed or remediated — a user who completes a forced password reset has their risk cleared, but an admin manually dismissing a risk detection without the user actually changing anything leaves the underlying exposure unaddressed.