A strong credential answers the question of whether the right person is signing in. It does not answer whether the sign-in itself is safe. Identity Protection exists for the gap between those two questions, and the right way to hold it in your head is not as a wall but as a sensor: it watches the authentications that already passed, decides how much it believes them, and hands that belief to something else to act on.
This is the sixth article in the Entra ID series. The previous two were about credentials, about getting the strongest ones registered and preferred. This one is about what the platform does when a sign-in looks wrong despite a good credential, and about being honest regarding the limits of what a risk engine can actually know.
Two questions, and a clock
Risk in Entra is split along two axes, and keeping them straight is most of the conceptual work. The first axis is what is at stake. Sign-in risk is the probability that a specific authentication was not performed by the legitimate owner of the account. User risk is the probability that the account itself is compromised, an assessment that accumulates as individual risky sign-ins and other signals pile up against the same identity. The second axis is when the engine reaches its conclusion. Some detections fire in real time, in the five to ten minutes around the sign-in, and can therefore feed a decision that blocks or challenges the session as it happens. Others are offline, taking up to forty-eight hours as the platform correlates the event against patterns it could not evaluate in the moment.
That clock is the first thing a designer has to internalize, because it sets a hard limit on what risk can promise. A risky users report that looks clean at any given instant can be lagging an active offline compromise by up to two days. Real-time detection is the part that can stop something mid-flight; offline detection is the part that tells you, after the fact, that something already happened. Treating the second as if it were the first is how people end up surprised that the engine did not block an attack it had not yet finished thinking about.
Confidence, not severity
The low, medium, and high levels attached to every detection are routinely misread as a measure of how bad the event would be. They are not. They are Microsoft’s confidence that the account is compromised. A high-risk detection means the platform is highly confident, usually because the signal matches known attack patterns or came from threat intelligence, not that the consequences are necessarily graver than a medium one. This distinction matters the moment you write a policy against these levels, because you are tuning the aggressiveness of your response to the engine’s certainty, and you should know that is the dial you are turning.
The risk level is not how bad the event is. It is how sure the platform is that the account is compromised.
What the engine sees, and what it is simply blind to
The detection catalog is broad and worth knowing in outline: anonymous and malicious IP addresses, atypical and impossible travel, unfamiliar sign-in properties, password spray, leaked credentials, Entra threat intelligence, verified threat actor IP, token issuer anomaly, anomalous tokens, adversary-in-the-middle, and attempts to access the primary refresh token, among others. Read as a group they describe a genuinely capable sensor. But two properties of that catalog decide whether it is capable in your tenant specifically, and both are easy to miss.
The first is that a large share of the more interesting detections do not originate in Entra at all. Impossible travel, mass access to sensitive files, new-country activity, and suspicious inbox rules are produced by Defender for Cloud Apps, and other detections come from elsewhere in the Defender family, so they surface in Identity Protection only if you own and have connected the product that generates them. Without that product, those detections are not disabled, they are absent. The engine is not quiet because nothing is happening; it is quiet because it was never given the sense organ that would notice. The second is subtler still. Leaked credential detection depends on password hash synchronization to compare your on-premises passwords against known breach corpora, so a tenant that is federated or has hash sync switched off has a real blind spot for exactly the credentials most likely to be reused and dumped. And password spray, usefully, only registers on a successful validation, which means the detection is evidence that a spray landed, not a count of how many attempts were made. It undercounts the campaigns that failed, by design.
The lesson I draw from all of this is to be precise about coverage rather than assuming it. The risk engine is only as complete as the licenses and connectors feeding it, and a design that leans on risk as a control should start by writing down which detections the tenant can actually generate, and which it cannot.
Remediation is a loop, not a verdict
A risk score is only useful if there is a defined way for it to go back down, and Entra gives risk two exits. The first is self-remediation, where the user clears their own risk without an administrator in the loop: a sign-in risk is retired when the user satisfies multifactor authentication, and a user risk is retired by a secure password change, which is a password change performed under multifactor authentication rather than an ordinary reset. Designed well, this means most risk resolves itself, automatically, through a risk-based policy that demands the right step at the right moment. The second exit is the administrator, who can confirm a user or sign-in compromised, confirm it safe, or dismiss the risk. Those actions are not just bookkeeping. Confirming safe moves the account into a learning state and tells the platform that similar activity should not be treated as risky in future; confirming compromised raises the stakes and feeds the opposite signal. This feedback is processed offline and tunes the accuracy of future detections, which is to say the administrator’s judgments are training data, and sloppy dismissals quietly degrade the engine that everyone downstream relies on.
The practical shape, then, is to let the platform self-remediate the ordinary cases through policy and to reserve human confirmation for the genuine investigations, treating each confirmation as the considered signal it actually is.
The policies are moving house
Risk becomes an enforceable control through two policy shapes: a user-risk policy that can require a password change or block when the account’s accumulated risk crosses a threshold, and a sign-in-risk policy that can require multifactor authentication or reauthentication when a specific sign-in looks wrong. The current-year fact that belongs in every plan is that these no longer live where they used to. The standalone risk policies configured inside Identity Protection are retiring on October 1, 2026, and the supported home for both is Conditional Access, where risk sits alongside every other condition rather than in a separate console with its own logic. If you inherited a tenant still running the legacy risk policies, migrating them is not optional housekeeping; it is a dated cutover. Microsoft also ships managed Conditional Access policies for the common risk cases, introduced in report-only and self-enabling after roughly forty-five days, which are a reasonable floor but not a substitute for a design.
I am deliberately not going to teach Conditional Access here, because the endpoint series owns that ground in its Conditional Access phase and risk is only one of the conditions it consumes. The point for this series is narrower and it is architectural: risk is a signal that Conditional Access spends, and the quality of the spending depends entirely on the quality of the signal, which is where the earlier cautions about coverage and latency come back to matter.
Reading risk through the API, and what comes next
When risk has to feed something outside the portal, a security operations pipeline or an automated response, it is exposed through Microsoft Graph as a small set of resources: risky users, risk detections, and their service-principal equivalents for workload identities. Sign-in risk, worth noting so you do not go looking for a resource that does not exist, is read from the sign-in logs themselves rather than from a separate risky-sign-ins object. All of this reporting detail, and every one of those API surfaces, sits behind Entra ID P2; the free and P1 tiers see a deliberately thinned view without the detail, history, or programmatic access that make risk operationally useful. Workload identity risk extends the same model to service principals and is generally available, with the honest caveat that managed identities are outside its scope and generate no detections at all, and the newest frontier, risk for agent identities, is arriving in preview as the platform learns to watch non-human actors the way it watches people.
Risk tells you when to distrust a sign-in that carried a valid credential. It says nothing about whether the credential should have been able to reach anything important in the first place. That is the domain of privilege, of who holds power in the directory and under what conditions they are allowed to use it, and it is where the series turns next.
Entra ID
‹ Previous: [E 5] Passkeys, WHfB, and Phishing-Resistant Credentials
Next: [E 7] Privileged Identity Management in Depth ›
