Azure RBAC is not complicated in isolation. Grant a role to a principal at a scope — that is the entire model. It becomes complicated at scale: when you have dozens of teams, hundreds of subscriptions, different access requirements for production and non-production, privileged operations that need just-in-time access, and an audit obligation that requires you to explain every assignment. This post is about the design discipline that keeps RBAC manageable as the estate grows.
The Least Privilege Principle (Actually Applied)
Least privilege is the most cited and least followed RBAC principle. The failure mode is not ignorance — most architects know what least privilege means. It is convenience: Owner is easier to assign than figuring out the specific permissions a team actually needs, and it works immediately with no back-and-forth about missing permissions. The path of least resistance at assignment time is the path of maximum exposure indefinitely afterwards.
The cost of Owner assignments is specific and significant. Owner includes the ability to assign RBAC — which is the mechanism for privilege escalation — as well as the ability to delete resources and modify resource locks. In a production subscription, an Owner assignment means the principal can grant themselves or others any additional permission they want, with no additional approval required. Break-glass scenarios and platform administration teams are the appropriate use cases for Owner. Application teams, contractors, and developers are not.
The practical approach: start with Contributor — which covers all resource operations but excludes RBAC management and, in some services, resource deletion — and layer specific Reader or action-level permissions where Contributor is still too broad. Before reaching for a custom role, work through Azure’s built-in role list. The list is longer than most people realise, and most scenarios have a built-in role that is more specific than Contributor: AKS Cluster Admin, Key Vault Secrets Officer, Storage Blob Data Contributor, Network Contributor. Built-in roles cover a large proportion of common access patterns without any maintenance overhead.
Where built-in roles are insufficient: service-specific operations that span multiple built-in roles in ways that do not map to a single built-in. An example: an automation account that needs to read AKS cluster credentials and trigger deployments, but should not be able to create or delete clusters. No single built-in role covers that combination cleanly. Custom roles are the answer, not Owner as a shortcut.
[DAN: Add your rule of thumb for when you create custom roles vs compose multiple built-in roles — specifically the maintenance overhead argument. Custom roles require maintenance when new resource types or actions are added; built-in roles are maintained by Microsoft. Where do you draw the line?]
Assignment Scope Strategy
RBAC assignments inherit down the management group hierarchy. An assignment at the subscription level applies to all resource groups within it; an assignment at the resource group level applies only within that group. The scope decision is a direct trade-off between manageability and blast radius.
Subscription-level assignments are fewer to manage but give access to everything in the subscription, including resources belonging to other teams if the subscription is shared. Resource group-level assignments are granular but multiply as the estate grows — a workload with twelve resource groups requires twelve assignments for every principal that needs access, and keeping those assignments consistent becomes a management problem.
The pattern that scales: platform teams — connectivity, identity, management — get subscription-level assignments on platform subscriptions, where they own the entire subscription and cross-resource-group operations are routine. Application teams get resource-group-level assignments on their workload resource groups within landing zone subscriptions, which are the subscriptions they share with other teams. Cross-cutting roles — read access for audit teams, monitoring access for operations — get management-group-level assignments, because these roles need consistent visibility across the estate and managing them per subscription does not scale.
Avoid assignment sprawl. Regularly audit the number of role assignments per subscription. Azure allows up to 4,000 role assignments per subscription, which sounds like plenty until you have a large estate with many teams, and the count has been growing unchecked for two years. Assignment counts that grow without bound are a reliable signal that access is being granted ad hoc rather than through a managed process with corresponding removal. The count itself is not the problem; the uncontrolled growth is.
Privileged Identity Management
Permanent privileged assignments — Owner or Contributor at subscription level — are a persistent governance risk. The credentials of any principal holding a permanent privileged assignment are a target worth compromising, and the assignment is active continuously regardless of whether it is being used.
Privileged Identity Management changes the model: privileged roles are assigned as “eligible” rather than “active.” The principal must activate the role on-demand, with a defined duration, an optional justification requirement, and an optional approval workflow. Outside of the activation window, the assignment is inert. The attack surface from a compromised account is bounded by the activation duration rather than being permanent.
PIM for what: at minimum, Owner at any scope, Contributor on production subscriptions, and any role that includes RBAC management permissions (User Access Administrator being the most significant). These are the assignments where the blast radius of compromise justifies the friction of JIT activation. Non-production Contributor assignments are a judgment call — the compliance argument for JIT is weaker, but the habit of using JIT for all privileged assignments is worth building.
The activation audit trail is as important as the access control itself. PIM produces an activation log showing who activated a privileged role, when, for how long, and with what justification. This is the artifact that compliance frameworks — ISO 27001, SOC 2, Cyber Essentials Plus — require as evidence of controlled privileged access. A well-configured PIM setup with mandatory justification is significantly easier to present to an auditor than a list of permanent Owner assignments with a verbal explanation.
The gap PIM does not close: service principals and managed identities. PIM applies to human identities — Entra ID users and groups. A service principal with Contributor on a production subscription is a permanent privileged identity without JIT controls, and it is one that may not be subject to the same credential hygiene as human accounts. Prefer managed identities over service principals wherever the target service supports them — no credentials to manage, no credentials to rotate, no credentials to compromise. Where service principals are unavoidable, audit them regularly and rotate their credentials on a defined schedule.
[DAN: Add your experience with PIM rollout — specifically the approval workflow decision (who approves activation requests?), the activation duration you’ve found appropriate for different role types, and the most common resistance from engineering teams.]
RBAC Governance as a Practice
RBAC is not a one-time configuration. Joiners, movers, and leavers change the access landscape continuously. Stale assignments accumulate: users who have left the organisation but whose Entra ID accounts were not promptly disabled, roles granted for a project that ended six months ago, guest accounts invited for a vendor review that were never cleaned up. Each of these is individually minor; collectively they represent both a security exposure and a compliance gap.
Access reviews in Entra ID automate the periodic review of group memberships and role assignments. Configure quarterly access reviews for all privileged role assignments — Owner, Contributor at subscription level, User Access Administrator — and semi-annual reviews for resource-level assignments. Access reviews send notifications to reviewers and track decisions; they produce an audit trail of who reviewed what and what decisions were made. This is the process control that demonstrates to an auditor that stale access is being actively managed rather than accumulated.
The break-glass account is the RBAC component that is most often either missing or misconfigured. Every Azure environment should have at least one break-glass account: a Global Administrator account not managed through normal access processes, not subject to MFA policies that could lock it out (including hardware token requirements for a device that is lost or unavailable), and used only when normal access mechanisms fail — Entra ID outage, PIM unavailability, a conditional access policy misconfiguration that locks out all administrators.
Break-glass account requirements: excluded from all conditional access policies, strong password stored offline (printed and stored in a physically secured location, not in a password manager that requires normal authentication to access), and sign-in activity monitored continuously. Any sign-in event from a break-glass account is an alert that warrants immediate investigation — either the account is being used legitimately in an incident, in which case you need to know about it, or it is being used by an attacker, in which case you need to know about it faster.
[DAN: Add your break-glass account management approach — specifically how you’ve stored credentials, what monitoring you’ve put in place for any sign-in events, and whether you’ve had to use it. The “have you ever had to use it” answer is always interesting to practitioners.]
RBAC design at scale is less about Azure mechanics and more about process discipline. The technical model is simple. The governance challenge is maintaining it as the organisation grows, as teams change, and as new workloads are added with their own access requirements. The organisations that do this well treat RBAC as a living system — with regular review, a defined process for granting and removing access, and tooling that catches stale assignments before they accumulate — not a configuration that is set once and trusted indefinitely.
