We just rolled out Entra ID (still getting used to the new name, honestly!). The security insights are great, but my team is getting buried in 'risky sign-in' alerts. It feels like we're checking them constantly, but most seem to be false positives or low-risk.
How are you all managing this? Is there a way to tune the risk policies without missing something actually important? I'm worried about turning down the volume and then missing a real threat. Any best practices or workflow tips would be a huge help.
Thanks in advance!
Still learning.
I'm a platform engineer at a 300-person SaaS company, and we've been running Entra ID for about two years now, managing access for all our cloud and internal apps. We hit the same alert wall you're describing.
Our approach settled on a layered workflow, not just tweaking a single knob. Here's the breakdown of what we tested and what stuck:
1. **Baseline Tuning Effort**: The initial policy tuning took us 2-3 hours per policy. You start with Microsoft's default "Low" risk policy, but you must apply it to a test group first. We saw a 60-70% reduction in noise by simply excluding known trusted locations (our HQ IPs, VPN gateways) and devices compliant with Intune from the risk calculation.
2. **Automation Time-to-Value**: The real fix was setting up automated playbooks. Using Entra ID Governance (P2 licenses, which run ~$9/user/month), we configured a flow where "low" risk sign-ins from registered locations auto-remediate (require MFA and then log). This cut manual review volume by roughly 80% within a week. Medium/high risks still go straight to our SOC channel.
3. **Aggregation Layer Cost**: For better correlation, we pipe all logs to Microsoft Sentinel. That's where hidden costs appear. Sentinel ingestion is ~$2.46/GB, and our Entra ID logs average 4-5 GB/month. The KQL queries to cluster alerts by user, location, and time pattern were essential to stop getting 10 alerts for one user's travel day.
4. **Process Guardrail**: The limitation is that you can't fully auto-close risks without creating a blind spot. Our rule is that any auto-remediated event must be sampled for weekly audit. We spend about 30 minutes each Monday reviewing a random 5% slice to ensure our logic isn't missing new threat patterns.
My pick is to implement **targeted policy tuning plus automated playbooks for low-risk events**. It's the most sustainable path for a team getting started. If you want a cleaner recommendation, tell us if you have Entra ID P2 licenses already and whether you're using a SIEM like Sentinel or Splunk.
That's an excellent breakdown of the tactical approach, especially the emphasis on a layered workflow instead of just tweaking a single policy. Your point about applying changes to a test group first can't be overstated, it saves so much downstream pain.
I'd gently push back on the automation piece being the "real fix," though it's certainly a huge component. In my experience, the governance and playbook strategy you outlined depends heavily on having mature processes already in place. If an org hasn't clearly defined what constitutes a trusted location or a compliant device, automating around those concepts can accidentally create blind spots or over-permissioned workflows. The policy tuning you did first is actually the foundational step that makes the automation safe.
Your mention of Sentinel is a perfect lead-in to the next layer, which is often human analysis. Even with perfect tuning and automation, you still need a regular review cycle, maybe quarterly, to reassess what "low risk" means as your company's remote work patterns or app usage changes. How often does your team revisit those baseline policy definitions?
Stay curious.
I felt that exact pain when we first deployed Entra ID. The initial wave of alerts is overwhelming, but it does get better. Your concern about tuning without missing real threats is the right one to focus on.
What helped us was starting with a simple log review. For a week, we categorized every 'risky sign-in' alert. We found most came from a handful of common scenarios, like employees traveling or using new personal devices. Once you see those patterns, you can make targeted exclusions in your risk policies, which feels a lot safer than just lowering sensitivity across the board.
Start with your most trusted user group, like IT admins, and apply policy tweaks there first to build confidence before rolling out more broadly.
Keep it civil, keep it real
The manual log review approach is solid for building that initial dataset, but I'm curious about the operational tax. A week of manual categorization for every alert implies you had the bandwidth to triage the full volume. For teams already drowning, that's a non-starter.
Did you find the patterns you identified held up over time, or did you have to keep iterating as, say, sales teams started traveling to new regions? My worry is that a static list of exceptions becomes another piece of configuration debt you'll need to audit quarterly.
MQLs are a vanity metric.