AC-3(13): Attribute-based Access Control

AC-3(13) requires you to enforce attribute-based access control (ABAC) for defined subjects and objects, making access decisions based on approved attributes (not just roles or group membership). Operationalize it by defining your ABAC policy, standardizing attribute sources, implementing a decision/enforcement architecture, and retaining evidence that policies are enforced consistently across systems. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define “subjects,” “objects,” and the attributes that drive decisions, then document an ABAC policy you can test. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Centralize attribute sources (identity, device, data classification) and treat attribute quality as a control dependency.
• Keep assessor-ready evidence: policy, mappings, configurations, logs, and test results that show ABAC decisions are enforced. (NIST SP 800-53 Rev. 5)

The ac-3(13): attribute-based access control requirement is an access enforcement expectation inside NIST SP 800-53 Rev. 5 that goes beyond traditional RBAC (role-based access control). In ABAC, access is allowed or denied based on attributes about the user (subject), the data or resource (object), and often the environment (context). This matters in real programs because most access failures happen in the “exceptions” and edge cases: contractors, privileged tools, sensitive datasets, remote access, and cross-domain sharing.

If you’re a Compliance Officer, CCO, or GRC lead, your fastest path is to treat ABAC as an enforceable policy plus a set of dependencies: authoritative attribute sources, a consistent decision point, and technical enforcement points that can prove they obey the decision. Your audit success will hinge less on ABAC vocabulary and more on whether you can show: (1) which attributes you rely on, (2) where they come from, (3) how they are protected from tampering, and (4) how enforcement is tested and monitored across in-scope systems. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement (verbatim excerpt): “Enforce attribute-based access control policy over defined subjects and objects and control access based upon {{ insert: param, ac-03.13_odp }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What an operator must do:

1. Define the scope of ABAC: which systems, apps, APIs, datasets, and infrastructure components must make access decisions using attributes.
2. Define subjects and objects: subjects are actors (users, service accounts, workloads); objects are resources (files, records, queues, secrets, endpoints).
3. Define the attributes used for decisions (the “control access based upon …” portion): subject attributes (e.g., clearance, employment type), object attributes (e.g., data classification), and relevant environmental attributes (e.g., network zone).
4. Implement enforcement so access decisions actually depend on those attributes at runtime, not in a spreadsheet.
5. Retain evidence that the policy exists, is implemented, and is operating. (NIST SP 800-53 Rev. 5)

Plain-English interpretation

ABAC means “allow access only when required characteristics match.” Instead of “Alice is in the Finance group, so she can read the folder,” ABAC looks more like “Alice can read records labeled ‘Financial-Confidential’ only if her worker type is ‘employee,’ her device is managed, and she is accessing from an approved network zone.”

For audits, ABAC succeeds when:

• Your policy clearly states which attributes are required for which objects.
• Your systems can consume the attributes reliably.
• Your enforcement points can prove they evaluated the attributes and acted accordingly.

Who it applies to

Entities: Federal information systems and contractor systems handling federal data commonly inherit NIST SP 800-53 expectations through system security plans, ATO processes, customer contractual requirements, or security addenda. (NIST SP 800-53 Rev. 5)

Operational context where ABAC is typically in scope:

• Access to sensitive datasets (regulated data, mission data, controlled technical information).
• APIs and microservices where authorization must reflect data sensitivity and caller context.
• Zero trust architectures, conditional access, device-based restrictions, and cross-tenant access.
• Third-party and contractor access where “role” is too coarse.

What you actually need to do (step-by-step)

1) Set ABAC scope and control ownership

• Name a control owner (often IAM lead) and a business owner (data/product owner) for each ABAC-protected domain.
• Write a one-page scope statement: in-scope systems, excluded systems with rationale, and the enforcement mechanism per system (IdP policy, gateway, app layer).
• Define an assessment boundary aligned to your SSP/system boundary documentation. (NIST SP 800-53 Rev. 5)

2) Define subjects, objects, and attributes (the minimum viable ABAC model)

Create an ABAC attribute catalog with three columns:

