Modern defence and national security environments need to share information quickly without giving every authenticated user the same level of access.
Security clearance, organisational membership or access to a classified network does not necessarily mean that a person should be able to see every piece of information available within that environment. Access may also depend on their nationality, organisation, mission, role, location, the sensitivity of the information and other contextual factors.
Attribute-Based Access Control (ABAC) provides a way to make those distinctions. At the centre of an ABAC implementation is the decision-making capability often described as an ABAC engine.
An ABAC engine is the decision-making capability within an Attribute-Based Access Control system that evaluates attributes about a user, resource, requested action and operational context against security policies to determine whether access should be permitted or denied.
Rather than relying solely on a user’s identity or membership of a predefined role, an ABAC engine can evaluate multiple attributes at the point an access request is made.
This allows organisations to make far more granular access decisions.
For example, a user may be authenticated to a secure collaboration environment but only permitted to access particular information when their attributes satisfy the policy associated with that information.
This distinction is particularly important in defence, government and coalition environments, where being inside the network does not automatically mean being authorised to access everything on it.
NIST defines ABAC as an access-control method in which requests are granted or denied according to attributes associated with the subject, object and environment, together with policies expressed in terms of those attributes and conditions.
At a simplified level, an ABAC engine answers a question:
Should this subject be allowed to perform this action on this resource under these conditions?
To reach an answer, the system may evaluate four broad categories of information:
Subject attributes describe the person, device or system requesting access. These could include organisation, role, nationality or other authorised characteristics.
Object or resource attributes describe the information or resource being accessed. These could include its classification, information category, owner or releasability requirements.
Action attributes describe what the subject is attempting to do, such as read, edit, copy or delete information.
Environmental attributes provide additional context around the request, such as time, location or other operational conditions.
NIST describes these same fundamental elements in its ABAC model: subject, object, operation, environment and the policies governing their relationships.
The ABAC engine evaluates the relevant attributes against the applicable policy and produces an access decision.
In simple terms:
Access request → Gather attributes → Evaluate policy → Make decision → Enforce decision
The result could be permission to access the resource or a denial of access because one or more of the required conditions have not been met.
ABAC and an ABAC engine are closely related, but they are not exactly the same thing.
Attribute-Based Access Control is the access-control methodology. An ABAC engine is the technology or decision-making capability that evaluates attributes and policies to put that methodology into practice.
Think of ABAC as defining how access should be decided, while the ABAC engine performs the evaluation required to reach that decision.
This distinction is useful because the term “ABAC engine” is widely used to describe the policy-evaluation capability, but it is not necessarily a single standardised component.
In formal access-control architectures, this decision-making function is commonly associated with the Policy Decision Point (PDP).
A Policy Decision Point (PDP) is the part of an access-control architecture responsible for computing an access decision.
When a request is received, the PDP evaluates the applicable policies and information required to determine whether the requested access should be allowed.
NIST defines the PDP as the mechanism that computes access decisions by evaluating applicable policies.
For this reason, when people refer to an ABAC policy engine, ABAC decision engine or simply an ABAC engine, they are often describing functionality centred on the PDP.
But making a decision is only part of the process.
The decision also has to be enforced.
The Policy Decision Point (PDP) decides whether access should be allowed.
The Policy Enforcement Point (PEP) applies that decision.
For example, an ABAC policy might determine that a particular user is permitted to read a document. The PDP evaluates the request and returns the decision, while the PEP controls whether the application actually provides access.
NIST describes the PEP as enforcing policy decisions in response to requests for protected resources, while the access-control decision itself is made by the PDP.
This separation can be important in complex environments because policy decisions do not necessarily have to be made in the same place that access is enforced.
A central decision service, for example, could evaluate policy while enforcement takes place within individual applications or services. NIST notes that PDP and PEP functionality can be centralised or distributed and can be physically or logically separated.
One of the strengths of ABAC is that access decisions can incorporate multiple pieces of information rather than depending on a single role or permission.
Depending on the system and the policies established by the organisation, relevant attributes might include:
These are illustrative examples rather than a fixed ABAC attribute set. The attributes available to an ABAC engine depend on the organisation, its systems and its security policies.
The quality of those attributes also matters. NIST notes that confidence in access-control decisions depends on attributes being accurate, trustworthy and available when required.
Traditional Role-Based Access Control (RBAC) assigns permissions according to roles.
A user might, for example, be assigned to an administrator, analyst or operator role, with each role carrying a predetermined collection of permissions.
This can work well when access requirements are relatively stable.
However, complex security environments can require decisions involving considerably more context.
ABAC allows policies to evaluate combinations of attributes at the time access is requested. NIST’s National Cybersecurity Center of Excellence describes this as a form of just-in-time privilege determination, where access to a particular resource is evaluated for a particular user rather than being derived solely from a previously assigned role.
ABAC does not necessarily mean abandoning roles altogether. A role can itself be treated as an attribute within a wider policy.
The important difference is that the role no longer has to be the only factor determining access.
Security clearance establishes an important boundary around who may potentially access classified information, but clearance alone does not necessarily establish a need to know every item at that classification level.
An ABAC engine can provide a mechanism for applying more granular policies.
Instead of asking only:
“Does this user have the appropriate clearance?”
a policy can potentially ask:
“Does this user satisfy all the attributes required to access this particular information?”
That distinction makes ABAC particularly relevant to need-to-know access.
A user might therefore satisfy one requirement but fail another. They could have the appropriate security clearance, for example, while not meeting an organisational, mission, nationality or releasability requirement associated with a particular resource.
The resulting decision can be specific to that user, resource, action and context.
This allows organisations to move beyond the assumption that authentication or network access automatically confers access to all information within the environment.
Defence collaboration increasingly takes place across organisational and national boundaries.
Coalition operations may bring together personnel from different armed forces, government departments, agencies, contractors and partner nations. Those participants need to collaborate, but they may not all be entitled to receive the same information.
Creating a separate application, network or user role for every possible combination can quickly become difficult to manage.
Attribute-driven access provides another approach.
Policies can express the conditions under which particular information can be accessed, while the ABAC engine evaluates whether a specific request satisfies those conditions.
This can enable more precise information sharing while maintaining control over protected resources.
NIST specifically identifies improved information sharing both within and between organisations while maintaining control of information as an important consideration for ABAC.
Traditional security models have often concentrated heavily on protecting networks, systems and applications.
But highly sensitive information may need protection even after a user has successfully entered the environment in which it resides.
This is where ABAC aligns closely with data-centric security.
Instead of treating everyone inside a trusted boundary as equally entitled to information, access decisions can take account of attributes associated with the information itself and the person or system requesting it.
This becomes especially important in environments where multiple classifications, organisations, missions or communities of interest coexist.
An organisation may have an air-gapped or highly protected network, for example, but there can still be users legitimately operating inside that environment who should not have access to every piece of sensitive information it contains.
Network isolation and authentication remain important, but they solve a different problem.
An ABAC engine can help determine who is authorised to do what with a particular resource under particular conditions.
ABAC also fits naturally with the principles behind Zero Trust.
Zero Trust challenges the idea that access should be implicitly trusted simply because a user or device is already inside a particular network boundary.
ABAC provides a practical mechanism for making more contextual authorisation decisions.
Instead of:
User authenticated → access granted
the decision can become:
User authenticated → attributes evaluated → policy checked → access decision made
That means authentication establishes who or what is making the request, while the ABAC engine helps determine whether that authenticated subject should be authorised to perform the requested action.
The two functions are related, but they are not interchangeable.
An ABAC engine is only as effective as the policies and attributes it evaluates.
The flexibility that makes ABAC powerful can also make policy design more demanding.
Organisations need to establish:
This becomes particularly important when attributes are shared between organisations.
NIST notes that attributes used across organisational boundaries require appropriate mechanisms for areas including validation, updating, security and revocation.
ABAC should therefore be understood as more than simply adding extra fields to user accounts.
It requires a trustworthy relationship between identity, attributes, policy, decision and enforcement.
For secure collaboration platforms, access control has to operate in an environment where information is continually being created, exchanged and consumed.
The challenge is not simply establishing whether somebody can log in.
It is ensuring that sensitive information reaches the people authorised to receive it while remaining unavailable to those who are not.
An ABAC engine provides a foundation for making those decisions using policy and attributes rather than relying solely on static permissions.
For defence, government and other security-conscious organisations, this can support a more granular approach to secure information sharing and help connect identity, need-to-know controls, Zero Trust principles and data-centric security.
As collaboration becomes more federated and information moves across increasingly complex organisational boundaries, that ability to make precise access decisions becomes increasingly important.
An ABAC engine evaluates attributes associated with a subject, resource, requested action and relevant environmental conditions against access-control policies. It uses that information to determine whether a request should be permitted or denied.
ABAC stands for Attribute-Based Access Control. It is an access-control approach in which authorisation decisions are based on attributes and policies rather than solely on predefined user roles.
The terms are closely related but are not necessarily synonymous. An ABAC engine commonly describes the policy-evaluation capability within an ABAC implementation. In formal access-control architecture, the component responsible for computing access decisions is known as the Policy Decision Point (PDP).
A Policy Decision Point (PDP) determines whether an access request should be allowed, while a Policy Enforcement Point (PEP) enforces that decision. The two functions can be logically or physically separated.
An ABAC engine can evaluate subject attributes, resource or object attributes, requested actions and environmental conditions. The exact attributes depend on the organisation’s systems and policies.
RBAC primarily grants permissions through predefined roles. ABAC can evaluate multiple attributes about the user, resource, requested action and context at the time an access request is made. Roles can still form part of an ABAC policy as attributes.
An ABAC engine can evaluate whether a user satisfies the specific policy requirements associated with a particular resource. This allows access decisions to go beyond broad security clearance or network access and incorporate additional need-to-know conditions.
ABAC can support access-control policies for sensitive and classified environments by evaluating attributes associated with users, resources and context. The effectiveness of any implementation depends on the policies, authoritative attributes, assurance mechanisms and wider security architecture surrounding it.
An ABAC engine can help implement contextual authorisation by evaluating attributes and policies rather than assuming that an authenticated user or a user inside a trusted network should automatically receive access to a resource.
ABAC can incorporate attributes associated with individual information resources into access decisions. This supports a data-centric approach in which access can be controlled according to the characteristics and policy requirements of the information itself, rather than relying only on the security boundary around the system containing it.