In the last post I argued that Security Defaults are not a Conditional Access strategy, and sketched a minimum viable posture: MFA for everyone, legacy auth blocked, admins locked down. That floor stops a lot of commodity attacks. But it’s static. Every sign-in gets treated the same whether it comes from a managed laptop on the corporate range or from a residential proxy in another hemisphere thirty seconds after a sign-in from the office.
Closing that gap is what Entra ID Protection is for — and in most tenants I assess, it’s either unlicensed, unconfigured, or configured and then completely ignored. The last one is the worst, because it looks like coverage on a slide.
What risk actually means here
Entra ID Protection produces two distinct risk signals, and conflating them is the first mistake people make.
- Sign-in risk is the probability that a specific authentication request is not from the legitimate user. It’s evaluated in real time from signals like anonymous IP usage, an impossible-travel pattern, an unfamiliar sign-in location or device, or a token with anomalous properties.
- User risk is the probability that the account itself is compromised — most commonly raised by leaked credentials found in a breach dump that match the user, or by a pattern of risky sign-ins accumulating over time.
They drive different responses. A risky sign-in should be challenged in the moment — step up to MFA, or block. A risky user means the credential is suspect and should be rotated — force a secure password change. Wiring both to the same control (“require MFA”) wastes half the signal.
Risk is scored low / medium / high. Some detections are real-time (they can block before the token is issued); others are offline and surface minutes to hours later, which is exactly why the response can’t only be a sign-in-time prompt.
The licensing reality
This is the part that quietly blocks people: risk-based conditions require Entra ID P2. With P1 you get Conditional Access and you can require MFA, compliant device, and so on — but you cannot use sign-in risk or user risk as a condition, and you don’t get the Identity Protection detections, the risky users report, or the investigation surface.
If you’re on P1, that’s fine, but be honest about it: you have CA, not risk-based CA. Don’t put “risk-based access policies” on the architecture diagram. If you have Microsoft 365 E5 (or the E5 Security add-on), you already have P2 — I’ve lost count of the tenants paying for E5 that never turned any of this on.
Build the policies in Conditional Access, not the legacy blades
Identity Protection still exposes its own standalone “user risk policy” and “sign-in risk policy” toggles. Microsoft’s current guidance — and mine — is to build risk policies inside Conditional Access instead. CA gives you proper scoping, exclusions, report-only mode, and a single place where all your access logic lives. The standalone policies are all-or-nothing and easy to forget about.
A reasonable starting pair:
- Sign-in risk policy — for all users, all cloud apps, when sign-in risk is medium or high, require multifactor authentication. This re-challenges a suspicious authentication without locking out the legitimate user who can pass MFA.
- User risk policy — for all users, all cloud apps, when user risk is high, require a secure password change (which forces MFA first). This handles the leaked-credential case: the account is presumed compromised, so the credential gets rotated under a verified identity.
Two non-negotiable details:
- Exclude your break-glass accounts from both policies. Two cloud-only emergency-access accounts, excluded from all CA, long random passphrases in the vault, MFA via a method that doesn’t depend on the same infrastructure you might be locking yourself out of. If a risk policy ever misfires tenant-wide, these are how you get back in.
- Self-service password reset and MFA registration must already be deployed. A user-risk remediation that demands a secure password change is useless if the user has no enrolled method to prove who they are. Roll out SSPR with MFA writeback before you enforce user-risk remediation, or you’re just generating help-desk tickets.
Report-only first, every time
I said this last time about CA generally and it’s doubly true for risk policies, because the false-positive surface is larger. Atypical-travel detections fire on VPN egress changes and on the one salesperson who genuinely flew to a conference. Unfamiliar-properties detections fire after someone reimages their laptop.
Run both policies in report-only for two to four weeks. Then go into the sign-in logs and the risky sign-ins report and read what would have happened. You’re looking for two things: the rate of legitimate sign-ins that hit medium/high (your disruption budget), and whether the genuinely bad ones are actually being scored. Tune your trusted named locations and VPN ranges to drain the obvious false positives before you flip to enforce.
The detection-engineering bit nobody does
Here’s where most deployments quietly die. The policies get enforced, the dashboard turns green, and the risky users queue is never worked. That queue is not noise — it is a prioritised list of accounts the platform’s ML thinks are compromised, and every entry needs an analyst disposition.
Two things make that queue actually improve over time:
- Confirm compromised / confirm safe. When an analyst investigates a risky user or sign-in, closing it with the correct verdict isn’t just hygiene — it’s the labelled feedback that tunes the model for your tenant. Dismissing everything as “probably fine” without a verdict trains nothing and leaves real compromises sitting at medium.
- Stream the signal to where you actually triage. Pipe Entra ID Protection’s
RiskyUsers,UserRiskEvents, and the sign-in logs into Sentinel (or whatever your SIEM is). The native blade is fine for a quick look, but your SOC works from the SIEM, and risk events correlate hard with everything else there — a high-risk sign-in immediately before a suspicious inbox rule or an OAuth grant is a far stronger story than either alert alone.
If you remember one thing: risk-based Conditional Access is not a config you finish. The policy is maybe a day of work. The value is in the operational loop behind it — investigate, confirm the verdict, tune, repeat. A medium-risk sign-in that nobody ever looks at is the same as no detection at all, except now it’s on a compliance report claiming you have coverage.
Where this sits in the bigger picture
Static CA stops commodity password spray and legacy-auth abuse. Risk-based CA is how you start catching the targeted stuff — the session-token theft, the adversary-in-the-middle phishing kits that survive plain MFA, the credential that leaked in last month’s third-party breach. It is not the whole answer to token theft (that’s a conversation about phishing-resistant credentials and token protection, for another post), but it’s the layer that turns identity from a one-time gate into something that watches.
Turn it on. Build the policies in CA. Run them in report-only. Then — and this is the part that matters — actually work the queue.