What is User-Based Access Control?
User-Based Access Control (UBAC) is a form of access control in which rights to systems, functions and data are granted to, and enforced for, the identity of a single individual user, so that every action can be traced back to a person. In OT environments this means no more shared “operator” or “engineer” account, but a personal account for every employee, contractor and supplier. UBAC is therefore the foundation underneath access management, least privilege and a reliable audit trail.
🧠 How does User-Based Access Control work?
UBAC follows the same chain as any form of access control, but with the individual identity at its centre:
- Identification - every person gets a unique account, preferably managed centrally in Active Directory or an IAM solution.
- Authentication - the user proves who they are with a password, badge, smartcard or MFA.
- Authorisation - the system looks up which rights belong to this account, for example in an ACL on a server, folder or application.
- Accounting - every login and change is logged with the username and forwarded to logging, security monitoring and a SIEM.
UBAC is not a formally standardised model. In the literature it is called identity-based access control (IBAC). In SP 800-162 (2014), NIST describes how IBAC works with access control lists: for each object, it is fixed which identities may perform which operations (read, write, edit, delete). NIST also names the downside: those decisions are made in advance, and if nobody actively revokes rights, users quietly accumulate more and more privileges.
🔄 What is the difference between UBAC, RBAC and ABAC?
The difference lies in what the rights are attached to. According to NIST, ACLs work on the attribute “identity”, RBAC on the attribute “role” and ABAC on a policy rule that combines several attributes.
| Model | Rights attached to | Administration | Strength | OT example |
|---|---|---|---|---|
| UBAC / IBAC | The individual user | Per account and per object | Full traceability, simple with small numbers | Supplier X only gets access to one PLC |
| RBAC | A job role | Central, through roles and groups | Scalable, fewer errors when people change jobs | Role “operator line 2” may change setpoints |
| ABAC | Attributes and context | Central policy rules | Fine-grained: time, location, maintenance status | Only during an approved change, from the jump server |
| DAC | The owner of the object | Owner hands out rights | Flexible | Shared folder with project files |
In practice these models are not alternatives but layers. UBAC provides the unique identity, RBAC bundles rights so that administration stays manageable, and ABAC or Zero Trust adds context checks on each request. Rights attached directly to individuals make most sense for exceptions: a temporary supplier, an emergency account or a specialist with a unique task.
🏭 Where is UBAC used in OT networks?
| Application | How UBAC works | Example |
|---|---|---|
| HMI and SCADA | Personal login before critical operation | Login required for setpoint changes; trend data viewable freely |
| Engineering Station | Personal account for programming and downloads | Every PLC download is recorded by name in the project log |
| PLC and controller | User management inside the controller itself | Siemens UMAC for the S7-1500 from firmware V3.1 (TIA Portal V19), Rockwell FactoryTalk Security |
| Remote Access | Personal, temporary account per supplier | An external technician gets one week of access to one installation |
| Jump Server and PAM | A session per person, with recording | Users only see their assigned systems; sessions are recorded |
| Next-Gen Firewall | Firewall rules per user or group | An IP address is mapped to an account via AD logins or a login portal |
| Network access | 802.1X with RADIUS | After login, the switch places the user in the correct VLAN |
Two caveats apply. 802.1X primarily authenticates the network port or device; per-user rights only arise when the RADIUS server returns, for example, a VLAN or filter. And user-based firewall rules stop working as soon as NAT hides the source IP addresses.
🔐 What do IEC 62443 and other standards require of UBAC?
No standard uses the term UBAC, but almost all of them require individual, traceable accounts.
| Standard or regulation | Requirement | Meaning for UBAC |
|---|---|---|
| IEC 62443-3-3 SR 1.1 | Identification and authentication of all human users | Baseline from security level 1 |
| IEC 62443-3-3 SR 1.1 RE 1 | Unique identification and authentication | Personal accounts mandatory from SL 2 |
| IEC 62443-3-3 SR 1.1 RE 2 | MFA for access via untrusted networks | From SL 3, relevant for remote access |
| IEC 62443-3-3 SR 1.3 | Account management | Creating, changing and revoking, optionally via LDAP or AD |
| IEC 62443-4-2 CR 1.1 | The same requirement at component level | HMIs and PLCs must support individual users |
| ISO 27001:2022 5.16 and 5.18 | Identity management and access rights | Shared identities only where demonstrably necessary, with approval |
| 21 CFR Part 11 | 11.100 and 11.300 | Every electronic signature belongs to one person with a unique ID and password |
| NIS2 / Cybersecurity Act | Article 21: access control policies | The Dutch act has applied since 15 August 2026 |
For suppliers and integrators, IEC 62443-2-4 sets comparable account management requirements, so that service engineers also work with personal accounts. Non-repudiation (SR 2.12, from SL 3) is only possible when actions can be linked to one person.
🛠 How do you implement UBAC step by step?
- Inventory shared and default accounts - on HMIs, SCADA servers, engineering stations, PLCs, switches and remote access tools. Factory accounts such as “admin” belong on that list too.
- Set up a separate OT identity domain - for example a dedicated Active Directory forest, separate from the office domain, so that an IT compromise does not carry straight through.
- Give everyone a personal account - including shift leaders, contractors and suppliers. Supplier accounts get an expiry date.
- Grant rights through groups - create a handful of groups per system, manage them centrally with AD groups and GPOs, and assign individual rights only for documented exceptions. That keeps administration feasible.
- Strengthen authentication - MFA for remote and privileged access, badge or RFID login on control room HMIs so that a shift change takes seconds.
- Arrange an emergency procedure - a break-glass account in a sealed envelope or safe, with every use logged and reviewed afterwards.
- Automate joiners, movers and leavers - link accounts to HR data so that departures and job changes take effect immediately.
- Review periodically - common practice is quarterly for privileged accounts and annually for other accounts; record this for the audit.
A well-known example is the incident at the Oldsmar water treatment plant (Florida, February 2021), where someone remotely raised the sodium hydroxide dosing from 100 to 11,100 ppm. According to a Massachusetts state advisory, all computers there with TeamViewer shared a single password. In 2023 the former city manager stated that an employee had made a mistake and that there had been no hack; the FBI never confirmed this. With personal, logged accounts it would have been quick to establish who made the change.
⚖️ What are the benefits and pitfalls of UBAC?
Benefits
- Traceability - every change can be linked to one person, which speeds up incident response and forensic investigation.
- Least privilege per person - rights can match exactly what someone does.
- Fast revocation - when someone leaves or misuses access, you block one account without disrupting anyone else.
- Compliance - individual accounts are a core requirement of IEC 62443, ISO 27001 and 21 CFR Part 11.
Pitfalls
- Administrative burden - rights per individual and per object scale poorly; without groups or roles it becomes unmanageable.
- Privilege creep - people who change jobs keep their old rights if nobody revokes them.
- Resistance on the shop floor - in a 24/7 control room a personal login feels like a delay; fast badge login prevents the account from being shared in the background.
- Legacy systems - older PLCs and HMIs sometimes know only a single password; compensate with a jump server or PAM in front of them, plus defence in depth.
- Misconfiguration - overly broad exceptions leave systems under-protected, while overly tight rights lead to workarounds that bypass security.
❓ Frequently asked questions
Is User-Based Access Control the same as RBAC?
No. With User-Based Access Control, rights are attached to an individual user; with RBAC, they are attached to a job role that users are members of. In OT the two are combined: UBAC provides the personal account, RBAC keeps rights manageable.
Why are shared accounts a problem in OT?
With a shared account it is impossible to establish who changed a setpoint or downloaded PLC code. That undermines incident investigation and conflicts with IEC 62443-3-3 SR 1.1 RE 1, ISO 27001 control 5.16 and 21 CFR Part 11. In addition, when one employee leaves, the password has to change for everyone.
From which security level does IEC 62443 require personal accounts?
IEC 62443-3-3 requires unique identification and authentication of all human users from security level 2, through SR 1.1 RE 1. At SL 1, identification may still take place per group or role. Because SL 2 is often the starting point in practice, personal accounts are the norm in OT.
Can UBAC work on an HMI that is staffed 24 hours a day?
Yes, provided login is fast. Many organisations use a badge, RFID card or fast user switching, so that a new operator works under their own name within seconds. Viewing functions often remain available without login, while operating the process requires a personal login.
How do you manage UBAC for external suppliers?
Give each of the supplier’s service engineers a personal, temporary account with MFA and access only to their own installation, via a jump server or PAM solution. Let the account expire automatically and record the sessions. That keeps remote access traceable without giving the supplier a permanent way in.
Is UBAC enough for Zero Trust?
No. Zero Trust requires a decision on every request based on identity, device and context, which is closer to ABAC. UBAC does provide the essential foundation: without a unique identity, no Zero Trust policy can determine who is requesting access.
📌 In summary
User-Based Access Control ties rights and actions to individual users. In OT it is the basis for traceability, least privilege and compliance with cybersecurity standards such as IEC 62443, ISO 27001 and NIS2. Combine it with roles for manageability and with context for Zero Trust.
In OT, User-Based Access Control means one person, one account, traceable actions. Grant rights through groups or roles, and keep individual exceptions short-lived, documented and periodically reviewed.