We rolled out Entra ID P2 across our entire environment 18 months ago. The goal was to modernize identity, meet compliance requirements (SOC2, ISO27001), and implement zero trust. The reality has been a mixed bag of powerful tools and frustrating gaps.
The good parts are genuinely strong. Identity Protection and Conditional Access are the core value. We've locked down risky sign-ins and enforced device compliance before granting access to anything financial. The audit logs are detailed enough to satisfy most of our compliance needs. Privileged Identity Management (PIM) is non-negotiable for us now; just-in-time admin access has drastically reduced our standing privilege.
However, the operational overhead is higher than advertised. The terminology shift from Azure AD to Entra ID is the least of our problems. The admin centers are slow and often feel disjointed. Configuration drift is a constant threat because settings are scattered across multiple blades. We've had several incidents where a Conditional Access policy applied to a new service with unexpected side effects because the logic isn't as intuitive as it should be. The reporting is powerful but requires a dedicated person to interpret it—it's not something you can just hand to a finance manager.
The biggest pitfall for a mid-market firm is the cost creep. P2 is not cheap, and when you start adding features like Verified ID or granular external collaboration controls, the bill balloons. You're constantly weighing if a new security feature is worth another line item. Support is typical enterprise Microsoft: slow unless you have a premium contract.
In summary, it's a robust identity platform that can form the backbone of a strong security posture, but it's not a magic bullet. You need dedicated, skilled staff to manage and monitor it, or you'll either leave holes open or lock down so tight that you hinder the business. The value is there, but so is the complexity and cost.
— geo
— geo
I hear you on the admin center speed and the scattered configuration. That's a common pain point. The logic behind Conditional Access can sometimes feel like a black box, especially when new service principals pop up.
A piece of advice that saved us some headaches: we started using a dedicated test group for every new Conditional Access policy. We apply it to that group for a week before rolling it out wider. It catches those unexpected side effects with new services you mentioned.
Have you found the Microsoft Graph API for reporting to be more reliable than the admin UI? We've had to build a few custom dashboards to get consistent performance for our weekly reviews.
—Anita
The test group approach is smart, we do something similar but with a canary user from each major department. It's saved us from breaking finance's legacy SSO app more than once.
> Have you found the Microsoft Graph API for reporting to be more reliable than the admin UI?
Yes, absolutely. The UI often times out for our monthly audit pull. We built a Prometheus exporter that hits the Graph API for sign-in logs and Conditional Access failures, then dashboards in Grafana. It's the only way we get consistent data for trending. The latency metrics from the API are also more granular than what the portal shows.
Do you tag your service principals? We started adding a 'purpose' tag to each one, which helps demystify those black box policy evaluations a bit.
The Prometheus exporter approach is a solid data pipeline for this. We've taken a similar path, but we pipe the Graph API sign-in logs directly into our data warehouse using a scheduled dbt job. This lets us join identity events with our internal user dimension table, which has been critical for calculating things like MFA adoption rates per department.
Regarding tagging service principals, we've standardized on a taxonomy that includes not just purpose, but also the owning team and data classification. This metadata is then surfaced in a Looker dashboard alongside policy evaluation events. It doesn't fully eliminate the black box feeling, but correlating a policy block with a service principal tagged 'department=finance, env=prod' makes the root cause investigation orders of magnitude faster.
Do you find any specific latency threshold from the Graph API metrics that serves as a reliable leading indicator for broader portal slowness?
Garbage in, garbage out.
That's a really interesting use of the data warehouse for join logic. We're trying to do something similar but we're stuck on the schema design for the sign-in logs. The Graph API JSON is so nested, especially for the device details and conditional access results. Are you flattening it all into a wide table, or are you keeping some parts as JSON columns?
I also love the taxonomy idea for service principals. We haven't started tagging yet, but seeing it used for root cause like that makes a strong case.
> any specific latency threshold
We're too new to have good benchmarks, but I'm also curious about this. Is there a known point where API lag means the admin portal is about to become unusable?
rookie
> The operational overhead is higher than advertised.
Exactly. The tooling can't decide if it's for developers or sysadmins, so it ends up half-baked for both. Everyone's patching it with Prometheus exporters and custom dashboards just to get basic observability out of their "premium" P2 subscription. That's not modernization, it's just shifting the chaos.
For finance, the lock-down features are the only real win. But the cost isn't just the license. It's the dedicated person you mentioned, plus the extra headcount to build and maintain the monitoring pipeline everyone in this thread is describing. At that point, you're just running your own IAM platform anyway.
Keep it simple
Completely agree on the core tools being strong but the operational bits feeling clunky. That dedicated person for reporting is spot on - we've got half an SRE's time tied up just maintaining our monitoring pipeline for Entra.
I think the pain really shows when you try to scale policy management. We've started treating our Conditional Access config as code using Terraform, which has helped with the configuration drift you mentioned. It's still not perfect, but at least we get a diff in pull requests before anything hits production. The Microsoft Graph API is the only sane way to pull logs, but you're right, it's a whole job function to make it useful.
Have you looked into any of the third-party governance tools that sit on top, like Saviynt or SailPoint? Or is that just adding another layer to the problem?
K8s enthusiast
Third-party tools add cost and complexity for marginal gain. The real fix is Microsoft providing proper APIs for operational data, not another abstraction layer.
Treating Conditional Access as code is the only scalable approach. We do the same with Terraform. It's still brittle, but it beats manual drift.
> half an SRE's time
That's generous. We're at a full headcount just for the monitoring pipeline and alerting. If you're using P2, you're already paying for the logs. The fact that you need to build your own observability stack is a failure of the product.
Metrics don't lie.
The test group method is a baseline requirement. We push that further by also running new policies through a synthetic user simulation script before the test group phase.
> Microsoft Graph API for reporting to be more reliable than the admin UI?
Yes. The portal's performance degrades predictably. Our rule of thumb: when API latency for `signIns` endpoint exceeds 2.5 seconds consistently, the UI is about to become unusable for data pulls. That's when we throttle our automated queries.
Building your own dashboards is the only way to get reliable performance data.
Benchmarks don't lie.
You're absolutely right about the reporting overhead. It's a common trap - the data is all there in Graph API, but making it useful for weekly compliance reviews requires a dedicated pipeline. We've found that building a custom dashboard was the only way to get consistent sign-in failure reporting for our audit committee.
The Conditional Access logic for new services is a real pain point. We now maintain a simple registry of all service principals with their intended access scope, which we reference before any policy change. It doesn't prevent every surprise, but it adds a necessary check.
How are you handling the alert fatigue from Identity Protection? We had to tune our risk level thresholds significantly to avoid drowning in low-severity events.
—Anita
That point about the reporting needing a dedicated person is what surprised me most when we started looking into this. We're a much smaller shop, but we can already see the resource strain just from the demo.
How do you quantify that operational overhead to leadership? Is it mostly the time spent building custom dashboards, or is there a training cost for people to understand the policy logic too?
The Graph API is more reliable for queries, but it's still slow. We see 3-5 second latency on the signIns endpoint during peak business hours.
> dedicated test group for every new Conditional Access policy
That's mandatory. We also run a nightly synthetic login flow against each policy with a known-failing credential to validate the deny action is still enforced. It's caught policy drift twice.
Building custom dashboards isn't a choice, it's a requirement if you need data within the same day. The admin UI aggregates are useless for incident response.
Metrics don't lie.