Picture this: a perfectly valid user signs in to Microsoft 365 at 9:02 AM. Same username. Correct password. Same app. Nothing “fails.” Yet the session originates from an anonymizing network, from a geography your tenant has never seen for that user, using an unfamiliar device and browser fingerprint. If you only watch failed sign-ins, you’ll miss it.
That gap is exactly what monitoring risky sign-ins with identity protection in entra id is meant to close.
Here’s the clean definition you can lift into a snippet:
Monitoring risky sign-ins with Microsoft Entra ID Protection means continuously detecting and investigating suspicious authentication attempts (sign-in risk) and compromised accounts (user risk), then enforcing automated controls through Conditional Access—typically requiring MFA, forcing password reset, or blocking access—based on Microsoft’s risk signals.
We go beyond the usual “click here in the portal” overview. We’ll treat Entra ID Protection as a risk engine, break down what it’s measuring, and build a monitoring + response loop that stays useful after the first week—when false positives, service accounts, VPNs, and real attackers start blending together.
Why this matters now
Identity attacks are optimized for “successful sign-in.” Phishing kits and adversary-in-the-middle tooling aim to steal sessions, bypass basic MFA, and reuse tokens. That means you need controls that respond to risk context—not just credentials.
Microsoft Entra ID Protection exists because Microsoft can see patterns you cannot: global IP reputation, malware-linked infrastructure, leaked credential telemetry, and behavioral anomalies across a massive identity footprint. The output is a risk score at two levels: the sign-in and the user.
If you don’t operationalize those two signals, Entra ID Protection becomes a fancy report you check after an incident.
The surface view (and why it’s incomplete)
Most “AI overview” style explanations stop here:
- Go to Protection → Identity Protection → Risky sign-ins
- Filter by risk level
- Investigate
- Configure Conditional Access to require MFA or password reset
All true. But incomplete.
Because in real environments, the hard problems are these:
- Which risky sign-ins are actionable, and which are “normal weird” (travel, mobile carriers, corporate VPN egress, Zscaler-like stacks)?
- How do you prevent “MFA solves it” from becoming a false sense of security when attackers can still steal sessions?
- How do you tune policy scope so you don’t lock out admins, service principals, or emergency accounts?
- How do you move from portal-driven investigation to repeatable triage with logs, queries, and automation?
To answer those, we need first principles.
What “risk” actually means in entra id protection
Risk scoring in Entra ID Protection is not a morality judgement. It’s a probability estimate:
- Sign-in risk: likelihood a specific authentication attempt isn’t performed by the identity owner.
- User risk: likelihood the account credentials are compromised (based on aggregated evidence across events and time).
The irreducible model
At its core, risk-based identity defense reduces to four steps:
- Observe: collect authentication signals (IP, ASN, device, location, session traits, threat intel).
- Infer: compare those signals to known bad infrastructure and to that user’s baseline.
- Decide: classify the event/user into low/medium/high risk.
- Act: enforce step-up auth, force credential reset, or block.
Entra ID Protection covers steps 1–3 and feeds step 4 into Conditional Access.
Why “risk” produces surprising behavior
From this model, a few non-obvious truths fall out:
- A sign-in can be high risk even if it succeeds, because the risk engine is orthogonal to authentication success.
- A user can remain “at risk” after one event, because user risk is stateful and accumulative.
- “Fixing” risk often means forcing a new proof of identity (MFA) or a new secret (password reset). That’s why self-remediation is a core concept.
- Monitoring without enforcement is mostly theater. Risk signals are designed to drive automated policy.
What Entra actually detects (and how to think about detections)
Microsoft documents risk detections as a catalog, including which detections are real-time vs offline, and which require P2 for full detail.
A useful way to understand detections is to group them by what kind of claim they make:
1) Infrastructure risk (the network is suspicious)
Examples include anonymous IP and malicious IP intelligence. This category is strong because it doesn’t depend on the user’s baseline—only on whether the source network is known-bad or intentionally obfuscated.
Operational implication: infrastructure risk often deserves immediate friction (MFA at minimum), but it can also generate noise if your company routes traffic through anonymized egress or security proxies.
2) Baseline deviation (this user doesn’t do this)
Detections like unfamiliar sign-in properties are based on observed history: IP, ASN, location, device, browser, tenant subnet, and related properties.
Operational implication: baseline-based detections are powerful, but sensitive to organizational changes (new VPN, new ISP, new laptop rollout).
3) Credential compromise signals (the secret is likely exposed)
Detections such as leaked credentials map more directly to account takeover risk.
Operational implication: treat these as “assume breach until proven otherwise.” You usually want password reset + session revocation patterns, not just MFA.
4) Correlated behavior (this pattern looks like an attacker)
Password spray, atypical patterns, token anomalies—these are less about one attribute and more about attacker-shaped behavior at scale.
Operational implication: you want cross-user correlation, which is where Sentinel/SIEM shines.
The monitoring loop that actually works
A mature setup has three layers:
- Portal monitoring for quick investigation and human decisions.
- Automated enforcement to reduce time-to-containment.
- Telemetry + hunting to discover patterns that policy alone won’t catch.
Microsoft’s risk reports and investigation guidance give you the base mechanics.
Your job is to turn them into an operating rhythm.
How to monitor risky sign-ins (end-to-end)
This is the “pure technical” portion. Treat it like an implementation runbook you can adapt.
Prerequisites and access model
- Licensing: full Entra ID Protection functionality requires Microsoft Entra ID P2 (or Entra Suite in many cases).
- Least-privileged access: for viewing reports, Microsoft notes roles like Global Reader as minimal for report visibility.
- Know where policies live: Microsoft has consolidated “risk policies” into Conditional Access risk conditions (sign-in risk and user risk).
If you need a refresher on Conditional Access mechanics and scoping, see WAD’s guide: How to use Azure AD Conditional Access to enforce access policies.
Step 1: Establish your baseline views (risk reports that matter)
In the Entra admin center, Identity Protection provides key reports:
- Risky sign-ins
- Risky users
- Risk detections (event feed)
Microsoft describes how to access, filter, and use these reports (including marking events as confirmed compromised or dismissing).
How to use these views in practice (not just “look at them”):
- Start with Risk detections to see what detection types are firing in your tenant.
- Pivot to Risky sign-ins when the question is: “Was this specific session suspicious?”
- Pivot to Risky users when the question is: “Is this account compromised beyond one session?”
This sequence matches how incidents unfold: first you see an indicator (detection), then you validate a session, then you decide account-level remediation.
Step 2: Define your enforcement strategy as two policies (minimum viable, high value)
You need two Conditional Access policies, mapped to the two risk signals.
Policy A: sign-in risk policy (session containment)
Goal: if the sign-in is risky, require strong proof.
- Condition: Sign-in risk = Medium and High (or High only at first).
- Control: Require MFA (or stronger authentication strength), otherwise block.
- Scope: Start with a pilot group, then expand.
Microsoft’s risk policy guidance emphasizes that strong authentication (usually MFA/passwordless) is how sign-in risk self-remediation happens.
Practical tuning choice:
- If you set threshold to High, you reduce noise but miss medium-risk sessions.
- If you set it to Medium, you increase prompts but shrink attacker dwell time.
A realistic rollout is: High (week 1) → Medium+High (after tuning).
Policy B: user risk policy (account recovery)
Goal: if the account is likely compromised, rotate the secret.
- Condition: User risk = High (expand later if desired).
- Control: Require password change via SSPR (self-remediation) or block.
Microsoft documents that user risk can be remediated by SSPR password reset, or by secure password change patterns, depending on your configuration.
Step 3: Handle the hardest part: exclusions that don’t create holes
Every tenant needs exceptions. The trick is to keep exceptions explicit, small, and monitored.
Common exclusion categories:
- Break-glass accounts (emergency access)
- Exclude them, but lock them down with long random passwords, restricted sign-in locations, and continuous alerting.
- Service accounts / non-interactive identities
- Many don’t behave like humans. They break baseline detectors.
- High-privilege admins
- Often you should tighten policies, not loosen them. But avoid locking yourself out.
A useful pattern is: exclude break-glass from risk policies, but apply separate strict controls to them (limited locations, monitored sign-ins).
We have already covered monitoring and exporting Entra logs to external systems, which matters because “excluded” accounts should be more monitored, not less:
- How to monitor and report security events in Microsoft Entra ID (Windows Active Directory)
- How to export Entra ID logs efficiently (Windows Active Directory)
Step 4: Build a repeatable investigation workflow (triage → decision → evidence)
Microsoft provides an investigation framework for risky users/sign-ins/detections.
The important part is turning it into a consistent checklist so two different engineers reach the same decision.
Triage checklist for a risky sign-in:
- Who: user, role, privilege level
- What: app, resource, authentication method
- Where: IP, ASN, geo, named location match?
- Device: managed/compliant? new device?
- Detection type: anonymous IP vs unfamiliar properties vs leaked credentials
- Session outcome: MFA performed? token issued? conditional access applied?
Decision outcomes (keep it binary):
- True positive → contain session + remediate account
- False positive → dismiss / confirm safe, then tune (named locations, device requirements, VPN strategy)
Microsoft supports giving risk feedback (confirm compromised / dismiss) which helps adjust risk and improves signal accuracy over time.
Step 5: Export telemetry and hunt patterns (because attackers don’t attack one user)
Portal investigation is necessary, but insufficient.
To detect mass spraying, geo waves, or targeted admin attacks, you want correlation across sign-ins.
Two practical routes:
Route A: Microsoft Sentinel / Log Analytics
We already outlined the “send logs to Sentinel” direction in our monitoring article.
Once in Sentinel, you can:
- Alert on spikes in risk detections
-
- Correlate risky sign-ins with privileged role changes (see our privilege escalation tracking for the investigative mindset)
-
- Build “top risky IPs / ASNs this week” and tie to user impact
Route B: third-party reporting and dashboards
If your goal is “prebuilt reporting, delegation, and M365-focused dashboards,” ManageEngine’s guide is a good complement:
Use it when you want clean reporting without building Sentinel workbooks.
Step 6: Validate user experience and avoid silent bypass
Two key realities:
- MFA is not identical to session safety. It proves possession at one moment, not that the session can’t be hijacked later.
- Attackers adapt. If you only require MFA at high risk, they will aim for lower-risk paths (trusted infrastructure, token replay, device registration abuse).
So you should harden adjacent controls:
- Require strong MFA methods and block weak fallbacks.
- Prevent MFA registration from risky sessions (Microsoft documents risk-based sign-in protections in this direction). (video2.skills-academy.com)
- Use authentication strengths and device compliance where feasible (Conditional Access material is a good starting point).
This is where “monitoring risky sign-ins” becomes a broader identity assurance program, not a single report.
Comparison: portal-only monitoring vs risk-driven operations
A good long-form comparison is to ask: what breaks as you scale?
Portal-only approach (common, fragile)
Strengths
- Fast to start
- Good for single-user investigations
- Minimal dependencies
Failure modes
- No consistency across analysts
- Slow containment
- No cross-user correlation
- Noise fatigue (people stop looking)
Risk-driven operations (what you’re building)
Strengths
- Automated containment through Conditional Access
- Self-remediation paths for sign-in risk and user risk
- Repeatable triage
- Better attacker economics (more friction, less dwell time)
Trade-offs
- Requires tuning and exception hygiene
- Needs telemetry pipelines for advanced hunting
Practical tuning guidance (what usually causes pain)
These are the issues that repeatedly show up in real tenants:
Corporate VPNs and “anonymous IP” tension
If your company uses egress that resembles anonymization or shared exit nodes, you can see more anonymous-IP hits. Treat this as a design problem:
- Decide whether VPN egress should be a trusted “named location” or whether you still want step-up auth even on VPN.
- Prefer device compliance signals where possible, because IP alone is fragile.
Unfamiliar sign-in properties after infrastructure changes
Large changes create baseline churn: new laptops, new ISP, new proxy. The right response is not “turn off risk.” It’s:
- Communicate planned changes to the SOC
- Temporarily raise thresholds
- Use the risk detections feed to observe which detection types spike
Admin accounts deserve different treatment
Admins should not get “normal user” policies. They should get:
- Smaller allowed surface area
- Tighter conditional access
- Faster remediation when flagged
A short “do this first” checklist (if you want results this week)
- Confirm you have Entra ID P2 coverage for the users you’ll enforce on.
- Review Risk detections for the last 7–30 days and identify top detection types.
- Create Policy A: Sign-in risk = High → require MFA.
- Create Policy B: User risk = High → require password change.
- Exclude break-glass accounts, then separately monitor them heavily.
- Set a weekly review: top risky sign-ins, top risky users, top detection types, and policy impact.
Key takeaways
Monitoring risky sign-ins with identity protection in entra id is not “a report you check.” It’s a control loop:
- Risk detections tell you what’s being seen. (Microsoft Learn)
- Risky sign-ins tell you which sessions to contain. (Microsoft Learn)
- Risky users tell you which identities need recovery. (Microsoft Learn)
- Conditional Access is how you turn risk into action at machine speed. (Microsoft Learn)
- The real differentiator is your tuning discipline: scoping, exclusions, telemetry, and feedback loops. (GitHub)
