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, and privileged operations that need just-in-time access. This post is about the design discipline that keeps RBAC manageable as the estate grows.
In context: RBAC sits within a broader governance framework. Your hierarchy and policy structure shape how RBAC assignments scale. See Management Groups and Subscription Design: Getting the Hierarchy Right and Azure Landing Zones: What They Are and Why Getting Them Wrong Is Expensive to Fix to understand the context where RBAC operates.
The Least Privilege Principle (Actually Applied)
Least privilege is the most cited and least followed RBAC principle. The failure mode is convenience: Owner is easier to assign than figuring out the specific permissions a team actually needs.
The practical approach: Start with built-in roles. Microsoft maintains these, and they are granular enough for 95% of use cases. Built-in roles like AKS Cluster Admin, Key Vault Secrets Officer, or Network Contributor cover a large proportion of common access patterns without any maintenance overhead.
My Maintenance Rule: I prefer to always default to built-in roles. Azure is constantly evolving; Microsoft updates built-in roles to include new sub-resources and actions as they are released. If you go down the path of custom roles, you are signing up for the long-term overhead of managing those definitions. It is significantly harder to keep custom roles up to date as the cloud evolves over time, and it’s a burden that rarely adds enough value to justify the risk of a “broken” role during an update.
Assignment Scope Strategy
RBAC assignments inherit down the management group hierarchy. The scope decision is a direct trade-off between manageability and blast radius.
The pattern that scales: Platform teams (connectivity, identity, management) get subscription-level assignments on platform subscriptions. Application teams get resource-group-level assignments on their specific workload groups. Cross-cutting roles, like read access for audit teams, get management-group-level assignments to ensure consistent visibility across the entire estate.
Privileged Identity Management (PIM)
Permanent privileged assignments are a persistent governance risk. Privileged Identity Management changes the model: roles are assigned as “eligible” rather than “active.” The principal must activate the role on-demand, with a defined duration and justification.
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 auditors require as evidence of controlled privileged access.
The Break-Glass Account
The break-glass account is the RBAC component that is most often either missing or misconfigured. Every Azure environment should have at least one Global Administrator account not managed through normal access processes—specifically one that remains accessible if Entra ID or your primary MFA provider has an outage.
The Break-Glass Standard: For break-glass accounts, I prefer a physical device. A Yubikey is the gold standard here because it isn’t tied to a single person’s identity or mobile device. This is a critical continuity point: if an employee leaves the business unexpectedly, the physical key can be handed over to their successor. It avoids the trap of a break-glass account being locked behind a former employee’s MFA app.
Monitoring is key: Sign-in activity for these accounts must be 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 a dire incident, or your “keys to the kingdom” have been compromised.
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. The organisations that do this well treat RBAC as a living system—with regular review and a preference for built-in, platform-managed roles over bespoke, high-maintenance configurations.
