What Is RBAC? Role-Based Access Control Explained

Walk into a hotel and you can’t wander into the laundry room or dive into the pool from reception. On arrival someone assigns you a role. As a guest you open your own room, as a visitor you wait in the lobby, as a diner you sit at a table in the restaurant. Nobody hands you a master key. Move that idea into a computer system and you have role-based access control.

The real problem with permissions is scale. Granting access to one person is easy. Doing it for two hundred people, and keeping every one of them from holding more than they need, is a different job. RBAC solves it with a plain idea: stop managing permissions person by person and manage them role by role. When someone changes jobs, you swap their role and you’re done.

Think about how that used to work. Someone joined the company, and you opened a list of every permission in the system and ticked the ones their job needed. The list lived in a spreadsheet, an email thread or the memory of the one administrator who had been there the longest. That approach survived ten people. At two hundred it collapses, because the list goes stale the same day you write it.

What is RBAC?

RBAC stands for Role-Based Access Control. It’s a security model where permissions are assigned to roles (administrator, accountant, salesperson, auditor) and users receive those roles instead of permissions directly.

The payoff shows up the moment people move. A new hire in accounting gets the «accounting» role and inherits exactly what they need. When they leave, you take the role away. Nobody has to walk through a hundred permissions one at a time.

The idea is old, and it didn’t come out of a marketing department. David Ferraiolo and Rick Kuhn formalised the model in 1992, and NIST adopted it as the ANSI/INCITS 359 standard in 2004, with a revision in 2012. That NIST RBAC model is the reference most implementations you’ll meet follow.

Before RBAC, systems used ACLs (access control lists), which grant permissions user by user. Multics was the first to use them in 1965, one of the milestones in the history of operating systems. They work, but at scale they turn into a maze. Every person and every resource needs its own entry, and keeping the list current is endless work. Grouping users into sets was the step before roles.

The stakes are higher than they look. Broken access control sits at the top of the OWASP Top 10 for 2021, the risk with the most occurrences in the data collected. RBAC doesn’t fix that on its own, but it’s the foundation almost everything else stands on.

Roles and permissions are not the same thing

The first mix-up, when you’re starting out, is treating «role» and «permission» as synonyms. They aren’t, and confusing them is the fastest way to build a model that doesn’t work. A permission is the specific authorisation to run an operation on a resource: read an order, edit an invoice, delete a user. A role is a bundle of permissions that matches a real business function: customer support, accounting, administration.

The chain is always the same. A user is handed one or more roles, and each role groups permissions. You never grant a loose permission to a person. That’s what lets the model survive growth. When the duties of a job change, you touch the role once and everyone who holds it is up to date. Out of that comes the work people tend to underestimate, role engineering: deciding which roles genuinely exist and what each one carries. That is analysis work, and it has almost nothing to do with configuration.

How it works: the four elements

RBAC rests on four pieces worth keeping straight:

• Users: who is accessing. That can be a person, a service or even a device.
• Roles: the set of functions. A user can hold several at once if the job requires it.
• Permissions: what can be done to what resource. They attach to the role. The person only holds the role.
• Sessions: the moment a user activates one of their roles to work.

The session is the piece most people forget. The same user activates a different role depending on the task, without dragging along the sum of every permission they hold.

A worked example

With those four pieces you can already build a small model. Picture a shop with three roles and three resources. The permission table would look something like this:

Role	Orders	Returns	Users
Customer	View their own	Request	Edit their profile
Support	View all	Process	View
Administrator	View and edit	View and edit	Create and delete

Look at the table again. Nobody holds a permission «on orders» in the abstract. Every cell is an operation on a specific resource. If Support later needs to see billing data, you add that permission to the Support role and the ten people who hold it inherit it. In a per-user model you would be editing ten records and remembering all of them, including the ones who already left the company.

RBAC vs ABAC (and other access models)

RBAC isn’t the only model, and picking the wrong one has consequences. The main ones:

Model	Based on	When it fits
ACL	Users and resources, one by one	Small or very simple systems
RBAC	The user’s role	Organisations with clear functions
ABAC	Attributes (department, location, time, seniority)	Fine-grained, changing rules
MAC	Security labels imposed by the system	High-security environments (military, government)
DAC	The resource owner decides who gets in	Desktop systems

The difference between RBAC and ABAC (Attribute-Based Access Control) is the one people ask about most. In RBAC you decide by role: «salespeople access the customer record». In ABAC you decide by attributes: «salespeople from the Seville office, during working hours, access the customer record». ABAC is more flexible and more powerful, and a good deal harder to design well. It works off rules, which makes it easy to set up and hard to maintain once it grows.

Mind you, the two aren’t mutually exclusive. Many systems combine them, with the role as the base and attributes to fine-tune specific cases, which is exactly what NIST studied.

The four levels of the standard

The standard doesn’t describe a single RBAC. It describes a family of four levels that stack on top of each other, which explains why two tools that both say «RBAC» don’t offer the same thing:

• Basic RBAC (RBAC0). The minimum: users, roles, permissions and sessions, with flat roles and no relationship between them.
• Hierarchical RBAC (RBAC1). A role can inherit another’s permissions, the classic team lead who can do everything their team can and a bit more.
• Constrained RBAC (RBAC2). Adds separation of duties: two incompatible permissions can’t fall to the same person. Whoever approves a payment shouldn’t be able to execute it.
• Symmetric RBAC (RBAC3). Combines hierarchy and constraints, which is what serious tools end up implementing.

