NOTE: This advisory is based on our evidence from the f11.ca lab experiment (EID-EXP-005), in which we reproduced the issue.
For engineers asking how this works technically.
As an MSP owner, I have observed a recurring pattern in Microsoft 365 environments among SMBs:
- Identity Protection is enabled.
- MFA is enabled
- Alerts are being generated.
Yet, organisations continue to experience security breaches.
Why does this occur?
In many Tenants, the reason is:
Microsoft Entra Identity Protection detects risks but does not enforce remediation unless Conditional Access is properly configured.
This blog is informed by an evidence-based lab published on f11.ca: EID-EXP-005, where I reproduced the issue and validated the solution.
The risk: Detection does not equate to prevention
This is what many businesses unknowingly run today:
Risk detected
Alerts logged
User still signs in
The attacker may still have access
This gap represents the difference between:
- a security notification
and - an actual security control
Why this matters for SMBs: Real-World Impact
Most Microsoft 365 compromises do not initially appear as ransomware incidents.
They usually start with a compromised identity and then escalate into:
1) Business Email Compromise (BEC)
- invoices redirected
- payment details changed
- clients defrauded using your brand
2) Data exposure
- SharePoint document libraries accessed
- OneDrive files copied
- Teams chats reviewed
3) Internal disruption
- users locked out
- password resets across systems
- Leadership email accounts frozen mid-day
The cost: Where the Impact Becomes Significant
When this happens, the bill isn’t just “security clear. "Costs may include:
Direct costs
- emergency incident response hours
- after-hours admin work
- mailbox cleanup (forwarding, rules, OAuth consent)
- endpoint and identity investigation
- Microsoft support escalation
Indirect costs
- downtime for staff
- delayed customer communication
- reputational damage
- lost productivity
- executive involvement
Insurance and compliance risk
Cyber insurers and auditors increasingly expect:
- enforcement controls
- remediation policies
- If your environment only generates alerts, it may not satisfy requirements during an insurance claim or audit.
A common misconception: Passing MFA does not guarantee security
This is one of the most costly assumptions in modern cloud security.
Admins see:
- Risky sign-in detected
- MFA completed
- sign-in succeeds
and assume the issue is resolved.
Attackers succeed through:
- MFA fatigue (push spam)
- social engineering
- token/session theft
- compromised devices
MFA is essential, but it does not confirm legitimacy.
The underlying issue: Identity Protection prioritizes detection over enforcement
Identity Protection is excellent at detecting risk.
However, unless the tenant is configured to enforce remediation, it functions as:
A security dashboard that notifies you of attacks while still permitting access.
This explains why many SMBs possess effective security tools yet still experience breaches.
The solution: Enforce risk remediation using Conditional Access
I recommend implementing the following remediation control as a baseline in any Entra ID P2 tenant:
High User Risk → Require Password Reset.
This ensures that if an account is likely compromised, the following actions occur:
- Access is interrupted
- The user must reset their password.
- Stolen credentials become useless.
- Risk is cleared after remediation.
This is one of the highest ROI identity controls available in Microsoft 365.
Recommended Minimum Baseline
If you are running Microsoft 365, the following controls should be in place:
- High user risk → requires a password reset.
- Medium/high sign-in risk → require MFA.
- Break-glass accounts should be excluded but actively monitored.
- Risky users should be reviewed within a defined SLA, for example, 24 hours.
Final Takeaway from an MSP Owner Perspective
From an MSP perspective, this is one of the most dangerous gaps because it creates false confidence.
The business believes:
“We have alerts, so we’re protected.”
But in reality:
“We have alerts, and the attacker still has access.”
An alert without enforcement serves only as a warning.
Need help validating this in your tenant?
This risk exists in most Microsoft 365 tenants.
Author: Jaspreet Singh
Platform: MSPInsights.ca
Hands-on Evidence & Labs: f11.ca