RBAC vs ABAC: which access control model fits your product?

Role based access control (RBAC) grants permissions to roles and assigns people to roles. Attribute based access control (ABAC) decides each request by evaluating attributes of the user, the resource, the action and the environment against policy. RBAC is simpler to run. ABAC handles finer, contextual rules. Many products combine them.

How does RBAC work?

NIST's RBAC project describes the model, formalised in 1992 by David Ferraiolo and Rick Kuhn, as the predominant approach for advanced access control because it reduces the cost and error of managing permissions user by user. The NIST model was adopted as the American National Standard INCITS 359-2004 and revised in 2012. You define roles such as "billing admin" or "viewer", attach permissions to them and assign users. Auditors like it because "who can do what" is a short list.

How does ABAC work?

NIST SP 800-162 defines ABAC as a logical access control methodology where authorisation to perform operations is determined by evaluating attributes of the subject, the object, the requested operations and, in some cases, environment conditions against policy, rules or relationships. Attributes might be department, clearance, data classification, device state, time of day or the owner of a record. A policy can read "allow read if the user's region equals the document's region and the device is managed".

Where do they differ?

• Granularity: RBAC works at the role level. ABAC can express per record and per context rules.
• Administration: RBAC needs role design and avoids long permission lists, but can suffer role explosion when each exception becomes a new role. ABAC moves effort into attribute quality and policy writing.
• Explainability: "Why can she read this?" is easy in RBAC, because she holds a role. In ABAC you must evaluate the policy with the actual attributes, so you need good decision logging.
• Change: adding a new rule in ABAC may need no new roles, but a wrong or stale attribute silently changes access.

A constructed example

A project tool starts with three roles: owner, editor, viewer. Then customers ask for rules: contractors can edit only tasks assigned to them, nobody outside the company network can export, and archived projects are read only. In pure RBAC that becomes a dozen new roles. With attributes it becomes three policies: task assignee equals user for contractors, network zone equals corporate for export, and project status equals archived denies writes. Roles still exist for coarse access.

When should you pick which?

Use RBAC when access follows job function, the set of permissions is stable and auditors need a simple answer. Use ABAC when access depends on ownership, data classification, location, device or other context, or when roles are multiplying. Most teams settle on RBAC for the coarse layer and attribute checks for the exceptions. Relationship based models, where access follows links such as "member of this team", are another option covered by the NIST definition of relationships in policy.

What are the common mistakes?

• Checking authorisation only in the UI, not the API.
• Treating role names as proof, for example trusting a role claim in a token that the client can alter.
• Unmaintained attributes: a person changes team but their attribute still shows the old one.
• No tests for deny cases. OWASP's authorization guidance highlights regression testing of authorization for this reason.
• No log of the attributes used in each decision.

What to do

1. List your resources and the real access rules customers ask for.
2. Start with a small set of roles for coarse access.
3. Add attribute policies for ownership, classification and context rules.
4. Enforce decisions in one central place on the server side.
5. Log the inputs and result of every decision.
6. Write allow and deny tests and run them in CI.
7. Review roles and attribute sources every quarter.

Quick check

Sources

• NIST CSRC: Role Based Access Control project
• NIST SP 800-162: Guide to Attribute Based Access Control
• OWASP Authorization Cheat Sheet

Last reviewed: 18 October 2026.