Identity Protection Alerts Often Overlooked: Why Detection Alone Does Not Prevent Compromise in Microsoft Entra ID
Many view Microsoft Entra ID Identity Protection as a security feature designed to block attackers.
NOTE: This analysis is based on real tenant observations and controlled experiments documented on f11.ca (Experiment ID: EID-EXP-004).
In practice, it functions primarily as a risk-detection engine. Without appropriate Conditional Access enforcement, the system may generate alerts while attackers continue to operate without interruption. This analysis will cover:
- What Identity Protection actually does (and doesn’t)
- Why admins ignore the alerts
- Why MFA success is not proof of safety
- The most common enforcement gap
- What policies actually fix the key point: Identity Protection does not provide default protection.
Identity Protection detects and reports risk events such as:
- Anonymous IP sign-ins (TOR, proxies, VPN)
- Atypical travel / impossible travel
- Password spray / credential stuffing patterns
- Suspicious sign-in properties
- Leaked credentials
These detections are valuable, but there is a significant limitation:
Identity Protection may detect risk but still allow users to sign in.
Many admins assume:
- “If risk is detected, access is blocked.”
- “If MFA is required, the attack is stopped.”
Neither outcome is guaranteed.
Reasons administrators may ignore Identity Protection alerts
Most ignored alerts fall into two buckets:
1) Risky sign-ins
Admins open the event and see:
- Risk level: Medium
- Risk state: Resolved
Then they conclude:
“The user passed MFA. This is fine.”
2) Risky users
This scenario poses a greater risk can be flagged as:
- User risk: Medium / High
- Risk state: At risk
However, without enforcement policies, the user continues to operate normally, and the alert does not become urgent.
No helpdesk ticket.
No outage.
No screaming user.
The result is a compromised identity.
The misunderstanding: Sign-in Risk vs User Risk
This This represents the most significant conceptual gap in risk.
Sign-in risk is session-based.
It answers:
“Was this sign-in suspicious?”
It’s tied to an authentication event. If the user passes MFA, the sign-in is often considered resolved from a session perspective.
User risk
User risk is identity-based.
It answers:
“Is this account likely compromised?”
This risk is persistent and may remain for hours, days, or weeks until remediation occurs.
Common failure mode: Treating 'MFA passed' as the stop condition
Here’s what the real-world flow looks like:
- Attacker steals credentials
- Attacker signs in from a risky network
- Identity Protection detects risk.
- MFA prompt is triggered
- MFA is approved (fatigue, push bombing, social engineering)
- Sign-in succeeds
- Admin sees an alert
- Admin does nothing because “MFA passed.”
- Attacker continues accessing resources.
This scenario is not hypothetical. his is exactly how many M365 compromises happen today.
Why Secure Score doesn’t catch this gap
Secure Score can show:
- MFA enabled
- Security defaults disabled (because CA is used)
- Identity Protection enabled
But Secure Score does not reliably force or validate that:
- High user risk triggers a password reset.
- Risky users are remediated within an SLA
- Alerts translate into access control outcomes.
This situation introduces significant risk:
The tenant may appear secure, but identity compromise can persist.
The technical reason alerts don’t block access
Identity Protection is fundamentally two parts:
1) Risk detection and reporting
- Risky sign-ins report
- Risky users report
- Risk detections report
2) Risk-based policy enforcement
This is done using:
- Conditional Access policies using User Risk and Sign-in Risk
- Identity Protection risk policies (older model, still seen in some tenants)
In the absence of enforcement, the system detects risk but does not require remediation.
Why this matters for MSPs and SMB tenants
In SMB environments, the typical setup is:
- One global admin
- MFA enabled
- No dedicated SOC
- Alerts sent to email nobody reads.
This is exactly the environment attackers love.
MSPs should treat Identity Protection as:
A detection system that requires enforcement and operational processes.
Not a magic “turn it on and you’re safe” feature.
Key takeaway
Identity Protection is valuable — but only if you turn detection into action. An alert without enforcement is just a warning label.
Related Evidence & Guidance
About the Author
Author: Jaspreet Singh
Platform: ITBlogs.ca
Hands-on Evidence & Labs: f11.ca