Microsoft Flagged the Breach. Nobody Was Listening: Wiring Risky Users Into Your Alert Flow

An MSP we spoke with in July 2025 had a client wire $500,000 to a fraudulent bank account after a user's credentials were phished. The painful part: Microsoft's machine learning almost certainly flagged the compromise as it happened. Nobody saw the flag, because by default, nobody is told. Risky user detections are one of the leading indicators of account compromise in Microsoft 365, and out of the box they go nowhere.

This guide covers three things: how Microsoft decides a user is risky, how to route those detections into your PSA or ticketing system, and the single policy we would deploy first to prevent the compromise from happening at all.

Anatomy of a $500,000 detection that nobody saw#

Here is how that breach plays out, step by step:

1. The CEO receives a phishing email, a fake message that looks real.
2. The email contains a link to a counterfeit Microsoft sign-in page.
3. The CEO enters username, password, and MFA code.
4. The attacker captures the session token (token theft) and is in.

From there the attacker:

• Logged into the account
• Set up inbox rules to hide their activity
• Added an app called eM Client to download all the mail
• Registered their own MFA method to stay in the account
• Found the person who handles money and posed as a vendor
• Sent the "our bank details have changed" email

And $500,000 was gone.

Rewind to the first step, though. The moment the user hit the fake Microsoft page, they were authenticating from an IP and location unusual for them, which should flag a risk detection in Entra. That detection is the trigger for an investigation before anything else happens. That is the power of Microsoft's threat intelligence around risky users, and the reason the rest of this guide exists.

How does Microsoft decide a user is risky?#

Microsoft evaluates billions of logins every day for signs that an account is in trouble: stolen passwords in use, sign-ins from locations that make no sense, or users landing on counterfeit Microsoft pages.

The machine learning looks at signals like:

• Where the person is signing in from
• What device or browser they are using
• Whether the pattern matches their history or looks strange

Detections are classified low, medium, or high based on likelihood. Take a company where everyone normally signs in from Denver. If Tony signs in from Boise eight hours after his last sign-in, that is probably a vacation, not an incident. If Tony signs in from Tokyo an hour after signing in from San Diego, that is impossible travel, and it gets flagged high.

Getting detections into your PSA#

Detection without notification is just a log entry. Wire the alerts to where your team works:

1. In the Defender admin center, go to Settings > Microsoft Defender XDR
2. Click Email notifications. Modify the existing rule or create a new one.
3. Update your notification rules so the tenant name is attached and the right services are selected. Severity is the tricky part: including low and informational generates a lot of noise, but some valuable alerts, like the creation of an inbox rule, are informational by default. To work around this, go to Email and Collaboration > Policies and Rules > Alert Policies and create your own rules at a higher severity.

1. On the recipients page, add the email connector for your PSA.

Now a risky user detection becomes a ticket with an owner instead of an unread portal notification.

What happens automatically at high risk? On Business Premium, nothing.#

Here is the uncomfortable licensing reality, what we would call the Microsoft Paywall Problem. If a tenant is on Business Premium and a user is detected at high risk, the default action is: nothing. The user is detected and the rest of the compromise plays out anyway. Better risk detections and automated responses sit behind Entra ID P2 or an E5 plan.

In a real event, the first moves are blocking the user's sign-in or resetting their password to contain the account until the breach is confirmed mitigated. Without automated detection and response, MSPs face both a scalability problem (you cannot manually watch every alert across every client) and a speed problem (damage compounds while you react). This gap is exactly why many MSPs layer on third-party tools like Huntress, Blackpoint, or SaaS Alerts.

If the tenant does have P2, E5, or the E5 Security add-on that bolts onto business plans, configure:

• Require a password reset at medium to high user risk (opens in new tab), and/or
• Block the account at high risk. This one is tricky: a false positive can lock an executive out while they travel overseas, so have a fast response path ready. We think over-protection is the right default here, but at minimum enforce the password resets.
• Automatic attack disruption (opens in new tab)

Reference reading:

• Premium user risk detections in Entra ID Protection (opens in new tab)
• How to investigate risky users (opens in new tab)

The policy that makes most of this moot: require a managed device#

Alerting and response are reactive. The better position is policies that stop the compromise from starting, and the one we would deploy first is a Conditional Access policy to require a managed device. It prevents token theft via adversary-in-the-middle phishing outright, and it blocks the persistence play where an attacker registers a new MFA method and signs back in from their own machine.

Prerequisites:

• Devices are Entra Joined, Hybrid Joined, or Entra Registered

Conditional Access policy settings:

• Users: Include all users
• Users: Exclude break-glass account, plus guest or external users (service provider users)
• Target resources: All
• Conditions > Device platforms: Windows

If hybrid:

• Grant: Grant access, require Microsoft Entra hybrid joined device

If cloud only:

• Conditions > Filter for devices: Exclude, Trust Type, Entra Joined
• Grant: Block

The takeaway#

Risky users in Microsoft 365 are not just a dashboard. They are your early warning system. Route the alerts where your security team will actually see them, then put the managed-device policy in front so most of those alerts never need to fire.