IT Glossary
Role-Based Access Control (RBAC) grants permissions by role, not per user. Learn how RBAC works, RBAC vs ABAC, and how it supports least privilege.
July 3, 2026
Role-Based Access Control (RBAC) is an access control model that grants permissions based on a user's role within an organization rather than assigning rights to each individual. Users are mapped to roles (such as "sales rep" or "finance admin"), and each role carries a predefined set of permissions. This simplifies administration, keeps access consistent, and supports the principle of least privilege.
RBAC and ABAC differ on four points. RBAC bases decisions on predefined roles, is simpler and coarser, fits stable and well-defined roles, but risks role explosion. ABAC bases decisions on attributes and context, is granular and dynamic, fits complex and conditional access, but adds higher policy complexity.
A company defines a "Recruiter" role granting access to the ATS, HRIS read access, and Slack HR channels. Every new recruiter inherits the same access on day one, and a role change instantly adjusts it. RBAC scales onboarding cleanly, but as exceptions pile up, organizations often add attribute-based rules on top, which moves them toward ABAC or PBAC.
RBAC grants access based on fixed roles. ABAC grants access based on attributes and context, which allows more dynamic, conditional decisions.
It is the proliferation of narrowly scoped roles created to handle exceptions, which makes RBAC hard to manage. Attribute-based rules can reduce it.
Yes. By granting only the permissions a role needs, RBAC is a practical way to apply the principle of least privilege at scale.
Corma maps roles to real access across your SaaS stack and flags drift. Request a demo.