• Subject attributes: identity assurance level, org, role, worker type, clearance, training completion, citizenship (if applicable), privileged status.
• Object attributes: system, application, dataset name, data classification, record sensitivity tags, owner, residency.
• Environment attributes: device posture, network zone, geo, time window, authentication strength, session risk.

Operator tip: pick a small set of attributes you can prove are authoritative. ABAC fails in audits when attributes exist only as free-text fields or are not governed.

3) Establish authoritative sources and attribute governance

For each attribute, document:

• System of record (HRIS for worker type, CMDB/MDM for device posture, data catalog for classification).
• Update mechanism (SCIM sync, nightly job, event stream).
• Protection (who can change it, logging for changes, approvals for sensitive attributes like clearance).
• Quality checks (null values, stale values, conflicting sources).

This is where many programs break: the ABAC “policy” exists, but attributes are not reliable enough to enforce safely.

4) Design the ABAC decision + enforcement pattern

You need a repeatable architecture, even if it varies by system:

• Policy Decision Point (PDP): where the decision is computed (IdP conditional access engine, authorization service, policy engine).
• Policy Enforcement Point (PEP): where access is allowed/denied (API gateway, app middleware, database row-level security, cloud IAM).
• Policy Administration Point (PAP): where policies are authored and versioned (policy repo, change-controlled config).

Document the pattern per system and keep it consistent enough that testing and evidence collection are straightforward.

5) Author ABAC policies you can test

Write ABAC rules in a way that maps directly to evidence. Example policy statements:

• “Only subjects with worker_type=employee and device_managed=true may access objects tagged data_classification=confidential.”
• “Service accounts may call payroll APIs only from the production network zone and only with approved scopes.”

For each policy, record:

• Rule intent (why).
• In-scope objects (what it protects).
• Required attributes (inputs).
• Default behavior (deny by default is easiest to defend).
• Exception handling (temporary access path).

6) Implement and validate enforcement

Implementation work varies by stack, but your validation approach should be consistent:

• Configuration evidence: screenshots/exports of conditional access policies, gateway authz config, or policy engine rules.
• Test cases: known-good and known-bad scenarios tied to each attribute condition.
• Logs: show attribute evaluation and deny events (or at least deny outcomes linked to policy identifiers).

Run validation after changes and on a schedule aligned with your change management cadence.

7) Operationalize: monitoring, drift control, and access reviews

ABAC is not “set and forget.” Put lightweight operations around it:

• Monitor for policy drift (unauthorized edits, bypass routes, shadow admins).
• Monitor attribute drift (stale device posture, HR termination not propagating).
• Review exceptions (time-bound access, break-glass use).
• Tie ABAC policies into onboarding/offboarding so subject attributes change quickly and predictably.

8) Map the requirement to an evidence calendar (make audits boring)

The most common risk factor for AC-3(13) is missing implementation evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON) Treat evidence as a recurring deliverable:

• Monthly: exception review, policy change log export.
• Quarterly: attribute quality checks, enforcement tests for critical systems.
• On change: new attribute introduction, new system onboarding, policy revision approvals.

Daydream can help by mapping AC-3(13) to a control owner, a written procedure, and a recurring evidence list so you stop rebuilding audit packets from scratch. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Maintain an “AC-3(13) ABAC packet” with:

• ABAC policy document (scope, definitions, attributes, enforcement approach). (NIST SP 800-53 Rev. 5)
• Attribute catalog + data dictionary (attribute name, source, owner, update method).
• System mappings (subjects/objects, PEP/PDP/PAP locations per system).
• Configuration exports (IdP conditional access rules, gateway policies, app authorization configs).
• Change management records for policy edits (approvals, tickets, version history).
• Testing evidence (test scripts, results, screenshots/log excerpts).
• Operational logs showing enforcement outcomes (allow/deny) and exception usage.
• Exception register (who approved, scope, start/end, compensating controls).

Common exam/audit questions and hangups

Auditors and assessors commonly press on:

