How does role-based access control (RBAC) work, and where does it break?

Role-based access control (RBAC) grants permissions to roles, not to individuals, and assigns users to roles. Someone who changes jobs changes roles, and their access follows. It is simple to audit and works well until roles multiply or rules depend on context.

Where does RBAC come from?

NIST's RBAC project page explains that the model, formalized in 1992 by David Ferraiolo and Rick Kuhn, became the predominant model for advanced access control because it reduces the cost and complexity of security administration. Without roles, administrators specify access for each user individually, which is costly and prone to error. With RBAC, security is managed at a level that corresponds closely to the organization's structure: each user gets one or more roles, and each role gets one or more permissions. The model was approved as an ANSI/INCITS standard in 2004 and revised in 2012.

What are the building blocks?

• Users: people, or sometimes services.
• Roles: job functions, such as "billing clerk" or "release manager".
• Permissions: approvals to perform an operation on a resource, such as "read invoices".
• Sessions: the roles a user has activated at a given time.

Two common extensions matter in practice. Role hierarchies let a senior role inherit the permissions of a junior one. Separation of duty constraints prevent one person from holding two roles that together create risk, such as creating a vendor and approving payments to it.

What does good role design look like?

A constructed example: a software company has a support team. Instead of granting each agent access to ten tools, it defines three roles.

• Support agent: read customer profiles, update tickets.
• Support lead: everything an agent can do, plus issue refunds up to a limit and view audit logs for the team.
• Support admin: manage macros and queues, but no access to customer payment data.

New hires get "support agent". Promotions change the role. When someone leaves the team, removing the role removes all access in one step. The auditor can review three role definitions and a list of members rather than a spreadsheet of every person's permissions.

Where does RBAC break?

• Role explosion. If every exception becomes a role ("support agent in region X who also needs report Y"), you end up with more roles than people.
• Permission creep. People collect roles over years and never lose them. Without periodic review, access outlives need.
• Roles that mean nothing. "Power user" tells nobody what it grants.
• Context blindness. RBAC cannot easily express "only during working hours" or "only for customers in your own region".
• Service accounts. Machine identities often get broad roles and nobody reviews them.

NIST SP 800-162 defines attribute-based access control (ABAC), where authorization is determined by evaluating attributes of the subject, the object, the requested operation and sometimes the environment against policy. ABAC handles context well. Many organizations combine the two: roles for broad grants, attributes for fine limits.

How does RBAC support compliance?

Frameworks such as SOC 2 and ISO 27001 expect access to be granted on need, reviewed and removed on departure. RBAC makes this evidence straightforward to produce: role definitions, member lists, approval records and review sign-offs. It does not satisfy those frameworks on its own, and each framework's own text sets the actual requirements.

How to check or apply this

1. List your systems and the ten most common job functions. Draw the first set of roles from job functions, not from technology.
2. Define each role in one sentence and list its permissions.
3. Apply least privilege: start with the minimum and add on request with an approval record.
4. Add separation of duty rules for risky pairs, such as request and approve.
5. Review role membership every quarter, and remove unused roles.
6. Give service accounts owners, narrow roles and expiry dates.
7. If you need context rules, add attributes on top of roles rather than inventing new roles.

Quick check

Sources

• NIST CSRC, Role Based Access Control (project page)
• NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• OWASP Authorization Cheat Sheet

Last reviewed: 18 October 2026.