Attribute-Based Access Control (ABAC)

Attribute-Based Access Control makes authorisation decisions by evaluating attributes: properties of the subject (clearance, department), the object (classification, owner), the action (read, transfer), and the environment (time of day, location, device health). A policy engine compares those attributes against written policy at request time, an approach formalised in the XACML standard. Because any combination of attributes can drive a rule, ABAC is the most granular and context-aware of the mainstream access control models.

That flexibility is also the caveat. Where role-based access control answers one question (what role does this user hold?), ABAC can express policies such as “managers may approve payments below 10,000 from a corporate device during business hours”. The cost is complexity: policies are harder to audit, and a miswritten rule can grant access that no role review would ever surface. ABAC also underpins the dynamic, per-request decisions demanded by zero trust architectures.

Exam relevance: if a scenario mentions decisions based on time, location, device posture, or any combination of subject and object properties, the answer is ABAC. The nearest confusable is RBAC: roles are static job groupings assigned in advance, while attributes are evaluated fresh at each request. The phrases “most granular” or “context-aware” in a question stem also point to ABAC.