Segmentation For Risky User/Risky Sign In Policy

Copper Contributor
I started for a company that runs primarily on an Azure and Microsoft Defender environment.  They get tons and tons of alerts for Risky User activity.  Recently I looked at their Risky Users policy and found that it was set to Who All Users, Severity All Low, High, and Critical alerts, Mitigation Block/Lockout.  So basically, the company janitor with extremely limited access along with the CEO are all dumped into the same bucket.  For this reason they get tons of these alerts with the users triggering the alerts getting locked out.  The Risky User alerts/blocks is literally crippling their productivity.
 Is the best practice for this not to have users segmented and then assign different levels of the Risky User policy to them? How does one go about methodically and systematically setting up this segmentation?
The company is the type that is made up of multiple smaller companies added from acquisitions.
5 Replies

Hello @egrizzly365 

To apply different Risks policies to various user groups (scopes), you should manage them with Conditional Access Policies. By doing this, you can tailor controls for users based on their roles within the company and manage exclusions more effectively. Check this article Risk policies - Microsoft Entra ID Protection | Microsoft Learn


Thanks @MatejKlemencic. I meant how do you go about determining which groups will get segmented? Meaning, if there are 3 users James Dean, John Doe, and Jane Doe with different job roles how do you determine which job roles get put into a higher or lower risk segment?

Hi @egrizzly365 

I don't use multiple policies for different groups. Instead, I configure two conditional access policies: one for risky sign-ins and another for risky users. In these policies, I block access if the risk level is medium or high. For low-risk levels, I only notify administrators and don't implement any blocking actions. Additionally, I set up an exclusion rule to prevent access from being blocked if a user connects from a trusted device (such as an Intune compliant device) or a trusted site. This approach helps avoid false positives from blocking legitimate sign-ins. Besides blocking, you can also choose different actions, such as requiring MFA or a password change.

Thanks gotcha. So I take it you don't get the insane barrage of Blocked users who were flagged by the Risky User/Sign-in policies then?


Correct. I've done multiple deployments without experiencing significant issues.