AU-10(1): Association of Identities

AU-10(1): Association of Identities requires you to cryptographically or logically bind the identity of the information producer (user, service, device, or process) to the information they create or modify, so you can prove provenance during investigations and audits. Operationalize it by defining which records need provenance, enforcing identity-backed creation paths, and retaining verifiable evidence. ¹

Key takeaways:

• Scope “information” and “producer” precisely, then enforce identity binding at creation time, not after the fact.
• Implement identity binding with signed records, authenticated service identities, and tamper-evident audit trails tied to unique principals.
• Keep assessor-ready evidence: data flows, configuration exports, sample signed objects, and validation procedures mapped to AU-10(1).

Compliance teams often treat AU controls as “logging controls,” then discover late that AU-10(1) is about provenance, not volume. AU-10(1): association of identities focuses on making the producer’s identity inseparable from the information produced, in a way you can later validate. That matters when you need to answer basic questions under pressure: Who generated this record? Was it a person or an automated job? Which credential did it use? Has the record been altered since creation?

This requirement shows up across federal system baselines and contractor environments handling federal data, where you need defensible traceability for security operations, incident response, and audits. The fastest path to implementation is to pick the “systems of record” that create regulated or security-relevant information, then require authenticated identities (human and non-human) to generate content through approved interfaces that automatically stamp and protect producer identity metadata.

This page is requirement-level implementation guidance you can hand to control owners to execute. It includes scoping decisions, step-by-step implementation actions, evidence to retain, audit pitfalls, and an execution plan you can run through your GRC workflow (including how to track it cleanly in Daydream). ²

Regulatory text

AU-10(1): Association of Identities — excerpt: “Bind the identity of the information producer with the information to {{ insert: param, au-10.01_odp }} ; and” ¹

Operator translation: You must ensure that whenever “information” is produced (created or materially modified) inside scope, the producer identity is attached to that information in a way that is durable and verifiable. “Binding” usually means one of:

• Cryptographic binding (preferred for high-assurance): digital signatures, signed commits, signed messages, signed artifacts, or signed audit records that can be validated later.
• System-enforced logical binding: immutable metadata fields set by the platform at write time (not user-editable), tied to a unique authenticated principal and protected by integrity controls (e.g., append-only logs, write-once indexes, or database auditing with tamper-evidence).

Your control design choice should be driven by the “{{ insert: param, au-10.01_odp }}” organization-defined parameter in your program: what information types, systems, or events require identity binding; and what “binding strength” you require for each. ¹

Plain-English interpretation of the requirement

AU-10(1) expects you to answer, with evidence:

1. Who produced this information? (human user, service account, workload identity, device identity)
2. How do you know? (the system bound identity at creation/modification; the binding is protected from alteration)
3. Can you validate it later? (you can demonstrate the binding survived storage, processing, and transfer without losing provenance)

A practical standard: if an attacker (or an admin) can edit the “created_by” field freely, you do not have a binding. If logs can be rewritten without detection, you do not have a binding. If “shared accounts” create records, you do not have a reliable identity to bind.

Who it applies to (entity and operational context)

Entity scope

• Federal information systems subject to NIST SP 800-53 controls ²
• Contractor systems handling federal data where AU control inheritance or contractual requirements apply ²

Operational scope (where AU-10(1) tends to be assessed)

• Systems producing security-relevant events: authentication, authorization, admin actions, configuration changes
• Systems producing mission/business records: case management entries, approvals, workflows, financial actions, data exports
• Pipelines and automation producing artifacts: build outputs, infrastructure-as-code deployments, policy changes, dataset transformations
• Interfaces where provenance is commonly lost: batch jobs, ETL, message queues, API gateways, shared admin consoles

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

1) Define your organization-defined parameter (ODP) for AU-10(1)

Create a short AU-10(1) standard that answers:

