We've used Privileged Identity Management for more than a year, and it works well for native Entra ID roles and Azure resources. The problem is the legacy and custom applications we've moved into Azure that still manage authentication and authorization themselves. PIM can't see what permissions users receive inside those applications, so access can gradually expand outside the systems we're reviewing.
Is anyone tracking privilege creep across both Entra/Azure permissions and those custom or legacy app roles as a metric over time? I'd like to detect access drift before the next formal review, preferably with visibility beyond the Entra boundary.
5 Answers
We had a similar setup with legacy applications using SQL role tables and local groups. We built nightly exports of each user's application roles into a Log Analytics custom table, then combined that with Entra access reviews. Another option is to mirror legacy role membership into Entra security groups solely for review visibility, even if the applications don't authenticate through those groups.
The most useful metric for us was entitlement accumulation: how many applications someone can access versus how many they've actually used in the past 90 days. Dormant access became a removal candidate, which caught things a normal PIM review missed. It isn't elegant—we use a small mix of Functions, Logic Apps, and maintained reports—but it turned an annual cleanup into a recurring drift report. Fully custom authentication is essentially a data-pipeline problem unless the application can provide its own access data.
Make expiration mandatory for every elevated role assignment. It won't clean up existing access, but it prevents new standing privilege from accumulating indefinitely.
PIM can cover Azure RBAC as well, but anything outside Entra is much harder to track with native tools. If an application has its own authentication or role database, you'll need an integration, export, or application-side access review to see those permissions.
The biggest gaps are usually custom application roles, resource owners who were never made PIM-eligible, service principals with broad Graph permissions, guest accounts, VM local administrators, and other paths that don't appear as normal Entra role assignments. Inventory those surfaces regularly and track last-used time, standing privilege, and who can escalate to Owner—not just PIM activations.
For applications with their own authentication store, there isn't a clean way to get complete telemetry without cooperation from the app. Either add an access export/review process or move authorization into Entra where practical.
The key distinction is whether the application uses Entra for authentication. If it does, sign-in logs can at least show who still uses the application. If it has a separate authentication and authorization system, you'll need a custom connector or an export from that system to track roles and usage.

Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures