Microsoft Entra Identity Protection is a valuable security feature in Microsoft 365, yet it is often misunderstood.
Many organizations assume:
“If Identity Protection detects a risky sign-in, it will stop the attacker.
”In practice, Identity Protection primarily detects risk. It generates signals and alerts, but does not reliably enforce remediation unless risk-based Conditional Access is configured.
This technical deep dive is based on an evidence-driven home lab published on f11.ca: EID-EXP-005 — Enforcing Risk Remediation with Conditional Access Policies.
The real-world problem: alerts without enforcement
In many environments, the security posture appears strong on paper:
- MFA is enabled
- Identity Protection is licensed (Entra ID P2)
- Risky sign-ins are detected.
- Risky users appear in the portal.
However, access is still permitted.
This creates a significant security risk: Risk detected
Alerts visible
No remediation enforced
User continues normal access
This is a primary reason Microsoft 365 compromises continue to occur, even in environments considered secure. (Pro, 2025)
What EID-EXP-005 proved (with portal evidence)
In EID-EXP-005, the following sequence was reproduced:
- A test user signs in normally (baseline)
- A risky sign-in is triggered using a VPN (unexpected country)
- Identity Protection detects the event.
- MFA is prompted
- MFA is completed successfully
- The sign-in succeeds
- The user becomes marked as “At risk”
- The user can still sign in again from a safe location.
The key issue is not a failure of Identity Protection.
The key point is:
Identity Protection accurately detected the risk, but no policy responded to it (What is Microsoft Entra ID Protection?, 2023).
The most important concept: Sign-in risk vs User risk
Many administrators overlook this distinction.
Sign-in risk
Sign-in risk answers:
“Was this specific authentication attempt suspicious?
”It’s tied to one sign-in event.
Sign-in risk is often marked as “resolved” once MFA is completed.
User risk
User risk answers:
“Is this identity likely compromised?
”This risk is persistent and may remain active for hours, days, or weeks until remediation occurs.
This risk signal should prompt the strongest enforcement actions.
Why MFA success does not mean “safe.”
A common admin response to risky sign-ins is:
“MFA passed, so it’s probably fine.”
But attackers frequently bypass MFA using:
- MFA fatigue / push spam
- social engineering
- compromised devices
- token theft
- previously trusted sessions
MFA is a strong control, but it does not guarantee the user’s legitimacy. (Combat impersonation using Face Check with Microsoft Entra Verified ID, 2024)This is exactly why user risk exists as a separate signal.
The enforcement gap: lack of Conditional Access policies for risk
In EID-EXP-005, the tenant had:
- Identity Protection enabled
- P2 licensing
- MFA registered
- Risky sign-ins detected
- Risky user flagged
But there were no Conditional Access policies configured for:
- user risk
- sign-in risk
As a result, risk signals were visible in the portal but did not affect authentication outcomes.
This situation results in “alert-only security.”
The fix: enforce remediation with risk-based Conditional Access
The core remediation in EID-EXP-005 was a single policy:
High user risk → requires a password change.
Policy name:
CA – High User Risk – Require Password Change
Users
- Include: All users
- Exclude: break-glass accounts.
Conditions
- User risk: High
Grant
- Grant access
- Require password change
This policy immediately changes the security outcome:
- A high-risk identity cannot continue operating.
- The user must reset their password.
- Stolen credentials become useless.
- Identity Protection risk state clears after remediation.
This is among the highest ROI Conditional Access policies available in Entra. (Nechaeva, 2025)
Why “require password change” is often better than “block.”
Some organizations choose to block high-risk users. Blocking works, but it creates common operational issues:
- The user cannot self-remediate
- Helpdesk becomes the bottleneck.
- Risky users remain unresolved longer.
Requiring a password change typically offers a better balance:
- The user can remediate quickly.
- Compromise is neutralized
- Business disruption is minimized.
What “good” looks like after enforcement
Before enforcement:
- Risky sign-in detected
- MFA completed
- sign-in succeeds
- user remains risky
- access continues
After enforcement:
- Risky sign-in detected
- user risk escalates
- sign-in triggers password reset
- Risk clears after remediation.
- The attacker loses access.
This is the security outcome most organizations expect, but it only occurs when Conditional Access is configured correctly.
Conclusion
EID-EXP-005 confirms a critical Entra security reality:
Identity Protection detects risk.
Conditional Access enforces remediation.
If your tenant only generates Identity Protection alerts, you may remain vulnerable to account compromise, even with MFA enabled.
To close the gap, implement:
- High user risk → requires a password reset.
- Medium/High sign-in risk → require MFA.
- break-glass exclusions + monitoring
Key takeaway:
Detection finds the attacker. Enforcement removes them.
Related Evidence & Guidance
About the Author
Author: Jaspreet Singh
Platform: ITBlogs.ca
Hands-on Evidence & Labs: f11.ca