A Risky Event Was Detected for a User: What the Entra ID Protection Alert Means, and the Response That Actually Closes It
If you are an IT Partner client you have seen the ticket: "A risky event was detected for user ...". Our risky-user monitor opens one for every Microsoft Entra ID Protection detection in your tenant, at no additional charge. Most are benign. The dangerous ones look the same at first glance, and in one recent case the alert that mattered was dismissed within about 90 minutes while the attacker kept mailbox access for four weeks. Here is what the alert means, where the trap is, and the sequence that closes a compromise.
What Identity Protection is telling you
Microsoft Entra ID Protection scores two things. Sign-in risk is the probability that one authentication was not the user. User risk is the probability that the identity itself is compromised; it accumulates from sign-in risk and from offline signals such as leaked credentials. Each carries a level (Low, Medium, High) and a state: At risk, Remediated (the user did something the system accepts as proof, such as completing MFA), Dismissed (an administrator called it benign), Confirmed compromised or Confirmed safe. Detection names change; check the current list on Microsoft Learn.
In our queue the common detections are atypical travel (two sign-ins from places too far apart for the time between them) and unfamiliar sign-in properties (a device, browser, network or app the user has not used before). Less common, and far more serious, are the real-time adversary-in-the-middle detection and the threat-intelligence detection for activity linked to a compromised session or stolen token. Both mean Microsoft has recognized a phishing proxy or a replayed token, not just an odd location.
The trap: a risk that remediates itself because MFA passed
The sample case in our redacted post-incident report went like this. On day one, four atypical-travel detections fired as an executive assistant signed in from a new branch office. Identity Protection auto-remediated them to Low ("User passed multifactor authentication"), and our ticket was closed because the location matched a site the customer had told us was normal. So far, correct.
Four hours later a phishing proxy submitted her password, relayed a genuine Authenticator push that she approved, and established a session. Identity Protection flagged it in real time as an adversary-in-the-middle sign-in; Defender XDR opened a High incident within the hour. But MFA had been satisfied, so the user risk had already settled at Low, and about 90 minutes later the customer administrator dismissed it. No reset, no revocation, no re-registration. The incident was never assigned.
The stolen Outlook refresh token was then replayed about three times a day from 88 residential-proxy addresses for four weeks; none of those non-interactive refreshes produced a detection, because each carried a valid MFA claim. No new ticket opened for the AiTM detection either, because the risk state was already remediated and dismissed, which is what the monitor keys on. Dismissing closes the alert, not the compromise, and it can silence the follow-ups.
"Passed MFA" is exactly what an adversary-in-the-middle attack produces. A Low or Remediated risk with an AiTM or stolen-token detection underneath it is a High incident wearing a green label. Why MFA is not enough anymore explains the mechanics.
The response that closes it
For any detection that is not obviously benign, and for every AiTM or stolen-token detection without exception:
- Decide with evidence, not the risk level. Call the user: did you approve a prompt you did not start, where were you, on which device. Read the sign-in: app, IP address and ISP, user agent against the recorded operating system, device state, and whether MFA was performed or "satisfied by claim in the token".
- Confirm compromised in Identity Protection rather than dismiss. Per Microsoft's documentation at the time of writing, confirming raises user risk to High, which lets a user-risk policy act.
- Reset the password: an admin reset, then the user sets a new one.
- Revoke sessions and refresh tokens, knowing the limit: access tokens already issued live until they expire unless Continuous Access Evaluation is in effect; in the sample the attacker's web session survived the revocation and sent a second batch. If in doubt, block sign-in as well.
- Delete every registered authentication method, including Windows Hello and passkeys, and have the user re-register on a verified call.
- Hunt persistence: inbox rules, forwarding, OAuth consents, new device registrations, added authentication methods, delegations.
- Pull 30 days of interactive and non-interactive sign-ins and group by app, IP address and ASN. Stolen refresh tokens shows the pattern.
- Open the Defender XDR incident, not just the risk: assign it, read every alert, resolve it as true positive.
- Look sideways: other users flagged the same days, the staff the attacker searched for, any admin role held.
- Close the ticket with the reason written down.
What the ticket from us looks like, and what we need from you
Risky Users and Risky Sign-ins Monitoring is included at no additional charge for IT Partner clients. Each ticket carries the user, the detection type, the risk level and state, the sign-in details (time in UTC, IP address and location, application, client, MFA result, device state) and our initial read: benign, needs the user's confirmation, or treat as compromised.
What we need back, quickly: a contact who can reach the user by phone; confirmation of travel, a new office or a new device; and approval for the actions the service page lists as customer-approved outside the pre-agreed scope: password reset, session revocation, forced MFA re-registration, blocking sign-in and Conditional Access changes. Agree that scope in advance for AiTM and stolen-token detections.
Two standing inputs make every ticket faster: a current list of your office, branch, home-worker and mobile networks, and notice of migrations, new sites or administrator changes. The service is monitoring and escalation, not full incident response, and depends on the signals and retention your licensing provides. The sample report recommends, to the tenant and to us, that High XDR incidents and AiTM detections open tickets independently of the risky-user state.
Licensing: what needs Entra ID P2, and what does not
Conditional Access needs Entra ID P1, included in Microsoft 365 Business Premium and the E3 and E5 suites. With P1 the risky users report shows only medium and high risk, without detail or history. The full reports, the risk history and the policies that react on their own (block on High sign-in risk, secure password change on High user risk) need Microsoft Entra ID P2, included in E5 and the Defender Suite add-ons and assigned per user in scope; our P1 vs P2 article has the breakdown, and the Plan Optimizer prices it as an add-on.
With P1 only, the monitor still works and a human does what the policy would have done, which is why the sequence above matters more, not less. Conditional Access Policy Implementation builds the baseline from Conditional Access policies every business should have, with the risk policies added where P2 is present.
Frequently asked questions
Should we block sign-in for every risky user?
No. Most detections are benign, and a blanket block teaches people to expect lockouts. Block when the evidence says compromised, or when you cannot reach the user and the detection is AiTM or stolen-token.
The user says it was them. Can we dismiss?
If the sign-in details agree with the user (their device, their network, MFA actually performed), yes, with the reason in the ticket. If the record shows MFA by claim in the token from an unknown network, the user's confidence is not evidence; in the sample she had approved a prompt the attacker generated.
Why did the risk drop to Low by itself?
Because the user completed MFA, which Identity Protection counts as remediation. An AiTM proxy satisfies that condition too.
Do non-interactive sign-ins raise risk?
In the sample, 95 refreshes from 88 addresses raised none, because each carried a valid MFA claim. Treat the non-interactive log as a separate hunt.
Is the monitor useful without P2?
Yes. Detections and tickets still flow; P2 adds the automatic response and the history.
Sources
- IT Partner: the redacted sample post-incident report (PDF), /samples/ITPWW540SECOT/post-incident-report-sample-bec-aitm.pdf, and its write-up at /blog/what-a-microsoft-365-post-incident-report-should-contain-lessons-from-a-bec-case
- IT Partner service pages, content/services/: ITPWW060SECOT, ITPWW240SECOT, ITPWW220MSPOT
- IT Partner blog, content/blog/new/: entra-id-p1-vs-p2-conditional-access-pim-identity-protection-compliance, why-mfa-is-not-enough-anymore-based-on-real-attack-paths, conditional-access-policies-every-business-should-have
- IT Partner subscription page: content/subscriptions/CFQ7TTC0LFK5__Commercial.json (Entra ID P2)
- IT Partner engineering notes, September 2026
- Identity Protection behavior is stated per Microsoft's documentation at the time of writing; verify on Microsoft Learn.
| Detection | Likely meaning | First action |
|---|---|---|
| Atypical travel | Two sign-ins too far apart for the time between; often a VPN or real travel | Confirm with the user; compare device and client to their baseline |
| Unfamiliar sign-in properties | A device, browser, network or app the user has not used before | Confirm with the user; MFA by claim from an unknown network means compromised |
| Anonymous IP address | Sign-in through an anonymizer or VPN exit | Ask whether the user runs a VPN; block if not |
| Leaked credentials | The password appeared in a credential dump | Reset now, whatever the user says |
| Adversary-in-the-middle (real time) | The user completed MFA through a phishing proxy; the session is the attacker's | Confirm compromised, reset, revoke, re-register MFA, open the XDR incident |
| Compromised session or stolen token | Microsoft threat intelligence has seen this session used maliciously | As for AiTM, then hunt the non-interactive log for replay |
| Suspicious inbox rules or forwarding | A rule or forward that hides or exports mail was created | Remove it; treat the account as compromised until proven otherwise |
Key takeaways
- A risky-user ticket reports a detection with a level and a state; the state is what people act on, and the easier one to get wrong.
- A risk can auto-remediate to Low because the user passed MFA; through an adversary-in-the-middle proxy that is exactly what the attacker made her do.
- Dismissing closes the alert, not the compromise, and a dismissed or remediated state can suppress follow-on tickets; confirm compromised instead.
- The response is a sequence: reset, revoke, re-register MFA, hunt persistence, review 30 days of sign-ins, resolve the Defender XDR incident.
- Risk-based Conditional Access policies need Entra ID P2 for the users in scope; without P2 the monitor still works and the sequence is done by hand.
Clients receive Risky Users and Risky Sign-ins Monitoring at no additional charge; agree the pre-approved response scope with us before the next ticket, not during it. If a detection has already become a compromise, Security Managed Service: Incident Response is a $700 fixed-price investigation with a written report, and Conditional Access Policy Implementation, $2,950 per project, puts in place the risk-based and device policies that turn the next alert into a block.
Questions this article didn’t answer?
Thirty minutes with Mike — our CEO, not a sales rep. Bring the hard version of the question.