Excessive permissions are not an access management oversight. They are a symptom of treating identity as an operational task rather than an architectural one. In multi-subscription Azure environments, that distinction has material consequences.
When the audit arrives
When an organisation reaches 8 or more Azure subscriptions, a pattern emerges that is almost universal. The security audit arrives. The auditors pull an access report. And somewhere in the review, someone in IT leadership sees it for the first time: Contributor assigned across dozens of resources, service principals with Owner rights that nobody can fully account for, and Entra ID groups created for a project three years ago and never removed.
The instinct is to treat this as an access management problem. Tighten a few assignments, remove some stale principals, run a cleanup script. But the audit finding is not the problem. It is the signal that the underlying permission model was never designed as an architectural concern. It was delegated to operations, handled through tickets, and allowed to accumulate.
In a single-subscription environment, that approach is survivable. In a multi-subscription estate with overlapping teams, shared services, and production workloads, it becomes a structural liability.
How the model drifts
Consider a composite pattern that appears consistently in growing Azure environments. An engineering firm running 14 subscriptions across two business units. Landing zone established two years prior. The platform has evolved since then: new regions, additional application teams, a shift to containerised workloads. The identity model has not evolved with it.
Observable symptoms:
Service principals with Owner rights at the subscription level, created during an early migration, never scoped down
Contributor assignments granted to individuals during incidents, never reviewed
No formal PIM configuration, despite Entra ID P2 licensing being in place
Access reviews either not configured or consistently waived under operational pressure
No documented privilege escalation process for platform engineers
Dedicated platform engineering for organisations that have outgrown ad-hoc DevOps. Architectural ownership, governance discipline, and Infrastructure as Code delivered under a defined engagement model.
Identity treated as an operational task, not an architectural decision
No defined role design standard across the management group hierarchy
Privilege elevation handled informally, without audit trail or approval workflow
No ownership model for Entra ID groups and service principals
Access reviews seen as compliance overhead rather than a governance mechanism
The result is a permission model that has drifted from its original intent. Nobody made a deliberate decision to create an insecure environment. The environment became insecure through accumulated decisions made under time pressure, without an architectural frame to constrain them.
What accumulates quietly
Privilege sprawl does not create immediate incidents. It creates exposure that compounds over time.
The direct risks are familiar to security teams: lateral movement potential from overprivileged service principals, difficulty attributing changes during an incident, and audit findings that grow in remediation cost with every month of accumulated drift.
The less visible risks are more significant for platform teams. When nobody is confident about who has access to what, change management becomes conservative. Engineers escalate permissions informally because the formal path does not exist or is too slow. Subscription onboarding stalls because the RBAC model for a new workload has not been defined. Platform engineers spend engineering capacity on access requests rather than architectural work.
The audit finding eventually forces action. But by that point, the remediation effort is large, the access history is incomplete, and the root cause still has not been addressed.
Treating identity as a platform concern
The shift required is not technical. It is architectural. Identity must be treated as a platform concern, not an operational one. That means designing the permission model as a deliberate structure and maintaining it through the same discipline applied to any other platform component.
Role design at management group scope. In a multi-subscription environment, role assignments should be anchored to the management group hierarchy, not applied ad hoc at the subscription or resource group level. The management group structure defines inheritance boundaries. Role design should follow those boundaries: platform engineers hold elevated access at the platform management group, application teams hold scoped access within their workload subscriptions, shared services follow their own model.
Custom role definitions are warranted where built-in roles grant excessive permissions for a specific function. A pipeline identity that needs to write to a storage account does not need Contributor at the subscription level. Defining that scope precisely is an architectural decision, not a configuration detail.
PIM as the elevation model. Privileged Identity Management should be the standard path for any rights that carry meaningful risk: Owner, Contributor at subscription level, User Access Administrator, and any role that touches security or networking configuration. Standing access at those levels should be an exception, not the default.
PIM activations provide the audit trail that standing access cannot: who requested elevation, what justification was given, how long the elevation was active. Over time, that trail is the basis for access reviews that are substantive rather than ceremonial.
The configuration model matters. Activation requirements should be appropriate to the role: approval required for the most sensitive assignments, justification and MFA for others. Maximum activation durations should be set deliberately, not defaulted. The PIM configuration is itself an architectural decision.
Break-glass accounts as a defined pattern. Every Azure estate needs emergency access accounts that operate outside normal authentication flows. The design of those accounts, how they are secured, when they are used, and how usage is monitored, is an architectural responsibility. Break-glass accounts are not an afterthought. They are part of the identity architecture.
Access reviews as a governance mechanism. Entra ID access reviews should be configured for all privileged assignments and for Entra ID groups used for RBAC. Review cadence should be appropriate to the sensitivity of the role: quarterly for high-privilege assignments, semi-annually for standard operational access.
Reviews are only effective if they are acted upon. A review process that consistently waives findings is not a governance mechanism. The review findings need to feed a remediation process, and that process needs ownership.
Where organisations go wrong
Several patterns appear repeatedly when identity has not been treated as an architectural concern.
Licensing PIM without configuring it. Entra ID P2 includes PIM, but the capability does not activate by default. Many organisations are paying for PIM licensing while their most sensitive role assignments remain permanent. The gap between licensed and configured is where the audit finding lives.
Using Entra ID groups for RBAC without lifecycle governance. Groups are created for a project, scoped to a subscription, and then persist indefinitely. When group membership is not reviewed and group lifecycle is not managed, the permission model drifts independent of any individual access change.
Treating service principal access as technical debt. Service principals with broad permissions are created during implementation phases and never revisited. In a multi-subscription environment, a service principal with Contributor at subscription scope represents a significant attack surface if the associated credential is compromised. Scoping service principal access precisely and reviewing it regularly is not optional.
Conflating break-glass with admin convenience. Break-glass accounts exist for emergency access when standard authentication is unavailable. They are not a workaround for MFA friction or a backup account for privileged operations. Treating them as such undermines both their purpose and the security model they are meant to protect.
Who owns the permission model
Identity governance does not maintain itself. It requires defined ownership, regular review cycles, and a clear process for handling exceptions.
In practice, this means the platform engineering function owns the permission model in the same way it owns the landing zone or the IaC standards. Role design is documented. Assignments are version-controlled where tooling allows. PIM configuration is reviewed as part of platform governance cycles. Access reviews are treated as engineering work, not compliance paperwork.
Without that ownership model, the permission model reverts to drift. People get access because they need it, and access is not removed because removal requires effort and context that nobody has tracked.
The question to ask is not whether the current access model looks reasonable. It is whether the process exists to keep it reasonable over time.
A diagnostic
If these questions do not have clear, documented answers, the identity model is not operating as an architectural component:
Who is accountable for reviewing and approving privileged role assignments?
Which roles are eligible for PIM activation, and what are the activation requirements for each?
How are service principal permissions scoped and reviewed?
What is the access review cadence for high-privilege assignments, and who acts on the findings?
Where are the break-glass accounts documented, and when were they last tested?
These are not compliance questions. They are platform engineering questions. The answers describe whether identity is being managed or governed.
Conclusion
The audit that reveals Contributor access everywhere is not evidence of a security failure. It is evidence that identity was never treated as an architectural responsibility.
In Azure environments at scale, the permission model is as much a platform concern as the management group hierarchy or the IaC standards. It requires the same discipline: deliberate design, documented standards, defined ownership, and regular review.
Privilege elevation through PIM, role design anchored to management group scope, and structured access reviews are not advanced features. They are the baseline for a permission model that can be maintained over time without compounding risk.
Identity is architecture. It should be engineered accordingly.