TL;DR: Azure RBAC defines who can do what and where, but broad roles, inherited scope, and standing access still let excess privilege accumulate across cloud estates, according to Sonrai Security. Least privilege fails when teams treat assignment as control, instead of continuously verifying whether access is still needed.
NHIMG editorial — based on content published by Sonrai Security: Azure RBAC Explained: Roles, Scope, and Why Least Privilege Breaks Down
Questions worth separating out
Q: How should security teams reduce least-privilege risk in Azure RBAC?
A: Start by moving away from broad subscription-level roles unless there is a documented operational need.
Q: Why do service principals and managed identities increase cloud access risk?
A: They often keep standing access long after the workload changes, and they are reviewed far less often than user accounts.
Q: What do teams get wrong about Azure RBAC access reviews?
A: They treat a completed review as proof that access is safe, when it only proves that someone acknowledged the assignment.
Practitioner guidance
- Re-scope broad roles before you rationalise role names Start with subscription and management group assignments, then move access down to the narrowest resource group or resource scope that still supports the workload.
- Audit inherited access as a separate control step Review group membership, management group inheritance, and direct assignments together so that high-level permissions are not missed during quarterly reviews.
- Retire dormant service principals and managed identities Build a lifecycle process that identifies machine identities with no recent activity, verifies whether the workload still exists, and removes access when the identity outlives its purpose.
What's in the full article
Sonrai Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Role-by-role breakdown of Azure built-in permissions, including where Contributor behaves like near-admin access.
- Examples of scope inheritance across management groups, subscriptions, and resource groups that show how privilege expands.
- Step-by-step guidance on right-sizing access using observed Activity Log usage and custom roles.
- Operational guidance for treating service principals and managed identities as first-class identities in access reviews.
👉 Read Sonrai Security's analysis of Azure RBAC and least privilege breakdown →
Azure RBAC and standing privilege: where least privilege breaks down?
Explore further