In this section
Risk Signals and Identity Protection
Section 1.5 showed you the Conditional Access evaluation record — which policies evaluated on each sign-in and what they decided. This section examines the risk signals that feed into those policy decisions. Identity Protection assigns a risk assessment to every sign-in and every user account. The risk fields in the sign-in log tell you why a sign-in was flagged, how confident the assessment is, and what action was taken. Reading these fields is how you evaluate whether Identity Protection's detections are accurate in your environment — which is the prerequisite for deploying risk-based Conditional Access policies in EI5.
Scenario
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. Three are high risk. You need to know which detections fired, whether they're real-time or offline, what action was taken, and whether any of those high-risk sign-ins succeeded without being blocked. Clicking through 47 entries in the portal takes an hour. A KQL query answers the same questions in seconds — and tells you things the portal view doesn't, like whether the same risk pattern is hitting multiple accounts simultaneously.
How Identity Protection assigns risk
Microsoft Entra ID Protection is a machine-learning 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, and the distinction between them determines how you respond.
Sign-in risk measures how suspicious a specific authentication attempt is. It answers one question: does this sign-in look like it came from the legitimate user? Sign-in risk is assessed in real time during the authentication process and is available before Conditional Access makes its enforcement decision. This is the critical timing — a risk-based CA policy can block or challenge a risky sign-in before access is granted. If the sign-in risk is high and your CA policy requires MFA for high-risk sign-ins, the user is challenged immediately. If they can't complete the challenge, the attacker is stopped at the gate.
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 flagged as high. User risk persists until it is explicitly remediated through a secure password change, administrator investigation, or administrator dismissal. This persistence is by design — a compromised account doesn't become safe because the attacker stopped logging in.
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.
Figure 1.6 — Risk signal flow from sign-in event through Identity Protection evaluation, Conditional Access enforcement, and sign-in log recording. EI5 configures the risk policies. You learn to read the signals in the logs.
The five risk fields in the sign-in log
Five fields carry risk information in every sign-in log entry. Each answers a different question during triage.
RiskLevelDuringSignIn is the sign-in risk level at the time of authentication — the real-time assessment. Values are none, low, medium, high, and hidden (risk detected but details suppressed, typically when the tenant lacks a P2 license). This is the field you filter on first when triaging risky sign-ins. A high-risk sign-in that succeeded (ResultType 0) means Identity Protection flagged it, but either no risk-based CA policy was configured, or the user satisfied the policy's requirement.
RiskLevelAggregated is the user's overall risk level at the time of this sign-in. If the user's risk was elevated from a previous incident and hasn't been remediated, this field shows the elevated level even if the current sign-in itself isn't risky. A user with RiskLevelAggregated: "high" and RiskLevelDuringSignIn: "none" has an unresolved compromise from a prior event — the current sign-in is clean, but the account is still at risk.
RiskDetail records what action was taken or is available. The values that matter for triage: "none" means no risk detected. "aiConfirmedSigninSafe" means Identity Protection determined the sign-in was safe after initial flagging. "userPassedMFADrivenByRiskBasedPolicy" means the user completed MFA prompted by a risk-based CA policy — the system worked as designed. "adminConfirmedSigninCompromised" means an administrator confirmed the sign-in was malicious. "adminDismissedAllRiskForUser" means an administrator dismissed the risk. "userPerformedSecuredPasswordChange" means the user resolved their user risk through a secure password change.
RiskState shows the current lifecycle state: "atRisk" means risk detected and not yet remediated — these accounts need action. "confirmedCompromised" means an admin confirmed compromise. "remediated" means the risk was resolved. "dismissed" means an admin dismissed it. "confirmedSafe" means the sign-in was confirmed legitimate.
RiskEventTypes_V2 is the most granular field — a JSON array listing the specific risk detection types that fired for this sign-in. This is where you find out why Identity Protection flagged a sign-in, not just that it was flagged.
Real-time versus offline detections
The detection type determines when the risk signal is available, and that timing has a direct operational impact.
Real-time detections are evaluated during the authentication process, before Conditional Access makes its decision. A CA policy that requires MFA for medium-or-higher sign-in risk can respond to these detections immediately — the user is challenged before access is granted. Real-time detections surface in reports within 5–10 minutes.
The real-time detections you'll see most frequently: unfamiliarFeatures fires when sign-in properties (IP, location, device) differ from the user's recent baseline — this is the most common detection and produces the most false positives. anonymizedIPAddress fires for Tor exit nodes and known anonymizers. maliciousIPAddress fires for IPs associated with known malicious activity. impossibleTravel fires when two sign-ins originate from geographically distant locations in a time window too short for physical travel. anomalousToken fires when the token has unusual properties — this is the AiTM indicator. tokenIssuerAnomaly fires for unexpected identity providers, potentially indicating a federation trust attack. authenticatorPhishing (added April 2026) fires when Authenticator app telemetry combined with unfamiliar ASN, browser, device, or GPS data suggest a social engineering or phishing attack during Password + MFA authentication.
Offline detections are calculated after authentication, sometimes hours later. They cannot influence the CA decision on the sign-in that triggered them — the access was already granted or denied. Instead, offline detections raise the user's risk level, which triggers a user risk-based CA policy on the user's next sign-in. Offline detections take up to 48 hours to surface in reports.
The offline detections that matter most: leakedCredentials fires when the user's credentials appear in a breach database — Microsoft monitors multiple sources for credential leaks. passwordSpray fires when Identity Protection detects a pattern consistent with a distributed spray campaign. suspiciousInboxForwarding fires when an inbox rule forwards email to an external address — not a sign-in detection, but a user risk signal that indicates potential compromise. mcasSuspiciousInboxManipulationRules is the Defender for Cloud Apps equivalent.
The operational implication: real-time detections are your first line of defense against active attacks. Offline detections are your early warning system for accounts that may already be compromised. Both feed into Conditional Access, but through different paths — sign-in risk for real-time, user risk for offline. EI5 teaches you to configure policies that respond appropriately to both.
Entra Admin Center
Identity → Protection → Identity Protection → Risk detections
The portal shows risk detections in a filterable list. Filter by detection type, risk level, and risk state. Click any detection to see the full detail including the sign-in correlation ID, the IP address, the detection timing, and the recommended investigation steps. The portal is useful for individual triage; the KQL queries below scale it across the tenant.
Triaging risk signals with KQL
The portal's Risky Users and Risky Sign-Ins blades work for individual triage, but at scale, KQL is faster and more systematic. Two queries cover the essential triage workflow.
The first query finds the most urgent items — high-risk sign-ins that succeeded:
Every result from this query is a high-risk sign-in that succeeded. The RiskDetail field tells you what happened. If it reads "userPassedMFADrivenByRiskBasedPolicy", the system worked — the user was challenged and completed MFA, which may have been the legitimate user proving their identity. If it reads "none", no risk-based policy was configured or the user was excluded — the sign-in succeeded without any additional challenge, which is the most dangerous outcome. The ConditionalAccessStatus field from Section 1.5 tells you whether any CA policy evaluated at all.
The second query shows which risk detection types are firing and at what frequency — the operational picture of your tenant's risk landscape:
This query gives you the tenant-wide risk detection distribution. If unfamiliarFeatures dominates at low risk, that's normal baseline noise — it fires for travel, VPN usage, and device changes. If anomalousToken appears at any risk level, investigate immediately — it's the AiTM indicator from Section 0.4. If leakedCredentials appears, those accounts need immediate password rotation regardless of the risk level, because the credentials are exposed. The pattern of what's firing and how often tells you what's happening in your tenant before you open a single investigation.
Identity Protection is enabled. Risk detections appear in the portal. Nobody has configured risk-based Conditional Access policies, so the detections are data without enforcement — the risk is flagged but access is never challenged or blocked. The Risky Users blade accumulates hundreds of flagged accounts over months. The SOC dismisses them in bulk because there are too many to investigate individually. The result: a detection engine running at full power with zero operational impact. EI5 closes this gap by teaching you to deploy risk-based CA policies that enforce automatically. You learn to verify, before deployment, that the detections are accurate enough to trust with automated enforcement.
Assessing detection accuracy before enforcement
You don't deploy risk-based CA policies blindly. Before you configure a policy that blocks high-risk sign-ins or requires MFA for medium-risk sign-ins, you need to know whether Identity Protection's detections in your environment are accurate enough to justify automated enforcement.
The assessment method is straightforward: query the risk detections for the past 30 days, sample the high and medium findings, and classify each as true positive (the sign-in was genuinely suspicious), false positive (the sign-in was legitimate — travel, VPN, new device), or indeterminate (you can't tell without more context). The ratio tells you whether automated enforcement is safe.
If your high-risk detections are 80%+ true positive, a CA policy that blocks high-risk sign-ins will correctly block most attacks with few disruptions. If your unfamiliarFeatures detections at medium risk are 60% false positive because your users travel frequently, requiring MFA for medium-risk sign-ins will produce frequent unnecessary MFA prompts — annoying but not blocking. You may still accept that trade-off, but you should make the decision with data, not assumptions.
In a new developer tenant with limited activity, you'll see few or no risk detections because Identity Protection needs a baseline of sign-in behavior before it can identify anomalies. This is expected. To generate test signals, sign in from a different network — a mobile hotspot, a VPN endpoint in a different country. Wait 15–30 minutes and check the sign-in logs for unfamiliarFeatures in RiskEventTypes_V2. The detection proves the pipeline works. The accuracy assessment comes later, when you have real user activity and real detections to evaluate.
One important platform change affects risk policy deployment: the legacy risk policies configured directly in the Identity Protection blade are retiring on October 1, 2026. All risk-based enforcement must be configured as Conditional Access policies. EI5 teaches you to build these policies in Conditional Access from the start, so this retirement has no impact on what you learn — but if your production tenant still uses legacy Identity Protection policies, plan the migration before the retirement date.
Identity Security Principle
Identity Protection is a detection engine, not an enforcement engine. By itself, it detects risk and flags accounts — but it takes no action unless you configure risk-based policies in Conditional Access. A tenant with Identity Protection enabled but no risk-based CA policies will see 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 intelligence without enforcement. EI5 connects the intelligence to the enforcement.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.