What Is RBAC? Role-Based Access Control, Explained

RBAC (Role-Based Access Control) manages who can do what in a system. Permissions attach to roles, and roles attach to people. A user gets access through their role, not through one-off grants, which keeps permissions predictable as teams change.

The model is easy to reason about. Instead of granting a new hire dozens of individual permissions, an administrator assigns one role, and the role already carries the right set. Change a role's permissions once, and every user in that role updates with it.

Almost every serious business application uses this approach. Operating systems, cloud platforms, databases, and enterprise resource planning (ERP) systems all express access through roles rather than a tangle of individual grants.

RBAC has a formal grounding. The National Institute of Standards and Technology (NIST) published a unified RBAC model in 2000, later adopted as the ANSI/INCITS 359 standard in 2004 and revised in 2012 (NIST RBAC project). Core roles, role hierarchies, and separation-of-duty constraints all come from that work.

A warehouse system shows the pattern well. A "picker" role can view and update pick tasks, a "supervisor" role can also reassign them and approve exceptions, and an "administrator" role manages users and settings. Nobody holds a permission they were handed by accident.

Why it matters for custom software

Access control is a design decision, not a feature bolted on later. We build RBAC into the software we deliver so permissions map to how a client's team actually works, which matters most in IT and internal-tools projects where many roles touch the same data. Clear roles also make audits and offboarding faster.

This page is a definition, not security advice.