Static Conditional Access policies evaluate fixed conditions — device, location, application — every time, the same way. Entra ID Protection adds a dynamic layer: continuously evaluated risk signals that feed directly into Conditional Access, letting policy respond to a sign-in or user that looks anomalous, not just one that fails a fixed rule.
User risk vs. sign-in risk
Entra ID Protection evaluates two distinct kinds of risk:
| Risk Type | What It Evaluates | Example Trigger |
|---|---|---|
| User risk | The likelihood that a specific user's credentials have been compromised, evaluated over time | Credentials found in a leaked-credential dataset; anomalous activity pattern |
| Sign-in risk | The likelihood that a specific sign-in attempt itself is not the legitimate user | Impossible travel, anonymous IP address, unfamiliar sign-in properties |
A user can have elevated user risk without any single risky sign-in (a credential appeared in a breach dump, even if no attacker has used it yet), and a sign-in can be flagged as risky without the user's overall risk being elevated (a one-off anomalous but ultimately legitimate travel pattern). Policies typically respond to both independently.
Automated response policies
Entra ID Protection's value comes from risk-based Conditional Access policies that respond automatically, rather than requiring an administrator to manually review every flagged event in real time:
- User risk policy — for example, require a secure password change when user risk is elevated, automatically prompting remediation without administrator intervention.
- Sign-in risk policy — for example, require MFA when sign-in risk is medium or above, or block access outright when risk is high.
This extends, not replaces, standard Conditional Access
Risk-based policies are built using the same Conditional Access policy engine covered in Microsoft Entra Conditional Access: A Practical Guide — risk level is simply one more condition, evaluated alongside device, location, and application, not a separate system.
Tuning to avoid alert fatigue
A common early-adoption problem is enabling risk-based policies at their most sensitive setting and generating enough false positives that administrators start ignoring — or worse, broadly excluding users from — the resulting alerts, defeating the purpose.
- Start risk-based policies in Report-only mode, exactly as recommended for any new Conditional Access policy, to see real-world risk detection volume before enforcing.
- Begin with "high" risk thresholds for blocking actions, reserving "medium" thresholds for lower-friction responses (MFA challenge) rather than an outright block.
- Review dismissed/false-positive risk detections periodically to identify whether a specific detection type is producing disproportionate noise for your environment, and adjust accordingly.
- Don't broadly exclude users from risk policies to silence noise — this defeats the control; instead, tune the specific trigger causing the noise.
Common mistakes
- Enabling risk-based blocking policies without Report-only testing first, risking unexpected legitimate-user lockouts.
- Ignoring or auto-dismissing risk detections without review, missing early warning signs of actual credential compromise.
- Broadly excluding frequently-flagged users from risk policies instead of investigating why they're triggering detections repeatedly (a legitimate travel pattern vs. an actual compromise).
- Not pairing user-risk remediation (secure password change) with a check for compromised MFA methods, since a password change alone doesn't address a scenario where MFA itself has also been compromised.
FAQ
What license does Entra ID Protection require? Entra ID P2 — this is one of the capabilities specifically gated behind the higher licensing tier discussed in Microsoft Entra ID Overview.
How is this different from Conditional Access sign-in risk conditions in general? Entra ID Protection is the underlying risk-detection engine; risk-based Conditional Access policies are how that risk data is acted upon. They're part of the same system, not two separate products.
Can Entra ID Protection detect a compromised account before any risky sign-in occurs? Yes, partially — user risk can be elevated based on external signals (leaked credential datasets) independent of observing a risky sign-in attempt from that account, which is why the two risk types are evaluated and can be acted on separately.
Does this replace the need for a SIEM or dedicated security monitoring? No — Entra ID Protection is identity-specific risk detection, not a general security information and event management platform. It's a valuable signal source that a broader security monitoring function should incorporate, not a replacement for one.