• What information types require identity binding? Start with: audit records, security events, admin changes, and regulated business records.
• What producers are in scope? Humans, service accounts, workload identities, devices.
• What binding method is acceptable per system tier? Signed artifacts for pipelines, platform-enforced immutable metadata for transactional systems, signed logs or tamper-evident logging for audit trails.

Deliverable: “AU-10(1) Identity Binding Standard” (one page) referenced by your audit logging/provenance procedure. ¹

2) Build a producer identity model (humans + non-humans)

For each in-scope system, document allowed producer identity types:

• Human identities: unique user IDs from your IdP, mapped to roles/groups.
• Non-human identities: dedicated service principals, workload identities, or device certificates; prohibit shared accounts except via documented break-glass.

Minimum requirement for defensibility: a record must map back to a unique principal that is managed, lifecycle-controlled, and attributable.

3) Map “information producers” to the “information” they produce (data-flow level)

Create a table per system of record:

System	Information produced	Producer identity	Creation path	Binding mechanism	Integrity protection
Example: ticketing	ticket updates	human user	UI + API	system-set “actor_id”	audit history append-only
Example: CI/CD	build artifact	pipeline principal	runner	signed artifact/attestation	signature validation + retention

This becomes your scoping proof and your implementation blueprint.

4) Enforce identity binding at write time (control the creation path)

Your key design objective: users and jobs must not be able to create/modify in-scope information without authenticated identity context.

Common implementation patterns:

• Application-layer binding: the app server writes producer_id from the session token/claims; field is not client-supplied; changes are audited.
• Database-layer binding: database auditing captures user/principal; triggers stamp immutable producer columns; changes to stamped fields are blocked.
• Pipeline binding: artifacts and changesets require signing (e.g., signed commits, signed images, signed attestations) by a controlled build identity; verification is part of promotion/release gates.
• Logging binding: central logging preserves original principal identifiers and protects log integrity with append-only storage and restricted admin access.

5) Make the binding verifiable (validation procedure + spot checks)

Write a simple validation procedure that a tester can run:

• Generate a record through an approved interface.
• Confirm the producer identity is attached (field present, correct principal, correct role).
• Attempt to alter the producer identity metadata; confirm it is blocked or detected and logged.
• Validate that downstream copies/exports preserve provenance or retain a cross-reference to the authoritative record.

6) Assign ownership and cadence

AU-10(1) fails in practice because it sits between IAM, app teams, platform, and GRC. Assign:

• Control owner: usually Security Engineering or GRC (depending on model)
• System owners: app/platform owners for implementation
• Evidence owner: GRC or audit readiness lead who pulls configs/samples

Track these mappings in Daydream so each system has an owner, an implementation procedure, and recurring evidence artifacts attached to AU-10(1) for assessment readiness. ¹

Required evidence and artifacts to retain

Keep evidence that proves design + operating effectiveness:

Governance artifacts

• AU-10(1) Identity Binding Standard (your ODP definition) ¹
• System scoping list and rationale (in-scope vs out-of-scope)

Technical artifacts ¹

• Data flow / architecture diagram showing creation paths and identity sources
• Configuration exports or screenshots showing:
  • authentication integration (IdP, service identity)
  • immutable metadata settings, database triggers, or auditing configuration
  • signing/attestation configuration where used
• Sample records (sanitized) demonstrating:
  • producer identity field/claim
  • timestamps and unique identifiers
  • audit trail entries tying the actor to the action
• Validation procedure + test results (date-stamped)
• Access control evidence for who can administer logging/provenance mechanisms

Operational artifacts

• Break-glass procedure and logs for exceptional shared/admin access
• Periodic review evidence (spot checks, change management tickets)

Common exam/audit questions and hangups

Assessors tend to drill into these areas:

