Role-based access control (RBAC) is a way of managing who can do what by attaching permissions to roles rather than to individual people. You define roles that match job functions, such as accounts payable clerk, help desk technician or database administrator, give each role the permissions it needs, and then assign people to roles. When someone joins, moves or leaves, you change their roles rather than editing dozens of individual permissions.
At a glance
- Permissions are granted to roles; users get access by being assigned roles.
- Makes onboarding, role changes and offboarding faster and more consistent.
- Supports least privilege by tying access to job function rather than to individual requests.
- Built into most cloud platforms, SaaS applications, databases and directories, each with its own role model.
- Works best with regular reviews to prevent role sprawl and accumulated access.
What problem it solves
When permissions are granted person by person, access drifts. A new employee is set up “like Sam”, inheriting everything Sam ever collected. Someone moves from sales to finance and keeps both sets of access. Auditors ask why a user can approve payments, and nobody knows. Each exception is small, but together they leave many users with more access than their jobs need and make reviews slow and unreliable.
RBAC replaces that with a defined model. Access follows the role, so two people in the same job have the same access, changes are predictable, and reviews can focus on whether each role is right and whether each person should hold it.
How it works
Define roles. Start with job functions and the tasks they perform. Each role gets a set of permissions in the relevant systems. Many products ship with built-in roles such as reader, contributor and administrator; organizations often add custom ones.
Assign users to roles. Users, or groups of users, are given one or more roles. In many environments, group membership in the directory or identity provider (IdP) drives role assignment in connected applications.
Enforce at access time. When a user tries an action, the application checks whether any of their roles allows it. Authentication confirms who the user is; RBAC is part of authorization, deciding what that user may do.
Separate duties. Roles can be designed so that conflicting tasks, such as creating a vendor and approving payment to it, sit in different roles that one person should not hold together.
Review and maintain. Identity governance and administration (IGA) tools commonly run role reviews and access certifications, flag conflicts and detect users with access outside their role. Highly privileged roles are often managed further through privileged access management (PAM).
When it matters for buyers
- When evaluating SaaS and cloud platforms. Check whether built-in roles are granular enough and whether you can create custom roles; some vendors offer custom roles only in higher tiers.
- When preparing for audits. Many frameworks expect access to be granted by job need and reviewed, and roles make that much easier to evidence.
- When implementing identity governance. Role design is often the hardest part of an IGA project and is usually underestimated.
- When onboarding and offboarding at scale. Growth, seasonal staff and acquisitions make person-by-person access unmanageable.
- When outside providers manage your systems. Giving an MSP or vendor a defined role is cleaner than sharing admin accounts.
Questions to ask vendors
- What built-in roles does the product include, and can we create custom roles with specific permissions?
- Can roles be assigned from our identity provider’s groups, and does that update automatically?
- Can we scope a role to a subset of data, sites or business units?
- How do you report on who holds which roles and what each role can do?
- Do you support separation-of-duties rules or conflict detection?
- Are custom roles, delegated administration or audit reports limited to certain license tiers?
How it differs from attribute-based access control (ABAC)
RBAC asks “which roles does this user hold?” Attribute-based access control (ABAC) asks “do the attributes of this user, this resource and this situation satisfy the policy?”, using things like department, clearance, data sensitivity, device or time of day. ABAC can express finer rules without creating a role for every combination, but it is harder to design and audit. In practice many systems blend the two: roles set the baseline, and attribute or context rules, such as conditional access at sign-in, add restrictions. Both sit within identity and access management (IAM). For controls over the most powerful roles, see our privileged access management overview.