Role-Based Access Control

Role-Based Access Control (RBAC) is the pattern of granting access via named roles rather than direct per-user permissions. In Microsoft 365, RBAC appears in many places: Entra ID admin roles (Global Administrator, User Administrator, dozens more) for tenant administration, Defender XDR roles for security operations, Purview roles for compliance, SharePoint site roles (Owners, Members, Visitors), Power Platform environment roles, Intune RBAC roles. Each role bundles specific permissions; assigning a user to a role grants those permissions. Combined with administrative units and PIM, RBAC provides scoped, time-bound, audit-friendly delegation. The right model for managing many users with many access scopes.

Why roles instead of direct permission grants

Without RBAC, granting access means assigning individual permissions to individual users directly — workable for a handful of people, but it breaks down at scale: auditing "who can reset passwords" means checking every user's individual permission set rather than one role's membership list, and onboarding a new help-desk technician means manually replicating whatever ad-hoc permission set a previous technician happened to accumulate. A role instead defines a fixed, named bundle of permissions once ("User Administrator can reset non-admin passwords, manage licenses, and manage groups"), and assigning a user to that role is a single, auditable action — the permission set itself lives in one place, and every role member gets exactly and only what the role defines, no more and no less through drift.

Worked example

A tenant's help-desk team needs to reset passwords and unlock accounts, but should never be able to modify Conditional Access policies or manage other admins. Rather than granting each help-desk hire a hand-picked bundle of individual permissions, they're assigned the built-in Helpdesk Administrator role, scoped additionally to an administrative unit covering only the regional office they support (so a help-desk technician in one region can't reset passwords for users in a different region's administrative unit). When a new technician joins, they're added to the same role assignment — inheriting the identical, already-defined and already-audited permission set — rather than someone reconstructing from memory what the previous technician could and couldn't do. When an auditor later asks "who can reset user passwords in the EMEA office," the answer is a single membership query against one role scoped to one administrative unit, not a manual review of every individual's permission grants.

Built-in roles vs custom roles

Most Microsoft 365 surfaces ship a set of built-in roles covering common scenarios (Global Administrator, User Administrator, Security Reader, Compliance Administrator, and many more in Entra ID alone), and increasingly support custom roles assembled from a granular permission catalog for scenarios the built-in roles don't fit precisely. The general guidance is to exhaust the built-in catalog first — custom roles are more flexible but also more to maintain and audit over time, and a built-in role that's slightly broader than strictly necessary is often a better trade-off than a bespoke role nobody else in the organisation fully understands a year later.

Common pitfalls

The most common RBAC failure isn't choosing the wrong role — it's role sprawl over time: users accumulating additional role assignments as their responsibilities shift, without anyone removing the earlier ones that are no longer relevant. Combined with PIM, making higher-impact roles eligible rather than standing-active, and with periodic access reviews attesting that each assignment is still needed, closes that gap; RBAC without either of those degrades into the same over-provisioned, hard-to-audit mess it was meant to prevent, just organised into named buckets instead of individual grants.