Uses attributes and policy rules, not just role membership, to decide whether access should be granted.
Attribute-based access control, often called ABAC, is an authorization model that uses attributes and policy rules to decide whether access should be granted. In plain language, the system looks at facts about the user, device, resource, or environment instead of relying only on a fixed role.
ABAC matters because real access decisions are often more contextual than a job title alone. A person may be allowed to view a record only from a managed device, only while assigned to a project, or only when handling data from an approved region.
It also matters because cloud and zero-trust environments often need policy decisions that change with context. ABAC can express these dynamic boundaries more cleanly than a large collection of exception-heavy roles.
ABAC appears in cloud IAM policy engines, data access platforms, API authorization, zero-trust gateways, and systems that evaluate device posture or data sensitivity. Teams reach for ABAC when static Role-Based Access Control starts producing too many exceptions.
It also depends on strong inputs. If identity, device, or resource attributes are stale or untrusted, the authorization decision becomes weaker even if the policy language looks sophisticated.
| Attribute type | Example | Why it matters |
|---|---|---|
| Subject | Department, clearance, project membership | Describes who is requesting access |
| Resource | Data classification, owner, environment | Describes what is being accessed |
| Action | Read, export, approve, delete | Narrows what the requester wants to do |
| Environment | Device trust, location, time, network | Adds context around the request |
A company lets engineers read production logs only if they are on the current on-call rotation, use a managed device, and connect through the approved access broker. The decision depends on several attributes, not just on membership in an engineering role.
ABAC is not automatically better than Role-Based Access Control. It is more flexible, but it can also become harder to reason about if policies and attribute sources are poorly managed.
It is also still a form of Authorization, not a replacement for Authentication. The system still needs trustworthy identity and attribute data before it can safely evaluate policy.