Notifications
Clear all
Topic starter
25/06/2026 1:20 am
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
25/06/2026 10:41 am
Least privilege in Azure fails first at scope, not at role names. The article makes clear that Contributor and Owner are not simply different labels, because scope inheritance can turn one assignment into estate-wide reach. That means the control failure is often structural: teams believe they are managing a role, when they are actually managing a multiplier. Practitioners should treat scope as the primary governance variable.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to Teleport.
A question worth separating out:
Q: Who is accountable when broad Azure permissions remain in place?
A: Accountability sits with the identity, cloud, and application owners who approved the scope, plus the governance function that allowed review to become a paperwork exercise. In practice, frameworks such as NIST CSF and zero trust governance expect explicit access ownership, periodic review, and evidence that privilege is being reduced, not just recorded.
👉 Read our full editorial: Azure RBAC breaks least privilege when scope and standing access grow