• “Which attributes are used for which objects?” They want a traceable mapping, not general statements. (NIST SP 800-53 Rev. 5)
• “Where do attributes come from and who can change them?” Attribute integrity is part of enforceability.
• “Show me a deny.” If you cannot demonstrate a policy-driven denial, ABAC looks aspirational.
• “How do you prevent bypass?” Direct database access, alternate endpoints, legacy admin paths.
• “How do you handle third-party access?” Contractors, support vendors, SaaS admins, API clients.

Frequent implementation mistakes and how to avoid them

1. ABAC policy is defined, but enforcement is still RBAC.
   Fix: pick one high-value object set and make an attribute required at runtime, then expand.

2. Attributes are not authoritative or are easy to tamper with.
   Fix: define attribute owners, lock down write permissions, and log changes for sensitive attributes.

3. No default deny behavior.
   Fix: explicitly document defaults per object class and validate them with tests.

4. Exceptions become the real access model.
   Fix: time-box exceptions, require business owner approval, and review exception volume as a control health signal.

5. Evidence is scattered across teams.
   Fix: maintain a single evidence index: what exists, where it lives, who updates it, and how often. Daydream is a natural place to track owners, procedures, and recurring artifacts across IAM and app teams. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as indirect: ABAC gaps often show up as unauthorized access findings during assessments, incident investigations, or customer audits. Practically, weak ABAC increases the chance that sensitive objects are reachable through overbroad roles, mis-scoped service accounts, unmanaged devices, or third-party access paths.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and attributes)

• Assign control owner and system owners for in-scope apps.
• Draft ABAC policy: definitions, scope, and the initial attribute catalog. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify authoritative sources for each attribute and document who can change them.
• Pick one “thin slice” implementation target (one app/API or one sensitive dataset) for enforceable ABAC.

Day 31–60 (implement enforceable ABAC for the thin slice)

• Implement PDP/PEP integration for the chosen target.
• Configure and peer-review policies with change control.
• Create test cases (allow/deny) tied to attribute conditions; run and retain results.
• Build the AC-3(13) evidence packet structure and assign evidence owners.

Day 61–90 (expand coverage and operationalize)

• Expand ABAC to additional objects/systems based on sensitivity and exposure.
• Add monitoring for attribute drift and policy changes; document response steps.
• Stand up an exception register with approvals and expirations.
• Run an internal assessment: sample users, sample objects, prove enforcement with logs and tests; remediate gaps and update documentation. (NIST SP 800-53 Rev. 5)

Frequently Asked Questions

Do we have to replace RBAC to meet ac-3(13): attribute-based access control requirement?

No. Many environments keep RBAC for baseline permissions and add ABAC conditions for sensitive objects or risky contexts. Your evidence should show where attributes change the decision outcome. (NIST SP 800-53 Rev. 5)

What counts as an “attribute” for ABAC?

An attribute is a decision input about the subject, object, or environment, such as worker type, device managed status, or data classification. You need to document each attribute’s source of record and how it is protected from unauthorized changes. (NIST SP 800-53 Rev. 5)

How do we prove ABAC is enforced during an audit?

Provide the policy, the system configuration implementing it, and test/log evidence showing both allowed and denied outcomes based on attribute values. Assessors typically want to trace a rule from documentation to runtime enforcement. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We use a SaaS app with limited authorization controls. How do we handle AC-3(13)?

Document what ABAC you can enforce (IdP conditional access, network controls, application settings) and what you cannot. Then record compensating controls and exceptions, and keep the rationale in your evidence packet. (NIST SP 800-53 Rev. 5)

How should we handle service accounts and workloads under ABAC?

Treat them as subjects with their own attributes (workload identity, environment, approved scopes) and restrict access by object sensitivity and context. Keep tight change control on credentials and policy updates affecting non-human subjects. (NIST SP 800-53 Rev. 5)

What’s the fastest way to become assessment-ready for AC-3(13)?

Create a single mapping from the requirement to the control owner, the written procedure, and the recurring evidence artifacts, then fill gaps system by system. Daydream is well-suited to keep that mapping current and audit-ready across teams. (NIST SP 800-53 Rev. 5 OSCAL JSON)