Okay, I need to vent and also get some real advice. My team's Entra ID (still feels weird not saying Azure AD) is blowing up our dashboards and inboxes with 'risky sign-in' alerts. We've gone from having a useful signal to just pure noise. I'm convinced our security folks are now just instinctively ignoring everything because there are *so many* false positives or low-consequence events.
It feels like a classic UX problem, honestly. The tool is doing its job detecting anomalies, but the presentation and workflow for handling them is failing. We're losing the actual 'risky' in the sea of 'unusual but probably fine'.
What are you all doing to tame this? I know the basic levers—adjusting the risk detection policies, integrating with Conditional Access for auto-remediation—but I'm hitting a wall. Have you found a sweet spot for policy settings that doesn't leave you exposed but also doesn't flag every employee logging in from a coffee shop? Are there specific reports or workflows outside the default alerts that give you a clearer picture?
I'm especially curious about how you handle the triage process. Is there a way to group or filter these alerts that actually works for your team? I'm drowning in context-switching and it's killing our efficiency.
Hey, I feel you. I'm Alex, a community lead for a B2B SaaS company around 300 people, and we run our entire identity stack on Entra ID. Our security team of three was in the exact same noise spiral about a year ago.
Here's what we learned and the criteria we used to evaluate our approach:
**Triage Workflow:** The native alerts lack grouping. We had to look at each risky sign-in as a discrete event. The only way we made it manageable was by building a Power Automate flow that aggregated similar alerts (same user, similar risk level, same source IP range) into a single daily digest for review. It took about two weeks of dev time to get right.
**Policy Tuning Sweet Spot:** The default policies are incredibly sensitive. We found turning off "familiar sign-in properties" for our sales and traveling teams cut about 60% of our noise. We also increased the risk level required for a real-time alert to 'medium' and rely on the 'risky users' report weekly for lower-level stuff. It's a balance, but that shift was crucial.
**Integration for Auto-Remediation:** This is where Entra ID can work well, but it's a set-it-and-forget-it piece. We have a Conditional Access policy that forces a password change for 'high' risk and requires MFA for 'medium' on sensitive apps. The catch is you need Entra ID P2 licenses for that, which runs about $9/user/month on top of everything else.
**External Filtering & Reporting:** The built-in reports weren't enough for us. We now pipe the Entra ID sign-in logs to our SIEM (Sentinel) and have a custom dashboard that filters out known travel hubs and our corporate VPN IPs. The setup took a few days, but the ongoing visibility is much better. Without a SIEM, you're stuck with the portal's limited views.
My pick for your situation really depends on two things: your license level and if you have a SIEM already. If you have Entra ID P2 and a SIEM, I'd recommend going the Sentinel route for aggregated dashboards. If you're on P1 or lower, your immediate win is adjusting those detection policies and building a simple aggregation workflow. What's your current license tier and do you have a log aggregation tool in place already?
You're right about it being a workflow problem, not just a detection one. We hit the same wall.
Your comment about grouping hits the nail on the head. The default single-event view is useless at scale. We ended up pushing everything to a dedicated SIEM dashboard. The key was filtering *before* it hits human eyes. We set rules to automatically suppress alerts for:
* Specific low-risk user groups (like sales)
* Known corporate travel IP ranges
* Specific MFA methods we deem secure
That cut our daily review volume by about letter80%. We still see the high-risk stuff.
Policy tuning alone never solved it. You have to build a filter layer and only escalate what actually needs a decision.
Prove it with a benchmark.