Almost nobody needs RBAC3, but almost everybody needs RBAC2 the moment money, personal data or audits enter the picture.

Where you already meet it

RBAC is rarely something you bolt on top of a system. It usually ships inside. Before building your own from scratch, look at what the platform already gives you. Here are examples you probably use without calling them that:

• Operating systems. On Linux, system groups and sudoers are a rudimentary RBAC, and Solaris has had roles, profiles and authorisations of its own for decades.
• Corporate directory. In Active Directory, security groups act as roles: you join a group and inherit its permissions.
• Containers and cloud. Kubernetes has Role, ClusterRole and RoleBinding objects, and Microsoft documents Azure RBAC as its native authorisation system over resources.
• Databases. Nearly all of them let you create roles with GRANT and attach privileges over tables and views.

Pick one of those platforms and look at the roles it already defines. In many cases they cover most of what you need, and only the parts where your organisation genuinely differs require something new.

Advantages of RBAC

Teams adopt it for four reasons they notice almost immediately:

• Less risk. With roles well defined, each person carries only what they need, and that shrinks the surface of a potential incident, whether it’s an outside attacker or a computer virus slipping in where it shouldn’t.
• Less work. Joining and leaving are handled by assigning or removing a role, so you stop going through loose permissions by hand.
• Compliance. Many privacy and confidentiality regulations require access control. RBAC helps you prove it in an audit.
• Scalability. It works just as well for a small company as for a large organisation with hundreds of functions.

The part teams feel fastest is the day someone leaves. With roles, access comes off in one move. Without them, you spend weeks chasing accounts and hoping you remembered every one.

Drawbacks and typical mistakes

None of this is free or automatic. These are the problems that keep coming back:

• Role explosion. If every tiny difference creates a new role, you end up with hundreds and you land back in the chaos you wanted to escape. With many functions and departments, the number of roles spirals when nobody designs it with care.
• Design costs. The hard part sits in translating how the organisation actually works into a map of roles. That’s analysis work, and configuration tools won’t do it for you.
• Temporary permissions. When someone needs a one-off extra, roles can turn into a straitjacket. You solve it with temporary roles, or with attributes (ABAC) for the exceptional cases.
• Unreviewed legacy roles. The classic mistake. The model gets built, everyone changes jobs, and nobody removes the old roles. Over time almost everyone ends up over-permissioned.

The cure for role explosion is a map you can defend out loud. If you cannot explain in one sentence what a role is for, that role has no business existing on its own.

The three golden rules

For RBAC to work, three rules apply in this order:

1. Role assignment: you can only exercise a permission if you’ve first been assigned the role.
2. Role authorisation: you can only activate a role if you’re authorised for it.
3. Permission authorisation: you can only exercise a permission if that permission belongs to the role you have active.

Together they guarantee the same thing: nobody does anything they aren’t authorised for. And all three start from a principle that isn’t exclusive to RBAC but is applied to the letter here, the principle of least privilege. Give each person the bare minimum for the job.

Read those three rules again, because each one catches a different failure. The first stops a permission from existing outside a role. The second stops a role from being used by someone who was never meant to have it. The third stops an activated role from reaching past what it was granted. Skip any one of them and the model develops a gap someone will find.

Good practice: keeping the model from rotting

An RBAC model falls apart through neglect more often than through bad design. These are the habits that separate one which lasts for years from one that ends up as a graveyard of roles:

• Least privilege by default. You start with no permissions and grant only what’s needed, never the other way round. NIST records it as an explicit control in its security catalogue.
• Regular review. Every so often you check who has what and remove the roles that no longer apply. In regulated environments this is called recertification and it isn’t optional.
• Joiner and leaver tied to the lifecycle. When someone joins they get the role. When they leave, everything comes off. Many insider incidents come from access nobody closed in time.
• Reuse what already exists. Platforms usually ship with RBAC. The OWASP access control guidance makes the same point: one mechanism, done well, reused everywhere.

Frequently asked questions

What is RBAC and what does it stand for?

Role-Based Access Control: a security model in which permissions are assigned to roles and users receive those roles, instead of individual permissions.

What is the difference between RBAC and ABAC?

RBAC decides according to the user’s role. ABAC decides according to attributes (department, location, time, seniority). ABAC allows finer rules at the cost of more complexity. The two can be combined.

What is the difference between RBAC and ACL?

ACLs assign permissions user by user and resource by resource, which doesn’t scale well. RBAC groups permissions into reusable roles, so managing access doesn’t become endless work.

What is the principle of least privilege?

Giving each user only the permissions essential to their job. Any sensible access control model is built on that foundation, and RBAC is no exception.

Is RBAC required by regulation?

Not by that name, but many privacy and security regulations require access control and traceability of permissions. RBAC is a common and well-regarded way to meet those requirements.

The bottom line

RBAC solves a very real problem with an idea close to common sense. Permissions go with the job, not with the person. Designed well, it cuts risk and saves a mountain of admin work. Designed badly, or simply left unreviewed, it turns into a graveyard of roles nobody uses and nobody remembers granting.

Work like this needs maintenance the same way the rest of security does. You set the model up, then you keep it alive, review after review. If you want to see the other side of the coin, the one of the people trying to get in where they shouldn’t, here’s what a hacker is.