AC-24(2): No User or Process Identity

AC-24(2): no user or process identity requirement means you must be able to make and enforce access control decisions using attributes that exclude the user’s identity (and any acting process identity), such as device posture, network zone, data classification, time, or mission role. Operationalize it by defining “identity-free” authorization rules, implementing policy enforcement points, and retaining testable evidence that decisions don’t depend on user or service account IDs.

Key takeaways:

• Build an authorization path that can decide “allow/deny” without usernames, UIDs, service account names, or process IDs.
• Treat this as an architecture and evidence problem: document your attribute set, policy logic, and enforcement points.
• Prove it works with configuration exports, policy-as-code snapshots, and repeatable tests that remove identity and still yield correct decisions.

Most access control programs default to identity-based decisions: “Alice can access System X.” AC-24(2) forces a different capability. You must enforce access control decisions based on an attribute set that does not include the identity of the user or process acting for the user. That is a specific technical requirement with practical consequences for your authorization design, especially in zero trust, shared services, and high-assurance environments.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) pick the systems where identity-free decisions are feasible and necessary, (2) define the attributes you will allow policy to use, (3) implement those policies in an enforceable control plane (gateway, PDP/PEP, database layer, or application), and (4) capture evidence that auditors can test without reverse-engineering your stack.

This page focuses on requirement-level execution: what counts as “identity,” what “based on attributes” means in real systems, how to prove decisions are identity-independent, and how to avoid common traps (like “we don’t log identity” or “we use roles, so it’s not identity”). You’ll leave with a concrete implementation checklist, evidence list, and an execution plan you can assign to owners.

Regulatory text

Requirement (verbatim): “Enforce access control decisions based on {{ insert: param, ac-24.2_prm_1 }} that do not include the identity of the user or process acting on behalf of the user.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do: implement authorization logic that can reach allow/deny decisions using an approved set of non-identity attributes (the “ac-24.2_prm_1” parameter is your organization-defined attribute set), and ensure user or process identity is not an input to that decision. Your control objective is not “hide identity,” it is “don’t depend on identity.”

Plain-English interpretation

AC-24(2): no user or process identity requirement asks for attribute-based access control where identity is explicitly excluded.

In practice:

• Allowed inputs (examples): device compliance state, network segment, workload label, data sensitivity tag, transaction risk score, time window, required approval state, mission/business function, session assurance level.
• Disallowed inputs (examples): username, email, UID/GID, service account name, API key tied to a specific principal, process ID, container runtime identity, “run-as” user, or any identifier that uniquely points to a person or acting process.

A useful test: if a policy says “allow if user == Alice” or “allow if serviceAccount == payments-writer,” it fails the enhancement. If a policy says “allow if device is managed and request originates from the finance subnet and resource has tag=invoice and action is read,” it fits the intent.

Who it applies to

Entity scope: federal information systems and contractor systems handling federal data (common in FedRAMP/NIST-aligned programs). (NIST SP 800-53 Rev. 5)

Operational contexts where auditors expect you to implement it cleanly:

• Shared or multi-tenant platforms where per-user identity is noisy, ephemeral, or not trustworthy on its own.
• Service-to-service workflows where a process acts “on behalf of” a user and identity chaining becomes fragile.
• High-privilege administrative planes where break-glass identity should not be the only gate.
• Zero trust / conditional access designs where non-identity signals drive decisions.

Systems scope (how to pick in a real program):

• Start with systems that already have strong attribute signals (device management, network segmentation, workload identity metadata, data tags).
• Exclude edge cases only with a documented rationale (e.g., legacy apps that cannot evaluate attributes at runtime) and a migration plan.

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

1) Define the organization “attribute set” for identity-free decisions

AC-24(2) hinges on the parameterized attribute set (“ac-24.2_prm_1”). You must define it for your environment. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverables:

• A short, version-controlled list of approved attributes your authorization layer may use.
• A clear statement of prohibited identity inputs (user ID, service account name, etc.).
• Mapping from attributes to authoritative sources (MDM, CMDB, IAM claims, data catalog tags, network controls).

Practical tip: write this like an allowlist. Auditors can test allowlists.

2) Inventory decision points (where access is granted/denied)

Document where authorization decisions actually happen:

• API gateway / service mesh policy
• Application authorization middleware
• Database row/column-level security policies
• Object store bucket policies
• Message queue/topic policies

Create a simple table:

System / Resource	Decision point (PEP)	Policy engine (PDP)	Inputs used today	Can exclude identity?

This prevents a common audit failure: policy exists “on paper” but the real enforcement point ignores it.

3) Design identity-free policy logic and enforcement

Implement policy so the enforcement point can deny access without referencing identity.

Common patterns:

• Policy-as-code (recommended for evidence): e.g., OPA/Rego, Cedar, or equivalent. The key is not the tool; it’s the traceable policy logic.
• Conditional access at the edge: allow only from managed devices, specific network zones, and approved session assurance.
• Workload attribute enforcement: allow based on workload labels, namespace, environment (prod vs dev), or signed workload metadata, without using a caller principal name.

Implementation requirement: engineers must be able to show that the policy evaluation does not read identity fields from the request context.

4) Prove “identity is not an input” with negative tests

Auditors will ask how you validated the exclusion. Build tests that:

• Remove identity claims from tokens (or replace with a dummy value) and confirm decisions remain correct.
• Attempt access from a compliant device vs non-compliant device without changing the username.
• Attempt access from approved network zone vs unapproved network zone without changing the service account.

Keep this tight: test cases should map directly to policy clauses.

5) Assign ownership and bake into change management

This enhancement fails most often because it is “nobody’s job.”

Minimum assignments:

