How should we redesign Azure RBAC across multiple subscriptions?

Governance should come before the technical rollout. Agree on ownership, support boundaries, approval processes, and a RACI for each Azure service and subscription. Define the minimum role and scope required for every team, obtain leadership support for the change, and then automate the agreed model with IaC. If the licensing is available, use Privileged Identity Management or privileged access groups for elevated permissions so administrative access is temporary, approved, and auditable.

First map what each team actually needs to do. Broad Owner access at the root is extremely risky because one compromised account could affect the entire estate. Most users should have Reader access by default, with Contributor or custom roles limited to the subscriptions, resource groups, or resources they operate. Separate application, network, security, and platform responsibilities instead of giving developers control over networking or access management. Use a pilot subscription first, then expand the model gradually so the migration does not unexpectedly interrupt work.

Built-in Owner and Contributor roles are often too broad for long-term governance. Create focused custom roles where necessary—for example, an application operations role that can manage application resources but cannot change role assignments, virtual networks, public IPs, or other platform infrastructure. Keep network administration, security operations, subscription lifecycle management, and application ownership as separate responsibilities. Policies can also help prevent dangerous assignments, such as Owner at the root management-group scope.

Start by creating a management-group hierarchy based on meaningful boundaries such as production, development, sandbox, business unit, or platform ownership. Move subscriptions into the appropriate groups, then assign permissions at the lowest practical scope. Management groups are useful for shared policies and carefully selected role assignments, while resource groups or individual resources should be used for application-specific access. Bicep or Terraform can define the hierarchy, role assignments, and policies so the configuration is reviewable and repeatable.