In this module

EI1.6 Risk Signals and Identity Protection

60-80 minutes · Module 1 · Free

Operational Objective

The Risky Users blade shows 14 accounts flagged at various risk levels. The Risky Sign-Ins blade shows 47 events in the last 24 hours. You need to understand what each risk signal means, how Identity Protection calculates the risk levels, which risk detections are real-time vs offline, and how to use KQL queries to triage and investigate risk signals at scale rather than clicking through individual entries in the portal.

Deliverable: The ability to interpret every risk-related field in the sign-in logs, understand how Identity Protection produces risk scores, query risk data at scale with KQL, and build the triage workflow that EI5 will formalize into operational procedures.

⏱ Estimated completion: 18 minutes

How Identity Protection assigns risk

Microsoft Entra ID Protection is a machine learning-based risk engine that evaluates every sign-in and every user account for suspicious behavior. It produces two independent risk assessments that appear in the sign-in logs:

Sign-in risk measures how suspicious a specific authentication attempt is. It answers the question: does this sign-in look like it came from the legitimate user, or does it look like an attacker? Sign-in risk is assessed in real time during the authentication process and is available before conditional access makes its enforcement decision. This means a risk-based conditional access policy can block or challenge a risky sign-in before access is granted.

Expand for Deeper Context

User risk measures the overall likelihood that a user account has been compromised, considering all recent activity — not just a single sign-in. A user who has had multiple medium-risk sign-ins over several days may accumulate a high user risk even if no single sign-in was individually high-risk. User risk persists until it is explicitly remediated (through a secure password change, admin investigation, or admin dismissal).

Both risk levels use the same four-point scale: none, low, medium, and high. The exact thresholds and model weights are not publicly documented — Microsoft treats them as proprietary to prevent attackers from gaming the detection. What is documented is the list of risk detection types and whether each produces a real-time or offline signal.

The sign-in log contains several risk-related fields:

RiskLevelDuringSignIn — the sign-in risk level at the time of authentication. This is the real-time assessment. Values: none, low, medium, high, hidden (risk detected but suppressed, typically in report-only scenarios). This is the field you use in detection rules to identify suspicious sign-ins.

Expand for Deeper Context

RiskLevelAggregated — the user's overall risk level at the time of this sign-in. This reflects the cumulative risk assessment across recent activity. If the user's risk was elevated from a previous incident and has not been remediated, this field will show the elevated level even if the current sign-in itself is not risky.

