Identity and security
RBAC
Role-Based Access Control
Role-Based Access Control is the practice of granting permissions through named roles that bundle a defined set of actions, rather than assigning individual permissions to individual users one at a time.
Why RBAC matters in a Microsoft estate
RBAC matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.
How RBAC shows up in practice
This makes access both easier to reason about and easier to audit, since reviewing who holds the Exchange Administrator role answers the access question directly, whereas reverse-engineering equivalent permissions granted piecemeal across dozens of individual assignments does not. In a Microsoft cloud estate this concept actually spans two related but distinct systems that get confused constantly, even by experienced administrators. Entra ID roles, such as Global Administrator, User Administrator, or Exchange Administrator, control administrative actions within the identity and Microsoft 365 service layer. Azure RBAC, built around roles such as Owner, Contributor, and Reader, controls access to Azure resources, subscriptions, resource groups, and individual resources like virtual machines or storage accounts.
The two systems have separate role definitions, separate assignment mechanisms, and, critically, separate places to check when investigating who can actually do what. This means a full access review has to cover both, rather than assuming one implies coverage of the other. Both systems support custom roles for cases where the built-in role definitions grant either too much or too little, letting an organisation define, for example, a role that can reset user passwords but not modify Conditional Access policies. Azure RBAC roles can also be scoped tightly, applying only to a single resource or resource group rather than an entire subscription.
This is one of the more effective and underused ways to limit blast radius when access genuinely only needs to cover one workload. The principle RBAC is meant to serve, least privilege, is that a user or service should hold only the access actually required for their function and no more. That principle is easy to state and consistently hard to maintain in practice, since role assignments tend to accumulate as people change jobs and rarely get revisited or removed when a broader role is no longer needed.
This is exactly the gap that role-assignable groups, periodic access reviews, and, for genuinely privileged roles, Privileged Identity Management's just-in-time activation are designed to close, converting standing, always-on privileged access into time-bound access granted only when there is an active, justified need for it. Getting RBAC design wrong tends to fail in one of two directions, both costly. Overly broad roles create unnecessary attack surface and make a single compromised account far more dangerous than it needs to be. Overly fragmented custom roles create an administrative burden that eventually pushes teams back toward granting excessive access, simply because working out the correct narrow role every time becomes impractical.