4 min read

Getting Started with Risky Users in Microsoft 365

Picture of Nick Ross Nick Ross : Jul 25, 2025 10:56:57 AM

Microsoft 365 Security Use Case

Getting Started with Risky Users in Microsoft 365

Risky user detections are one of the leading indicators of account compromise in Microsoft 365. By default, you will not get alerted as an MSP for a new risky user. I just talked to an MSP last week who had a client that wired 500k to a fraudulent bank account after the user account was compromised. If they had received and responded to the risk detection, this might have been avoided. In this article, I will walk you though:

Understanding how Microsoft detects risky users and sign-ins
How to set up alerts to go to your PSA or Ticketing System
The top policy I would put into place to prevent user compromise

Understanding how Microsoft detects risky users

Microsoft is watching for signs that something might be wrong with a user’s account. They check billions of logins every day to look for danger.

This danger could come from things like:

Bad guys using stolen passwords
A login coming from a place that doesn’t make sense
Someone using a fake Microsoft page to trick a user

Microsoft uses machine learning to look at things like:

Where the person is logging in from
What kind of device or browser they are using
If they’ve done this before or if it looks strange

How Microsoft Decides Risk: Low, Medium, or High

When we talk about likelihood, this is how they are going to classify a detection as Low, Medium, or High Risk. Lets say we have this company, Stark Industries and normally users are all signing in to their Microsoft account from Denver, CO. If a user, Tony, goes on vacation for a week and signs in from Boise, Idaho but it is 8 hours after his last sign-in, this may not really signal any risk. On the other hand, if Tony signs in to Tokyo, Japan an hour after signing in from San Diego, that should cause a higher risk to be flagged as that is impossible travel.

blog_riskyusers_2

A Real Breach Example

blog_riskyusers_3

A company got tricked and lost $500,000.

Here’s how it happened:

The CEO got a phishing email — a fake message that looked real.
The email had a link to a fake Microsoft page.
The CEO entered their username, password, and MFA code.
The bad guy used this to steal their token (this is called token theft).

Now the attacker:

Logged into the account
Set up inbox rules to hide what they were doing
Added a sneaky app called eM Client to download all the emails
Registered their own MFA so they could stay in the account
Found the person who handles money and pretended to be a vendor
Said: “Hey, our bank info has changed. Send money here.”
And just like that, $500,000 was gone.

Now if we rewind and take a look at what is going on behind the scenes: At the moment the user clicks on the malicious link taking them to the fake Microsoft webpage, they are hitting an IP and location that should be unusual than what they normally do which should flag a risk detection in Entra. This is what should trigger an investigation before anything else ever happens and this is the power of Microsoft’s threat intelligence with Risky users.

Set up Alerts to PSA

In the Defender Admin Center, go to Settings>Microsoft Defender XDR
Click on email settings. Modify the existing rule or create a new rule
Update your notification and rules to ensure the tenant name is attached and the services for alerts are detected. The alert severity is tough given that including low and informational will generate a ton of noise but alerts like the creation of an inbox rules by default are informational. To overcome this, you can go to Email and Collaboration>Policies and Rules>Alert Policies and create your own rules that follow a higher severity.
On the recipients page, add you email connector for your PSA.

blog_riskyusers_4

The Microsoft Paywall Problem (MPP)

blog_riskyusers_5

What action is taken by default even if the user is detected with high risk? In most cases (especially if you are just on licensing like Business Premium)…nothing. Thats right. The user will be detected and the rest of the compromise will play out.

This is what brings us to the Microsoft paywall problem. In order to get better risk detections and automated responses to risk, we need to be on higher levels of licensing. Aka Entra P2 or an E5 plan. In these events, one of the first things you would want to do is either block the user sign in or reset their password. In doing so you can stop or mitigate things going on with the account until you ensure the breach has been mitigated.

As MSPs without automated detection and response, we have both a scalability problem (i.e. we can’t potentially monitor all of the alerts being generated across all clients) and we increase risk of damages by not being able to respond fast enough. This is why people turn to purchasing 3rd party tools to layer on like Huntress, Blackpoint, and SaaS alerts which solve for this gap.

If you do have E2 or E5 (or the E5 add-on that can be bolted on to business plans) you can configure the following:

Require a user reset their password with Medium to High Risk AND/OR
Block the user account with High Risk
- This one is tricky given if its a false positive and you lock an executive out because they are traveling overseas on a business trip, you better have a way to quickly respond. I think it better to be over protective here but at minimum you should enforce the password resets.
Automated Attack Disruption
P2 Risk Detections: What are risks in Microsoft Entra ID Protection – Microsoft Entra ID Protection | Microsoft Learn
Investigate Risky Users: Investigate risk Microsoft Entra ID Protection – Microsoft Entra ID Protection | Microsoft Learn

The top policy to prevent user compromise

Imagine a world where you weren’t reactively responding to account breaches and instead, had proper policies in place to prevent them altogether? While it sounds very “perfect world”, there are a few policies that you can put into place that could stop a majority of these attacks in their tracks. Today I will talk about one of my favorites that is very achievable for most organizations. Its a conditional access policy to Require a Managed Device. This policy actually prevents things like token theft via AiTM phishing and would prevent use cases where an attacker is maintaining persistence by doing something such as registering another MFA method and trying to resign back in.

Prerequisites:

Devices are Entra Joined, Hybrid Joined, or Entra Registered

Conditional Access Policy Settings

Users> Include All Users
Users>Exclude Break Glass account + 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

blog_riskyusers_6

Final Takeaway

Risky Users in Microsoft 365 aren’t just a dashboard — they’re your early warning system. Configure these alerts for your security team to review and consider placing more advanced protections in place.