NOTE: This analysis is based on real tenant observations and controlled experiments documented on f11.ca (Experiment ID: EID-EXP-007).
Most Microsoft Entra tenants detect risky sign-ins.
However, it is important to recognize the following:
Detection alone does not prevent incidents.
If a sign-in is flagged as high risk and the user still gains access to Microsoft 365, effective identity security is not in place.
This scenario represents a well-documented breach.
In this analysis, I will explain what high sign-in risk means, its significance, how Conditional Access functions, and how to implement an effective control that automatically blocks the most serious sign-in attempts.
The Core Issue: Most Tenants Treat Risk as Merely Logging
Microsoft gives us Identity Protection signals.
And those signals are good.
But many tenants do one of the following:
- Leave Identity Protection enabled, but never enforce it.
- Keep Conditional Access policies in Report-only forever.
- configure policies but apply them incorrectly
- confuse User risk with Sign-in risk
- apply policies too broadly and then roll them back after a lockout
The outcome is therefore predictable:
risk detected
no enforcement
Compromise still occurs
Many administrators assume that “high sign-in risk” means:
The user is probably compromised.
This assumption is not always accurate.
Sign-in risk is scoped to one sign-in event.
In reality, it means:
“This sign-in attempt has strong indicators of being malicious.”
That could include:
- password spray attempts (high confidence)
- known bad IP reputation
- sign-in from anonymizing infrastructure
- suspicious token activity
- abnormal patterns Microsoft has high confidence in
Risk levels
Microsoft generally classifies sign-in risk as:
- Low
- Medium
- High
This classification is valuable because it provides a high-confidence input for Conditional Access.
User Risk vs Sign-in Risk (Most Tenants Get This Wrong)
A straightforward way to distinguish them is as follows:
Sign-in risk
This sign-in looks suspicious.
The decision is made per event.
User risk
This identity is likely compromised.
Decision follows the user, not the event.
In real-world security architecture:
In practical security architecture:
- User risk is used to enforce remediation..
Why Blocking High Sign-in Risk Is Among the Most Effective Conditional Access Policies.
This policy is one of the rare Conditional Access policies that is:
simple
low-maintenance
high signal
high security impact
easy to explain to leadership
audit-friendly
This policy helps prevent the most serious identity-related incidents, including:
- credential stuffing that actually succeeds
- The attacker signs in from a known malicious infrastructure.
- session abuse patterns
The Control: Conditional Access + Sign-in Risk = High → Block Access
This is the exact control implemented in EID-EXP-007.
Policy logic
If Sign-in risk = High
Then Block Access
That’s it.
No complicated device logic.
No hybrid join dependencies.
No MFA registration problems.
This provides a clear and immediate block on the most suspicious sign-ins.
Implementation Notes (The Real-World Version)
The following steps are particularly relevant for engineers.
1) Always start with a test group
I used a group named:EID-EXP-007 - CA High Sign-in Risk.
It is not advisable to deploy this policy tenant-wide immediately.
2) Exclude break-glass accounts (mandatory)
Failing to exclude a break-glass account undermines identity security and introduces unnecessary risk.
The proper break-glass account should be:
- cloud-only
- long random password
- excluded from CA
- monitored with alerts
- no mailbox license (optional but recommended).
3) Apply to “All cloud apps.”
If applied only to Exchange Online or SharePoint, high-risk sign-ins may still occur in:
- Azure portal
- Entra admin center
- third-party SSO apps
- Graph access
- Intune
For comprehensive security, apply the policy to:
All cloud apps.
4) Use only “High” risk
This distinction is important.
Many admins try to block medium risk.
However, medium risk often generates excessive alerts and includes:
- travel
- new device behavior
- IP reputation that’s not high confidence
Blocking medium risk typically results in:
- helpdesk tickets
- business disruption
- policy rollback
Therefore, the objective for this lab is to implement a clear and defensible control:
High = blocked.
What This Looks Like in Sign-in Logs (Proof, Not Hope)
Once the policy is enabled, evidence of enforcement will appear in the logs.
Go to:Entra admin center → Users → (user) → Sign-in logs
For a high-risk event, you should see:
- Conditional Access status: Failure
- Result: Blocked
- Policy name: EID-EXP-007 — Block High-Risk Sign-ins
- Sign-in risk: High
This is important because it serves as:
- Your audit evidence
- Your incident response evidence
- Your SOC correlation point
The Most Common Mistakes I See
Mistake #1: Leaving the policy in Report-only mode
Report-only mode does not provide security.
It functions only as a policy simulation.
Mistake #2: Confusing sign-in risk with user risk
These are distinct controls.
Mistake #3: Failing to exclude break-glass accounts
This oversight can result in tenant lockout during a false positive event.
Mistake #4: Applying the policy to all users prematurely
A phased rollout strategy is essential.
Start with:
- test group
- pilot group
- then all users
Mistake #5: Assuming Identity Protection automatically blocks access
Identity Protection detects risk.
Conditional Access enforces policy.
When You Should NOT Block (Edge Cases)
In most environments, blocking high-risk sign-ins is a safe practice.
But here are the exceptions:
1) High-risk sign-ins from legacy auth
If legacy authentication remains enabled, unusual sign-ins may occur.
Address legacy authentication issues first.
2) Service accounts
Service accounts should not be interactive users.
If this is the case, update the architecture accordingly.
3) Break-glass accounts
These accounts must always be excluded.
Recommended Next Step (What I Do After This Lab)
Blocking high-risk sign-ins is an essential first step.
The next logical controls are:
1) Require MFA for medium sign-in risk
Instead of blocking.
2) User risk policy → password reset
If the user risk is high.
3) Require a compliant device for admin roles
This helps prevent token theft from unmanaged devices.
Final Takeaway
Identity protection is not measured by the number of risks detected.
It is defined by the controls you enforce. This lab proves a simple point:
If Entra detects a high-risk sign-in, access should not be allowed.
About the Author
Author: Jaspreet Singh
Platform: ITBlogs.ca