What is role based access control: RBAC defined, with the failure mode it is famous for
Role based access control, abbreviated to RBAC, is a model in which permissions are granted to roles rather than to individuals, and people receive access by being assigned a role. Nobody holds a permission directly, so access follows the job somebody does rather than the requests they have made.
It is the dominant access model in enterprise software, and the reason a new starter can be productive on day one by being added to a group rather than by twelve separate approvals.
What does role based access control mean?
The model has three sets and two relationships. Users, roles and permissions. Users are assigned to roles, and permissions are assigned to roles. There is no direct line from a user to a permission, and keeping that line absent is the whole discipline.
A permission itself is an operation on an object: read this case, approve that repair, export this report, delete that record. Spelling permissions out as verb plus object is what stops a role definition from drifting into something vague like "claims access", which nobody can audit.
The formal version is standardised. RBAC was formalised in 1992 by David Ferraiolo and Rick Kuhn at NIST, and the unified model was adopted as ANSI/INCITS 359-2004, which defines the reference model of users, roles, permissions, operations and objects along with a functional specification. The standard also covers role hierarchies, where a senior role inherits a junior one's permissions, and separation of duty constraints, where one person may not hold two conflicting roles.
Least privilege, and why RBAC exists at all
The principle behind the model is older than the model. Saltzer and Schroeder set out least privilege in their 1975 paper "The Protection of Information in Computer Systems": every program and every user should operate with the smallest set of privileges needed to do the job.
Least privilege limits blast radius. It does not assume malice. Most of what it prevents is ordinary error, the export nobody meant to run and the record nobody meant to delete, which is why arguing for it as a trust question with your own colleagues tends to go badly.
RBAC explained: a worked example
A claims operation defines four roles. Intake can create a case and request more information but cannot settle. Handler can review, assign and approve up to a value threshold. Investigator can read every case and add findings but cannot change a decision. Administrator manages roles and retention but has no case approval rights at all.
A handler moving to investigations has one role removed and another added. What changes is precise, reversible, and visible in the log. Compare that to the version where their old permissions are simply kept "for continuity", which is how the next problem starts.
Role sprawl: the failure everyone walks into
RBAC degrades in a predictable way. Someone needs one extra permission, and instead of changing the role a new one is created for them. Repeat across a few years and a few hundred people, and the organisation is managing more roles than it has employees, each with a slightly different permission set and no owner.
At that point the model has inverted. It was meant to reduce the number of things to administer, and it has multiplied them. The symptoms are recognisable: roles named after a person, roles nobody can explain, and access reviews that get approved wholesale because reviewing them properly would take a week.
Standing access that outlives its purpose is the measurable consequence. The Netwrix 2026 Data and Identity Security Report, drawn from 2,317 IT and security professionals, found that 76% of organisations cannot immediately revoke standing access once it is no longer needed.
What holds it back is unglamorous:
- Give every role an owner. A role without a named business owner cannot be reviewed, only rubber stamped.
- Refuse the person shaped role. If one individual needs something nobody else in their job needs, question the requirement before creating the role.
- Review on movement, not only on a schedule. Internal transfers accumulate access far faster than joiners do.
- Delete rather than disable. A dormant role is a role somebody will reuse without reading what is in it.
- Keep the definitions readable. If a role's permissions cannot be explained to its owner in a sentence, it will not be audited honestly.
How RBAC differs from ACLs and ABAC
- An access control list attaches permissions to the object: this document lists who may read it. RBAC attaches them to the role. ACLs are precise and become unmanageable at scale, because the truth is scattered across the objects.
- Attribute based access control decides at request time from attributes: department, location, case value, time of day, device posture. It is more expressive and considerably harder to reason about. Many systems run RBAC as the base and add a few attribute conditions on top.
- Authentication is a separate question. Single sign on establishes who someone is. RBAC decides what that person may do, and the two are configured in different places even when the same vendor supplies both.
In evidence handling the model does double duty, since the record of which role acted on a case is part of its chain of custody. Roles are also what make a shared inbox workable, by deciding who may claim, comment on or close a case rather than merely see it.