1. “Define ‘information’ for AU-10(1) in your environment.” If you cannot state what records/artifacts are in scope, you will argue about boundaries instead of showing controls.
2. “How do you bind identity for service accounts and automation?” Many programs only handle humans. Expect scrutiny on CI/CD, ETL, schedulers, and API integrations.
3. “Can a privileged admin change the producer identity without detection?” This is a tamper-evidence and separation-of-duties question.
4. “Show me an example end-to-end.” Be ready to walk one record from creation through storage, export, and investigation.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AU-10(1)	Fix
Shared accounts create important records	No unique producer to bind	Replace with individual accounts or workload identities; restrict shared IDs to break-glass
Identity stored only in application logs, not with the record	Logs can be incomplete; record provenance lost in exports	Stamp producer identity into the record (or retain a verifiable reference)
Client-supplied “created_by” fields	User can spoof identity	Set identity server-side from authenticated context; block edits
No integrity protection on audit/provenance data	Producer binding can be altered	Use append-only controls, restricted admin, and integrity checks
No documented ODP/scoping	Inconsistent coverage across systems	Publish AU-10(1) standard and map systems to it

Enforcement context and risk implications

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

Risk-wise, AU-10(1) gaps typically surface during incident response and insider-threat investigations: you may have logs, but you cannot prove who produced a critical record or whether provenance was altered. In federal contracting contexts, that becomes an assessment finding and can drive corrective action plans because the control expectation is explicit about binding producer identity to information. ²

Practical execution plan (30/60/90-day)

You asked for speed. Use this as an operator’s runbook.

First 30 days (stabilize scope + quick wins)

• Publish the AU-10(1) Identity Binding Standard (ODP definition) and get sign-off from security + system owners. ¹
• Identify top in-scope systems: audit logging platform, IdP, CI/CD, and one core business system of record.
• For each, document current binding method and gaps in a single table (system, information, producer, binding, integrity).
• Eliminate shared accounts for the selected systems or move them behind break-glass with logging.

By 60 days (implement binding controls + validation)

• Implement server-side stamping for producer identity on in-scope record types.
• Implement non-human identity governance: inventory service principals, rotate credentials via your standard, and ensure each pipeline/job uses a dedicated identity.
• Add integrity protections where provenance is stored (append-only where possible; strict admin access everywhere).
• Run the validation procedure and retain test artifacts (sanitized samples + screenshots/config exports).

By 90 days (harden + make it assessor-ready)

• Expand to remaining in-scope systems and cover at least one high-risk data flow (exports, integrations, or data lake ingestion).
• Add monitoring: alerts for missing producer identity fields, anomalous producer patterns, or creation via non-approved interfaces.
• Operationalize recurring evidence collection in Daydream: map AU-10(1) to a control owner, document the procedure, and schedule evidence pulls per system. ¹

Frequently Asked Questions

What counts as “information” for AU-10(1)?

Treat it as any record or artifact where you may later need defensible provenance: audit records, admin/config changes, business approvals, pipeline artifacts, and exports. Define the list in your AU-10(1) organization-defined parameter so assessors see consistent scope. ¹

Does AU-10(1) require cryptographic signatures everywhere?

The requirement says “bind,” not “sign,” so system-enforced immutable metadata can satisfy it if it is protected from alteration and attributable to a unique principal. Use signing where artifacts move across systems or where integrity and provenance need strong independent verification. ¹

How do we handle microservices producing events through queues?

Ensure each service uses a distinct service identity, and propagate an immutable producer identifier in message metadata that the platform sets or verifies. Preserve the producer identity through consumption, and keep an audit trail that ties message creation to the producing principal.

What about records created by an admin on behalf of a user?

Store both identities where possible: the acting admin (who performed the change) and the subject user (on whose behalf it was done). Auditors look for “actor vs subject” clarity when privileged functions exist.

If we already have central logging, are we done?

Central logging helps, but AU-10(1) expects identity binding with the information itself or a verifiable reference that survives downstream use. If exports or replicas lose producer identity, you still have a gap.

How should we track AU-10(1) work in a GRC tool without overcomplicating it?

Track by system: each in-scope system gets an owner, a short implementation procedure, and a standard evidence set (config export + sample record + validation results). Daydream works well when you keep the mapping tight and evidence recurring. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5