What is RBAC?
RBAC (Role-Based Access Control) is an access management model in which users do not receive rights directly, but through a role that matches their job, such as operator, maintenance technician or engineer. You therefore manage access per job function rather than per person. RBAC is the most widely used access model in both IT and OT and is formally standardised as ANSI/INCITS 359. In industrial environments, RBAC determines who may operate an HMI, who may change setpoints and who may modify a PLC program.
🕰️ Where does RBAC come from?
Roles already existed in mainframes and databases, but RBAC as a formal model was developed at the US NIST:
| Year | Milestone |
|---|---|
| 1992 | David Ferraiolo and Rick Kuhn (NIST) publish Role-Based Access Controls at the 15th National Computer Security Conference |
| 1996 | Ravi Sandhu and colleagues publish the RBAC96 framework with the levels RBAC0 to RBAC3 |
| 2000 | Sandhu, Ferraiolo and Kuhn merge both approaches into the NIST model for RBAC |
| 2004 | ANSI/INCITS 359-2004 is adopted as a US industry standard in February |
| 2012 | Revised as INCITS 359-2012, plus INCITS 494-2012 with policy enhancements (Policy Enhanced) |
An economic study by RTI International in 2010 estimated that NIST’s RBAC work had saved industry about 1.1 billion US dollars, mainly through more efficient rights administration and less downtime.
🔧 How does RBAC work?
The standard model has four basic elements:
- Users - people, but also service accounts or processes
- Roles - a job function within the organisation, such as Operator or OT Engineer
- Permissions - approval to perform an operation on an object, for example “change setpoint” on a control loop
- Sessions - during a session a user activates one or more of their roles
Permissions are attached to roles and users become members of roles. A user therefore gains access through the role, never directly. When someone changes jobs, you only swap the role; the permissions follow automatically.
🧱 Which variants of RBAC exist?
ANSI/INCITS 359 divides RBAC into four components that build on each other:
| Component | What it adds | OT example |
|---|---|---|
| Core RBAC | Users, roles, permissions and sessions | Operator may start and stop pumps |
| Hierarchical RBAC | Roles inherit permissions from junior roles | Shift Supervisor inherits all Operator permissions |
| Static Separation of Duty (SSD) | One person may never hold two conflicting roles | Whoever writes PLC code may not approve that change |
| Dynamic Separation of Duty (DSD) | Conflicting roles may not be active in the same session | An engineer may not be logged in as operator on the same station at the same time |
The last two together form constrained RBAC. Segregation of duties is also a separate control in ISO 27002 (control 5.3).
🔄 What is the difference between RBAC, ABAC, DAC and MAC?
RBAC is not the only access model. ABAC was described by NIST in SP 800-162 (January 2014) and decides on the basis of attributes of the user, object, action and environment.
| Model | Access decision based on | Strength | Weakness | Typical use |
|---|---|---|---|---|
| RBAC | The user’s role or job function | Clear, easy to audit | Little context, risk of role explosion | Business applications, HMI/SCADA, PLC software |
| ABAC | Attributes (time, location, device, role) | Fine-grained and context-aware | Complex policy, hard to test | Cloud, access portals, Zero Trust |
| DAC | The owner of the object decides | Flexible | Little central control | File sharing, workstations |
| MAC | Central labels and classifications | Very strict | Rigid, heavy administration | Defence, highly classified systems |
In practice, models are combined: RBAC as the foundation, supplemented with attributes such as “only from the engineering station” or “only during an approved maintenance window”.
🏭 What does RBAC look like in an OT environment?
In OT, RBAC is about protecting the physical process. A typical role structure:
| Role | System access | Permitted actions |
|---|---|---|
| Operator | HMI, SCADA clients | View process graphics, operate equipment, acknowledge alarms |
| Shift Supervisor | HMI, SCADA, reports | As operator, plus shelve alarms and adjust limits |
| Maintenance | PLC diagnostics, Historian, alarm system | Read status and diagnostics, reset faults, no program changes |
| OT Engineer | SCADA, PLC, historian, network configuration | Modify and download programs, configure |
| Third party | Only via a jump server during an agreed time window | Read-only or perform updates under supervision |
Modern OT software supports this directly. From TIA Portal V19 (S7-1500 from firmware 3.1, S7-1200 from firmware 4.7), Siemens uses User Management & Access Control (UMAC), with roles and function rights for the PLC and WinCC Unified. Rockwell Automation does the same with FactoryTalk Security. Both can manage users centrally and link them to Active Directory.
🔐 What do IEC 62443 and other standards require of RBAC?
Within the IEC 62443 series, part IEC 62443-3-3 is the most explicit. System requirement SR 2.1 Authorization enforcement requires the control system to be able to enforce the authorisations assigned to all human users, supporting segregation of duties and least privilege. The enhancements become mandatory per security level:
| Enhancement | Content | From |
|---|---|---|
| RE 1 | Enforce authorisation for all users, including software processes and devices | SL 2 |
| RE 2 | Map permissions to roles (RBAC) | SL 2 |
| RE 3 | Supervisor override for a configurable time or event sequence | SL 3 |
| RE 4 | Dual approval for actions with serious impact on the process | SL 4 |
For individual components, the same requirement appears in IEC 62443-4-2 (CR 2.1). Like other security standards, ISO 27001 and ISO 27002 do not literally prescribe RBAC, but require an access control policy (5.15), management of access rights (5.18) and restriction of privileged access rights (8.2). RBAC is the most common way to meet those. The same applies to NIS2 Article 21, which mandates access control policies, and to the Dutch Cybersecurity Act that transposes it. Dutch government bodies also check their roles against the BIO.
🛠 How do you implement RBAC step by step?
Designing roles is called role engineering. A proven approach:
- Inventory functions and tasks - which job functions exist, and which tasks do they perform on which systems?
- Analyse existing rights (role mining) - group users with similar rights and find rights that nobody uses.
- Design a limited set of roles - start with 4 to 6 base roles per system and only add roles when a task genuinely requires it.
- Define segregation of duties - specify which roles are mutually exclusive, such as developing and approving PLC code.
- Automate assignment - map roles to groups in Active Directory or an IAM system, so joiners, leavers and job changes take effect immediately.
- Give privileged roles extra protection - with MFA and PAM for administrator and engineering roles.
- Review periodically - check roles and memberships in an access review; quarterly for privileged roles and annually for other roles is common practice, and record this for your audit and compliance file.
⚠️ What are the pitfalls of RBAC?
- Role explosion - every exception becomes a new role, until there are more roles than users and nobody has an overview.
- Privilege creep - staff who change jobs keep their old roles on top of the new ones.
- Shared accounts - in OT a single “operator” account is often used on an HMI. RBAC then works per role, but you cannot trace who did what, which undermines logging and investigation.
- Overly broad default roles - an “admin” role that everyone gets because it is convenient makes the model pointless.
- No emergency procedure - without a break-glass account, a night-time fault cannot be resolved; with a poorly managed one, you create a back door.
❓ Frequently asked questions
What is the difference between RBAC and least privilege?
Least privilege is the principle that a person only gets the rights needed for their task. RBAC is a model for putting that principle into practice: by designing narrow roles, each user receives exactly the required rights through their role.
Is RBAC mandatory under NIS2?
NIS2 does not mention RBAC by name, but Article 21 does require organisations to have access control policies. In practice, RBAC is the most common way to arrange this demonstrably. An auditor will mainly want to see that rights are based on job function and are reviewed periodically.
How many roles does an RBAC model need?
An RBAC model needs as few roles as possible, as long as segregation of duties is maintained. For an HMI or SCADA environment, four to six roles are often enough, such as operator, supervisor, maintenance, engineer and administrator. When the number of roles approaches the number of users, you are dealing with role explosion.
What is role explosion in RBAC?
Role explosion occurs when an organisation creates a new role for every exception, resulting in hundreds of overlapping roles. The RBAC model then becomes unmanageable and hard to audit. Remedies are clean-up through role mining and using attributes (ABAC) for exceptions.
Can RBAC be used on PLCs?
Yes, modern PLCs and engineering software support RBAC, for example the Siemens S7-1500 with UMAC in TIA Portal and Rockwell with FactoryTalk Security. Older PLCs often only have one password per access level. There, RBAC is enforced on the engineering station and the jump server in front of it.
What is the difference between RBAC and ABAC?
RBAC decides on access based on a user’s role, ABAC based on multiple attributes such as time, location and device. RBAC is easier to manage and audit, while ABAC is more flexible. Many organisations combine both: RBAC as the foundation and ABAC for context rules.
📌 In summary
RBAC controls access based on job function or role, not per individual: easy to manage, scalable and easy to audit. In OT, RBAC is a core requirement from security level 2 under IEC 62443-3-3 SR 2.1. Keep the number of roles small, define segregation of duties and review roles periodically, and RBAC will also support your compliance with ISO 27001 and NIS2.