RiskDetail — what action was taken or is available regarding the risk. Values include: "none" (no risk detected), "aiConfirmedSigninSafe" (Identity Protection determined the sign-in was safe after initial detection), "userPassedMFADrivenByRiskBasedPolicy" (the user completed MFA prompted by a risk-based policy), "adminConfirmedSigninCompromised" (an administrator confirmed the sign-in was malicious), "adminDismissedAllRiskForUser" (an administrator dismissed the user's risk), and "userPerformedSecuredPasswordChange" (the user changed their password through a secure flow, resolving user risk).

RiskEventTypes_V2 — a list of the specific risk detection types that were triggered for this sign-in. This is the most granular risk information available and is essential for understanding why a sign-in was flagged.

RiskState — the current state of the risk: "atRisk" (risk detected and not yet remediated), "confirmedCompromised" (admin confirmed compromise), "remediated" (risk was remediated through password change or admin action), "dismissed" (admin dismissed the risk), "confirmedSafe" (admin or AI confirmed the sign-in was legitimate).

Understanding the risk detection types

Each risk detection type corresponds to a specific suspicious pattern. The detections fall into two categories: real-time (evaluated during authentication, can influence the access decision) and offline (calculated after authentication, used for investigation and user risk assessment).

Real-time detections — evaluated during sign-in, available for conditional access decisions:

// EI1.6 — Risk detection overview for the last 7 days
// Shows which risk types are firing and at what frequency
SigninLogs
| where TimeGenerated > ago(7d)
| where RiskLevelDuringSignIn != "none" and RiskLevelDuringSignIn != ""
| extend RiskTypes = parse_json(RiskEventTypes_V2)
| mv-expand RiskType = RiskTypes
| summarize 
    DetectionCount = count(),
    AffectedUsers = dcount(UserPrincipalName),
    MostRecentDetection = max(TimeGenerated)
    by RiskLevel = RiskLevelDuringSignIn, 
       RiskType = tostring(RiskType)
| order by DetectionCount desc
// Review: Which detection types are most common?
// High-risk detections require immediate triage
// Medium-risk detections should be reviewed daily
// Low-risk detections indicate baseline noise — tune if volume is too high

Expand for Deeper Context

Anonymous IP address — the sign-in originated from an anonymous IP address such as a Tor exit node or known VPN anonymizer. Not all VPN traffic triggers this — only IPs specifically identified as anonymizing services.

Atypical travel — the user signed in from two geographically distant locations in a time period that makes physical travel impossible. If the user signs in from London at 9:00 AM and from Sydney at 9:15 AM, atypical travel fires. This detection accounts for VPN usage and known travel patterns, but false positives occur with VPN switching and mobile network handoffs.

Malicious IP address — the sign-in originated from an IP address that Microsoft's threat intelligence has identified as associated with malicious activity.

Unfamiliar sign-in properties — the sign-in has properties (IP address, location, device) that differ from the user's recent baseline. This is the most common detection and the one with the highest false positive rate — it fires frequently for users who travel, use multiple devices, or work from varying locations.

Anomalous token — the token presented has unusual properties. This detection specifically targets AiTM-captured tokens and tokens that have been manipulated.

Token issuer anomaly — the token was issued by an unexpected identity provider, potentially indicating a federation trust attack (Golden SAML).

Offline detections — calculated after sign-in, contribute to user risk:

Leaked credentials — the user's credentials were found in a credential dump or dark web database. Microsoft monitors multiple sources for credential leaks and matches them against Entra ID accounts.

Password spray — Identity Protection detected a pattern consistent with a distributed password spray campaign targeting this account.

Suspicious inbox forwarding — an inbox rule was created that forwards email to an external address. This is not a sign-in risk detection but a user risk detection that raises the user's overall risk level.

Triaging risk signals with KQL

The portal's Risky Users and Risky Sign-Ins blades provide a GUI for individual triage, but at scale, KQL queries are faster and more systematic. Here are the core triage patterns:

Find all high-risk sign-ins that succeeded (the most urgent queue):

// EI1.6 — High-risk successful sign-ins — triage immediately
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0  // Successful
| where RiskLevelDuringSignIn == "high"
| project 
    TimeGenerated,
    UserPrincipalName,
    AppDisplayName,
    IPAddress,
    Location = strcat(tostring(LocationDetails.city), ", ", 
        tostring(LocationDetails.countryOrRegion)),
    RiskEventTypes_V2,
    ConditionalAccessStatus,
    RiskDetail
| order by TimeGenerated desc
// EVERY result requires investigation
// A high-risk sign-in that succeeded means Identity Protection flagged it
// but the access was not blocked — either no risk policy enforced, or
// the user satisfied the risk policy requirement (e.g., completed MFA)

// EI1.6 — Users at risk with no remediation action taken
AADRiskyUsers
| where RiskLevel in ("medium", "high")
| where RiskState == "atRisk"  // Not yet remediated or dismissed
| project 
    RiskLastUpdatedDateTime,
    UserPrincipalName,
    UserDisplayName,
    RiskLevel,
    RiskDetail,
    RiskState
| order by RiskLastUpdatedDateTime desc
// These users need action: investigate, remediate (password change + session revoke),
// or dismiss with documented justification
// The triage workflow is formalized in EI5

// EI1.6 — What did risky users do after their risky sign-in?
// Correlate risky sign-in with subsequent activity
let riskySignIns = SigninLogs
| where TimeGenerated > ago(24h)
| where RiskLevelDuringSignIn in ("medium", "high")
| where ResultType == 0
| project RiskyUser = UserPrincipalName, RiskyTime = TimeGenerated, RiskyIP = IPAddress;
AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| join kind=inner riskySignIns on $left.UserPrincipalName == $right.RiskyUser
| where TimeGenerated > RiskyTime  // Activity after the risky sign-in
| where TimeGenerated < datetime_add('hour', 2, RiskyTime)  // Within 2 hours
| summarize 
    PostRiskApps = make_set(AppDisplayName, 10),
    PostRiskIPs = make_set(IPAddress, 5),
    EventCount = count()
    by UserPrincipalName
// Review: What applications did the user access after the risky sign-in?
// Were the non-interactive events from the same IP as the risky sign-in or a different one?
// Different IP = potential token theft in progress

Expand for Deeper Context

Find users with elevated risk that has not been remediated:

Correlate sign-in risk with what the user did after authentication:

This correlation query is a preview of the detection engineering patterns in EI13. The logic: after a risky sign-in succeeds, what happened next? If the user's subsequent non-interactive activity comes from the same IP as the risky sign-in, it may be the same (potentially compromised) session. If it comes from a different IP, the attacker may be replaying a stolen token from their own infrastructure while the user's legitimate session continues from the user's IP.

Figure EI1.6 - Risk Signals and Identity Protection

Real-time vs offline: why the timing matters

The distinction between real-time and offline detections has a direct impact on your security posture.

Real-time detections are available during the authentication process. A conditional access policy that requires MFA for medium or higher sign-in risk can respond to a real-time detection immediately — the user is challenged for additional verification before access is granted. If the attacker cannot complete the additional challenge, the attack is blocked at the moment of initial access.

Expand for Deeper Context

Offline detections are calculated after the fact — sometimes hours after the sign-in occurred. A leaked credential detection, for example, depends on Microsoft's threat intelligence pipeline processing a credential dump and matching it against Entra ID accounts. By the time the detection fires, the user's credentials may have been exposed for days. The offline detection raises the user's risk level, which triggers a user risk-based conditional access policy on the user's next sign-in — but it does not retroactively block the access that already occurred.

This timing difference means that real-time risk detections are your first line of defense, while offline detections are your early warning system. Both are valuable, but they serve different operational purposes. EI5 teaches you to configure risk policies that respond appropriately to both types.

Try it yourself

Try It — Explore Your Risk Signals

Environment: Your M365 developer tenant with Sentinel workspace.

Exercise: Run the risk detection overview query from above. In a new developer tenant with limited activity, you may see zero risk detections — this is normal because Identity Protection needs a baseline of sign-in behavior before it can identify anomalies.

To generate risk signals for testing: sign in from a different network (mobile hotspot, VPN to a different country). Wait 15-30 minutes and check the sign-in logs for risk fields. You may see "unfamiliarFeatures" in the RiskEventTypes_V2 field.

Then check the Risky Users blade in the portal: Entra admin center → Identity → Protect & secure → Identity Protection → Risky users. Note the users, their risk levels, and the risk detail. Compare what you see in the portal with what the KQL query returns. The portal and the KQL query should show the same data — but the KQL query is faster at scale.

⚠ Compliance Myth: "Identity Protection catches all identity attacks automatically"

The myth: We enabled Identity Protection. It uses AI to detect identity attacks. We are protected.

The reality: Identity Protection is a detection engine, not an enforcement engine. By itself, it detects risk and flags accounts — but it does not take action unless you configure risk policies in conditional access (EI5). A tenant with Identity Protection enabled but no risk-based conditional access policies will see risk detections in the logs and the portal, but no sign-in will be blocked and no user will be prompted for remediation. The detections are data without enforcement. Additionally, Identity Protection's detections have blind spots — a well-crafted AiTM attack from the same country as the user, using a VPN exit node with a clean reputation, may not trigger any risk detection. Custom detection rules in Sentinel (EI13) complement Identity Protection by catching patterns that the built-in model misses.

📋 Investigation Artifact — Risk Detection Type Reference

Reference this when triaging risk detections in sign-in logs or the Risky Users blade:

Identity Protection Risk Detections

Real-Time Detections (available during sign-in):

- unfamiliarFeatures — sign-in properties differ from recent baseline

- anonymizedIPAddress — Tor exit node or known anonymizer

- maliciousIPAddress — IP associated with malicious activity

- suspiciousIPAddress — IP with known bad history

- impossibleTravel — two distant locations in impossible time

- anomalousToken — token has unusual properties (AiTM indicator)

- tokenIssuerAnomaly — unexpected identity provider (Golden SAML indicator)

- suspiciousBrowser — browser fingerprint associated with attack tools

Offline Detections (calculated post-authentication):

- leakedCredentials — credentials found in breach data

- passwordSpray — pattern consistent with distributed spray

- suspiciousInboxForwarding — email forwarding rule to external address

- anomalousUserActivity — unusual behavior pattern

- mcasSuspiciousInboxManipulationRules — Defender for Cloud Apps detection

- investigationsThreatIntelligence — Microsoft threat intelligence match

Triage priority:

High risk + anomalousToken = investigate immediately (likely AiTM)

High risk + tokenIssuerAnomaly = investigate immediately (likely federation attack)

Medium risk + unfamiliarFeatures = review within 4 hours (likely travel or VPN)

Low risk = review during daily triage (likely baseline noise)

Compliance mapping: Risk-based monitoring supports SOC 2 CC7.2 (Monitoring), ISO 27001 A.12.4.1 (Event Logging), and NIST CSF DE.AE-2 (Anomaly Detection).

Decision point

Entra ID Identity Protection flags a sign-in as 'High Risk' due to unfamiliar sign-in properties. The user is a new employee who started this week and is signing in from their home for the first time. Do you block the sign-in?

Not automatically. New employees generate Identity Protection alerts because they have no established baseline — every sign-in property is 'unfamiliar' for a user with no history. The response: (1) verify the sign-in is from the new employee (check with HR or the hiring manager), (2) dismiss the risk detection as a confirmed false positive (this trains Identity Protection's machine learning), (3) document the pattern so future new employee onboarding includes a note to the SOC: 'New employee [name] starting [date] — expect Identity Protection alerts for the first 2 weeks.' The alternative — blocking new employees on day 1 — creates a terrible onboarding experience and a flood of helpdesk tickets.

NE's Entra ID security audit reveals: 4 Global Administrators (policy says 2), 23 users with Global Reader from a completed project, a break-glass account with no monitoring rule, and 3 guest accounts with no expiry date. Which finding is the highest priority?

The 4 Global Administrators — 2 extra GAs doubles the attack surface.

The break-glass account with no monitoring rule. The 4 GAs and stale Global Readers are governance issues that should be remediated — but they are existing conditions, not active threats. The unmonitored break-glass account is a critical detection gap: if the break-glass account is compromised or misused, the SOC has no alert. A break-glass account is excluded from CA policies by design — it is the most powerful and least restricted account in the tenant. Without monitoring, its compromise or misuse is invisible. Deploy the monitoring rule (any sign-in to the break-glass account = Severity 1 alert) before addressing the other findings.

The 23 stale Global Readers — this is the largest number of affected accounts.

The 3 guest accounts — external accounts without expiry are the highest risk.

You've mapped the identity threat landscape and learned to read sign-in logs.

EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.

17 engineering modules — authentication methods, conditional access architecture, Identity Protection, PIM, token protection, application governance, and detection rules
The Defense Design Method — the six-step framework applied to every identity control you'll build
EI18 Capstone — Identity Security Architecture Design — design complete identity architectures for three realistic organisations (SMB, mid-market, regulated enterprise)
Identity Security Toolkit lab pack — deployable conditional access policies, PIM configurations, and Identity Protection risk rules
Cross-domain detection (EI16) — email-to-identity correlation and the full phishing-to-inbox-rule attack chain

Unlock the full course with Premium See Full Syllabus

← Previous Next →

EI1.6 Risk Signals and Identity Protection

How Identity Protection assigns risk

Risk fields in the sign-in log

Understanding the risk detection types

Triaging risk signals with KQL

Real-time vs offline: why the timing matters

Try it yourself