ABAC

What is ABAC?

ABAC (Attribute-Based Access Control) is an access control model in which a policy decides, for each request, whether access is granted based on attributes of the user, the resource, the requested action and the environment. Instead of asking “which role does this person have?”, ABAC asks “do the who, the what, the operation and the circumstances together satisfy the policy?“. NIST described the model in January 2014 in SP 800-162 (updated in August 2019) as a logical access control methodology, and it is a building block of Zero Trust.

In OT networks, ABAC enables fine-grained rules, for example: “Only operators on shift A may operate the HMIs of line 3, and only during their own shift.”

🧠 How does ABAC work?

Each access attempt is evaluated against a set of rules (policies). These rules combine four kinds of attributes:

The decision follows a fixed architecture defined in the OASIS standard XACML 3.0 (January 2013) and adopted by NIST SP 800-162:

• Policy Administration Point (PAP) - where policies are written and managed
• Policy Decision Point (PDP) - evaluates the policies and returns Permit or Deny (XACML also defines NotApplicable and Indeterminate)
• Policy Enforcement Point (PEP) - intercepts the request, asks the PDP for a decision and enforces it
• Policy Information Point (PIP) - supplies current attribute values, for example from Active Directory, LDAP, an HR system or an asset register

Because attributes are looked up at request time, permissions change automatically: someone who moves to another shift, or whose certification expires, loses access without an administrator having to edit a role. Conflicting rules are resolved with combining algorithms such as deny-overrides or permit-overrides. The same PDP/PEP split reappears in NIST SP 800-207, NIST’s Zero Trust architecture.

🔄 What is the difference between ABAC and RBAC?

RBAC ties permissions to job roles; ABAC ties permissions to combinations of characteristics. In ABAC a role is simply one attribute of the subject, so ABAC can emulate RBAC, but not the other way round.

In practice a hybrid approach is the most common: RBAC as the baseline, with ABAC rules for context such as time, location and change window.

🏭 How is ABAC applied in industrial networks?

Controllers rarely support ABAC natively; most PLCs and HMIs know users and roles at most. ABAC therefore usually sits in the access layer in front of them: on the jump server, in the industrial DMZ, in the PAM solution or at the remote access gateway. Typical rules:

• Changes to a PLC only by certified technicians, and only during an approved change window from change management
• Access to the engineering station only for on-site engineers over a wired connection, not over Wi-Fi
• Process data visible only for the operator’s own line or installation
• Different permissions per network location, for example per VLAN or zone
• External suppliers limited to their own installation, with MFA and within an agreed time slot
• Write actions blocked while the installation is in production mode, allowing read access only

ABAC prevents excessive permissions and makes the principle of least privilege enforceable, even as people and installations change.

🔧 How do you introduce ABAC step by step?

1. Inventory resources and actions - which systems, zones and operations (read, write, download) do you want to protect?
2. Choose authoritative attribute sources - HR for employment status, the training register for certifications, the asset register for criticality, the roster for shifts. A rule is never more reliable than the attribute it relies on.
3. Start with RBAC and add context - define baseline roles and write ABAC rules only for exceptions and context conditions.
4. Write policy as code - with XACML, or with modern policy languages such as Rego from Open Policy Agent (a graduated CNCF project since 2021, widely used with Kubernetes) or Cedar, developed by AWS.
5. Test and simulate - check in advance which users gain or lose access after a change, and keep version control on your policies.
6. Arrange emergency access - in OT a policy must never lock an operator out during an incident; define a controlled break-glass procedure.
7. Log every decision - send Permit and Deny decisions through logging to your SIEM for detection and audit.

What do well-known platforms offer?

🔐 What are the security considerations for ABAC?

• Part of Zero Trust - every request is assessed again; combine ABAC with MFA, network segmentation and microsegmentation
• Central management - manage policies in a central IAM solution rather than spread across devices
• Attribute manipulation - anyone who can change an attribute (for example a department field in the directory) can grant themselves access; protect the PIP sources as strictly as the policy itself
• PDP availability - if the decision point fails, access fails with it; design for redundancy and caching
• Standards - IEC 62443-3-3 requires in SR 2.1 (Authorization enforcement) that an IACS enforces authorisations for all human users to support segregation of duties and least privilege; ISO 27001 (Annex A, control 5.15 Access control) and NIS2 also require demonstrable access policies

A sound ABAC policy improves not only security but also compliance and traceability, because every decision can be traced back to a rule and a set of attributes.

❓ Frequently asked questions

What does ABAC stand for?

ABAC stands for Attribute-Based Access Control. With ABAC, a policy decides on access based on characteristics of the user, the resource, the action and the environment, rather than on a role alone.

Is ABAC better than RBAC?

ABAC is not necessarily better than RBAC, but it is more flexible and fine-grained. RBAC is easier to manage and audit, while ABAC is stronger for context rules such as time, location and device posture. Most organisations combine both models.

Which standard describes ABAC?

ABAC is described in NIST SP 800-162 (January 2014, updated in 2019). The policy language and the architecture with PAP, PDP, PEP and PIP come from the OASIS standard XACML 3.0 from 2013, and NIST compared XACML with NGAC in SP 800-178 in 2016.

Do PLCs support ABAC?

PLCs rarely support ABAC directly; most controllers only know users, passwords or roles. In OT, ABAC is therefore enforced in the access layer in front of them, such as a jump server, PAM solution or remote access gateway in the industrial DMZ.

What is a Policy Decision Point in ABAC?

A Policy Decision Point (PDP) is the component of an ABAC system that evaluates the policies and decides Permit or Deny. The Policy Enforcement Point asks the PDP for a decision and enforces it towards the user.

What is the biggest risk of ABAC?

The biggest risk of ABAC is unreliable attribute data: a wrong or manipulated attribute immediately results in wrong permissions. Complex policies are also hard to test and audit, which makes policy versioning and logging of every decision essential.

📌 In summary

ABAC delivers contextual, fine-grained and scalable access control by checking attributes of user, resource, action and environment against central policy for every request. In OT environments, ABAC works best as a complement to RBAC, enforced in the access layer in front of the controllers, with reliable attribute sources, emergency access and complete logging.