• Control owner (GRC): defines attribute allowlist, prohibited identity inputs, evidence cadence.
• Policy owner (Security architecture): maintains the policy model and patterns.
• System owners (Engineering): implement PEP/PDP configuration and tests.
• IAM team: ensures identity claims can be excluded and that attribute claims are reliable.

Add a change gate: policy changes require review that checks for identity dependence.

6) Operationalize monitoring (without turning identity into the decision input)

Logging identity is not prohibited by AC-24(2). The decision cannot be based on identity. Keep audit logs rich, but keep the policy logic clean.

Operational controls:

• Policy evaluation logs that show which attributes were evaluated (and confirm identity fields were not referenced).
• Drift detection on policy repositories and enforcement configs.
• Periodic access simulations that replay requests with identity removed.

Required evidence and artifacts to retain

Keep evidence tied to “design,” “implementation,” and “operation.”

Design evidence

• Attribute allowlist / definition of “ac-24.2_prm_1” (versioned document) (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Prohibited identity inputs list (control appendix)
• Reference architecture diagram showing PDP/PEP flow and attribute sources

Implementation evidence

• Policy code/config exports from enforcement points showing rule logic
• Screenshots or exports demonstrating policies reference allowed attributes (not identity)
• Threat model or abuse cases covering “process acting on behalf of a user”

Operational evidence

• Test plans and test results for negative tests (identity removed or replaced)
• Change tickets/PRs showing reviews for policy updates
• Monitoring alerts or periodic review records for policy drift

If you use Daydream to manage control evidence, store the allowlist, policy snapshots, and test runs as recurring artifacts tied to the control owner, with a standing evidence request to engineering for each material policy change.

Common exam/audit questions and hangups

Expect these and prepare short, testable answers:

1. “What attributes is your access control decision based on?”
   Show the allowlist and a sample decision log that lists evaluated attributes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

2. “How do you know identity is not used?”
   Show policy code/config and negative test results where identity claims are absent but decisions still evaluate correctly.

3. “Where is enforcement implemented?”
   Point to concrete PEP locations (gateway, app middleware, database policy) and provide config exports.

4. “What about services acting on behalf of users?”
   Show how your policy uses non-identity attributes for delegation context (e.g., transaction approval state, session assurance, device posture).

5. “Is role-based access control allowed?”
   Roles can be acceptable if they are treated as non-identity attributes and not as a thin proxy for a specific person. Auditors will look for roles that effectively encode identity (“alice-admin”). Document naming and governance rules.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-24(2)	Fix
“We don’t log identity, so we’re compliant.”	Logging is separate from decision inputs.	Prove policy evaluation excludes identity fields.
Using “service account name” as the main gate	Service account identity is still identity.	Gate on workload attributes, environment constraints, network zones, signed metadata.
Roles/groups that mirror individuals	Identity sneaks in through RBAC.	Enforce role governance and prohibit person-specific roles.
Attributes exist but are not authoritative	Policies become bypassable or inconsistent.	Tie each attribute to an authoritative source and document trust boundaries.
Policy exists in one layer, bypass exists in another	Direct-to-database or side-channel paths evade controls.	Map all access paths; enforce at choke points; restrict network paths.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so this page does not cite specific actions.

From a risk standpoint, identity-dependent authorization breaks down under common failure modes: credential theft, token replay, service account sprawl, and confused-deputy scenarios where a process acts for a user. AC-24(2) pushes you to require additional, non-identity signals before access is granted, which raises the cost of misuse even when identity is compromised. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

Use phased execution without date promises.

First 30 days (Immediate: decide scope and define “identity-free”)

• Name a control owner and engineering policy owner.
• Define the attribute allowlist for “ac-24.2_prm_1” and prohibited identity inputs. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Inventory decision points for in-scope systems; identify bypass paths.
• Pick one high-value enforcement point (often API gateway or service mesh) for a pilot.

Days 31–60 (Near-term: implement enforceable policies + tests)

• Implement identity-free policies at the pilot enforcement point.
• Add negative tests that remove or neutralize identity claims and validate decisions.
• Create evidence automation: policy export snapshots, test run artifacts, and a change review checklist.

Days 61–90 (Operationalize: expand coverage and harden governance)

• Expand to additional systems with similar patterns.
• Add drift monitoring and a recurring review of the attribute allowlist.
• Formalize exceptions with compensating controls and a migration backlog.
• Centralize evidence in your GRC system (Daydream or equivalent) so an assessor can trace requirement → policy → enforcement → tests.

Frequently Asked Questions

Does AC-24(2) mean we cannot authenticate users?

No. You can still authenticate and log identity. AC-24(2) requires that the access control decision can be made without using user or process identity as an input. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Are roles and groups considered “identity” under this requirement?

They can be, depending on how you govern them. If roles are stable, non-person-specific attributes tied to job function, they can support identity-free decisions; if they encode individuals or unique principals, auditors may treat them as identity proxies.

How do we handle service-to-service calls where a service account is always present?

Keep the service account for authentication, but base authorization on non-identity attributes such as workload metadata, environment constraints, network zone, and resource tags. Preserve evidence that policy logic does not reference the service account name.

What evidence is most persuasive to an assessor?

Policy code/config that clearly references only approved attributes, plus negative test results showing decisions still work when identity claims are removed or replaced. Pair that with an architecture diagram that shows where enforcement occurs. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What’s the fastest way to find identity dependencies in existing policies?

Search policy repositories and gateway/app configs for identity fields (username, subject, UID, principal, serviceAccount) and then trace each match to a business justification. Treat each match as either an exception with a plan or a refactor candidate.

How should we document the “ac-24.2_prm_1” attributes?

Maintain a version-controlled attribute allowlist with definitions, authoritative sources, and examples of acceptable values. Review it as part of access control changes so policy authors don’t reintroduce identity inputs. (NIST SP 800-53 Rev. 5 OSCAL JSON)