AC-24: Access Control Decisions

AC-24 requires you to define and implement how your system makes access control decisions so that the required decision rules are evaluated on every access request before the system grants access. Operationally, you need a documented decision workflow, enforced in technical controls, with testable evidence that decisions happen “pre-enforcement” across your key applications and infrastructure. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Document the access decision logic (who/what decides, inputs, and rules) and map it to enforcement points. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Prove decisions occur before access is granted, using logs, configurations, and test cases. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Assign a control owner and maintain recurring evidence artifacts so assessments don’t stall on “show me” gaps. (NIST SP 800-53 Rev. 5 OSCAL JSON)

AC-24: access control decisions requirement is easy to misunderstand because most teams focus on access “enforcement” (the allow/deny action) while AC-24 focuses on the decision that must occur before that action. Your assessor will look for a defined decision process that is consistently applied to each access request, not a loose collection of IAM features. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest route to operationalizing AC-24 is to treat it as a control-design-and-evidence problem: (1) define the decision logic in plain terms, (2) ensure the logic is implemented at the right technical control points (IdP, PAM, gateways, OS, SaaS), and (3) retain proof that the decision is evaluated for real requests. (NIST SP 800-53 Rev. 5 OSCAL JSON)

This page gives requirement-level implementation guidance: who it applies to, what to build, what artifacts to retain, what auditors ask, and the failure modes that cause findings. Where helpful, it also describes how to structure ownership and recurring evidence so AC-24 does not become a last-minute scramble during an assessment.

Regulatory text

Requirement excerpt: “{{ insert: param, ac-24_odp.01 }} to ensure {{ insert: param, ac-24_odp.02 }} are applied to each access request prior to access enforcement.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation: You must define how access decisions are made and implement that logic so the system evaluates the required access control criteria for every access request before it grants access. “Prior to access enforcement” is the key phrase: decision inputs and rules cannot be informal, optional, or performed after the fact. (NIST SP 800-53 Rev. 5 OSCAL JSON)

In practice, this means you should be able to answer, for any protected resource:

• Where does the request enter (application, API gateway, VPN, OS, database, SaaS)?
• What decision point evaluates the request (IdP policy engine, PDP/PEP, app authorization layer, firewall rule evaluation)?
• Which attributes and rules are checked (identity, role, device posture, session risk, network location, time-of-day, ticket/approval state)?
• What enforces the decision (token issuance, group membership, ACL, policy, microsegmentation rule)? (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation

AC-24 is about repeatable, consistent access decisions. You are not being asked to invent new access control models; you are being asked to make your decision process explicit, enforced, and auditable.

A practical way to phrase AC-24 internally:

“For any access request, the system evaluates defined rules using defined inputs, and only then grants the requested access.”

This pushes you away from ad hoc exceptions (“just add them to the group”), hidden approvals (email threads), and “best effort” checks performed by humans outside the system.

Who it applies to

Entity types: Federal information systems and contractor systems that handle federal data. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational contexts where AC-24 shows up:

• Central identity and SSO: Your IdP issues tokens only after policy evaluation.
• Application authorization: The app checks claims/roles/entitlements before showing data or executing actions.
• Privileged access: Elevation decisions (PAM, sudo, just-in-time) occur before privileged commands run.
• APIs and service-to-service: Gateways and services authorize calls before processing.
• Third-party access: External users (support, implementers, managed service providers) are decided and constrained through the same decision logic, not “temporary” bypasses. (NIST SP 800-53 Rev. 5 OSCAL JSON)

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

1) Assign a control owner and define the system boundary

Name a single accountable owner (IAM lead, security engineering, or platform owner) and identify the in-scope systems and enforcement points. If your environment is large, start with “crown jewels” and shared control planes (IdP, PAM, API gateway). Your evidence must match the boundary your assessment uses. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: AC-24 control record with owner, scope statement, and referenced systems.

2) Document the access decision workflow

Create a short, testable description of the decision process. Keep it operational, not academic. Include:

• Decision points: Where the decision is computed (policy engine, application middleware, OS policy, gateway).
• Decision inputs: Identity attributes, group/role, device posture, session context, risk signals, resource sensitivity tags.
• Decision rules: Allow/deny conditions, default deny behavior, exception handling.
• Decision outputs: Token claims, entitlements, permit/deny logs, step-up MFA requirement. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Tip: Put the workflow in a table so assessors can trace it.

3) Map decision points to enforcement points (PDP/PEP mapping)

AC-24 breaks when teams cannot show that a decision is connected to enforcement. Build a mapping for each major access path:

• User to SaaS via SSO
• Admin to servers via PAM
• Developer to cloud console
• Service A to Service B via mTLS/API gateway
• Third party remote support path (VPN/ZTNA, bastion, or support portal)

For each path, list:

• Request type
• Decision mechanism
• Enforcement mechanism
• Log source (where proof will come from) (NIST SP 800-53 Rev. 5 OSCAL JSON)

4) Implement (or tighten) the technical controls

Common implementation patterns that satisfy AC-24, if configured correctly:

• IdP conditional access policies that evaluate conditions before issuing a session/token.
• Application authorization middleware that validates claims and entitlements before serving endpoints.
• PAM policies that require approval, MFA, and time-bounded elevation before privileged sessions start.
• API gateway authorization (JWT validation, scopes, RBAC/ABAC) before routing to backend services.

The control outcome you need: access is not granted unless the decision logic passes, and denial is enforced consistently. (NIST SP 800-53 Rev. 5 OSCAL JSON)

5) Build a minimal but real test plan

Write tests that mirror how auditors validate AC-24:

• A permitted user succeeds.
• A user without entitlement is denied.
• A user missing a required condition (e.g., MFA) is denied or stepped up.
• A third-party identity is denied outside approved conditions.

Run tests against representative apps and record evidence (screenshots are fine, logs are better). (NIST SP 800-53 Rev. 5 OSCAL JSON)

6) Operationalize change control for access decision rules

Access decision logic changes often (new apps, new roles, mergers, third-party onboarding). Tie policy changes to your change process:

• Who can change decision rules?
• How are changes reviewed?
• How do you validate “decision before enforcement” after changes?
• How do you roll back? (NIST SP 800-53 Rev. 5 OSCAL JSON)

7) Set up recurring evidence collection (assessment-ready)

Most AC-24 failures are evidence failures, not technical failures. Create a recurring evidence set:

• Current policy exports/config snapshots
• Representative access decision logs
• Test results
• Exceptions register (if any) with approvals and expirations (NIST SP 800-53 Rev. 5 OSCAL JSON)

Daydream can help by mapping AC-24 to the control owner, implementation procedure, and recurring evidence artifacts so the program does not depend on institutional memory during audits. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Design evidence (what you intended):

• AC-24 control narrative (decision workflow, inputs, rules, outputs)
• PDP/PEP mapping for major access paths
• Standards for roles/attributes and naming conventions (internal doc is fine) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational evidence (what actually happened):

• IdP/PAM/API gateway policy exports (dated)
• Sample allow/deny logs showing policy evaluation tied to identities and resources
• Access test cases with results and timestamps
• Change tickets for policy updates (show review/approval) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Audit accelerators:

• System inventory with enforcement points labeled (IdP, PAM, gateway, app auth layer)
• Exception register with expiration and compensating controls (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Expect questions like:

• “Show me where the access decision is made for this application, and what rules are evaluated.” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “How do you know the decision happens prior to enforcement?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “What happens if the policy engine is unavailable; do you fail open or fail closed?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “How do third-party users get access, and is their access governed by the same decision logic?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Show evidence for a denied access attempt and explain why it was denied.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Hangups that slow audits:

• Logs exist but cannot be tied to a decision rule.
• App teams claim authorization is “in the app” but cannot show configuration or code-level checks.
• Multiple overlapping decision points (IdP + app + network) with unclear precedence and exception handling. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-24	What to do instead
Relying on manual approvals outside the system	The decision is not consistently applied to each request	Put approvals into PAM/JIT workflows or entitlement systems that the policy engine checks before granting access (NIST SP 800-53 Rev. 5 OSCAL JSON)
“Access is controlled by groups” with no rule documentation	Assessors can’t confirm which rules are required and when they run	Document group-to-privilege mapping and the policy evaluation points (NIST SP 800-53 Rev. 5 OSCAL JSON)
App endpoints missing authorization checks	Authentication happens, but authorization decisions are inconsistent	Add authorization middleware and enforce deny-by-default for protected routes (NIST SP 800-53 Rev. 5 OSCAL JSON)
Exceptions that never expire	Exceptions become the real policy	Maintain an exception register with owner and expiration, and review regularly (NIST SP 800-53 Rev. 5 OSCAL JSON)
Evidence stored in Slack/email	Hard to reproduce under exam conditions	Store policy exports, logs, and test results in a controlled repository with clear naming (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 you should treat AC-24 primarily as an assessment-readiness and control-effectiveness expectation rather than a “find a fine” control. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Risk implications are still concrete:

• Poorly defined access decisions drive inconsistent authorization and privilege creep.
• Missing “pre-enforcement” checks causes latent exposure in apps and APIs because requests are processed before authorization gates run.
• Weak evidence collection turns a functioning IAM program into an audit finding because you cannot demonstrate operation. (NIST SP 800-53 Rev. 5 OSCAL JSON)

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign AC-24 owner and identify in-scope systems and enforcement points. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Draft the access decision workflow template and complete it for the IdP and PAM paths first. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify log sources that can prove decisions and denials.

By 60 days (Implement and prove)

• Complete PDP/PEP mapping for major user, admin, API, and third-party access paths. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Export policies/configs from IdP/PAM/gateway and store them as versioned evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Run a small set of access decision tests per critical path and retain results.

By 90 days (Make it durable)

• Add change-control hooks for policy/rule changes (review, test, evidence capture). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Build a recurring evidence cadence and delegate collection to control operators.
• Use Daydream to map AC-24 to the control owner, implementation procedure, and recurring evidence artifacts so the package stays current between audits. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

What counts as an “access request” under AC-24?

Any request that results in access to a resource: interactive logins, API calls, privileged session starts, and application actions that expose or modify protected data. Your mapping should cover the main paths that matter in your system boundary. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do we need a single centralized policy engine to meet AC-24?

No. AC-24 expects consistent, defined decisions before enforcement, but the decision can occur in the IdP, the application, the gateway, or multiple layers. Document the flow and show which layer is authoritative for which decision. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we prove “prior to access enforcement” to an auditor?

Show configuration and logs that demonstrate policy evaluation occurs before token issuance, session establishment, or endpoint execution. Pair this with a negative test where an unauthorized request is denied before the protected action occurs. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How should we handle third-party access under AC-24?

Put third-party identities into the same decision framework: defined identity lifecycle, explicit entitlements, and conditional access rules. Avoid shared accounts and “temporary” bypasses that are not enforced by policy. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is the fastest to collect if we’re behind?

Start with policy exports from your IdP/PAM and a small set of allow/deny logs tied to a documented decision workflow. That combination usually lets you demonstrate both design and operation quickly. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who should own AC-24 in a matrixed org?

Assign a single accountable owner for the requirement and name technical delegates per platform (IdP, PAM, gateway, key apps). The owner’s job is to keep the mapping, test plan, and evidence current across teams. (NIST SP 800-53 Rev. 5 OSCAL JSON)