AU-10(5): Digital Signatures

AU-10 sits in the Audit and Accountability family; the control enhancements focus on making audit records trustworthy, not just present. AU-10(5) specifically calls out digital signatures as a mechanism to protect audit record integrity and support non-repudiation type objectives (proving origin and detecting tampering). For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate “digital signatures” into concrete operational choices: which systems produce “high-value” audit records, where those logs flow, what signing method you will use, and how an assessor can re-verify signatures later without heroic effort.

In practice, teams stumble on AU-10(5) for two reasons. First, they confuse “TLS in transit” or “hashing” with a digital signature backed by a managed private key. Second, they implement signing in a way that cannot be validated later (missing public cert chain, no retention plan, or undocumented verification steps). This page gives requirement-level implementation guidance you can hand to engineering and security operations, plus the evidence package you need for assessment readiness against NIST SP 800-53 Rev. 5. ¹

Regulatory text

Excerpt: “NIST SP 800-53 control AU-10.5.” ²

Operator interpretation (what you must do): implement digital signatures for audit records within scope so you can (1) attribute audit record creation to an authorized signing identity and (2) detect modification of the record after signing. AU-10(5) is assessed by looking for a real signing implementation, controlled keys, and repeatable validation procedures, not a policy statement.

Where teams get stuck is that the OSCAL excerpt provided here is minimal. Don’t wait for perfect prose. Treat AU-10(5) as a build-and-prove control: you need an implemented technical mechanism and evidence that it works for the audit records you say it covers. ¹

Plain-English interpretation of AU-10(5)

You must make certain audit logs tamper-evident by attaching a cryptographic digital signature created with a protected private key. Later, someone (an auditor, IR team, or system) must be able to verify the signature with the corresponding public key/certificate and detect if the log record was changed.

A practical way to think about it:

• Unsigned logs can be edited and re-ingested without obvious detection.
• Signed logs let you prove integrity after collection, which matters when logs support investigations, compliance reporting, insider threat cases, or regulatory inquiries.

Who it applies to (entity and operational context)

AU-10(5) is most relevant for:

• Federal information systems and programs adopting NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST 800-53 is contractually required or inherited through an ATO boundary. ¹

Operational contexts where AU-10(5) tends to be tested hard:

• Centralized logging/SIEM pipelines (collection agents → brokers → storage).
• Admin activity logging (IAM changes, privilege grants, key management events).
• Security tooling logs (EDR alerts, WAF events, DLP events).
• “Evidence logs” used to support compliance assertions (access reviews, change management, incident timelines).

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

1) Define scope: which audit records require signing

Create a short “AU-10(5) signing scope” list that names:

• Systems and log sources (e.g., cloud audit trail, PAM, OS audit, application audit events).
• Event classes that must be signed (e.g., authentication, authorization, privilege changes, policy changes, log pipeline changes).
• Where signing occurs (at source, at collector, at storage ingest).

Decision rule you can use: sign audit records that (a) support security investigations or (b) prove compliance-relevant admin actions occurred and were authorized.

Artifact: AU-10(5) scope statement (one to two pages) mapped to system inventory and audit event categories.

2) Choose the signing architecture (source vs. pipeline)

Pick one pattern and document it:

Pattern A: Sign at the source (preferred when feasible)

• The producing system (or agent on that host) signs each audit record or batch.
• Strongest provenance story: “the system that generated the record signed it.”

Pattern B: Sign at the log pipeline boundary

• A dedicated collector/signing service signs logs as they enter the controlled logging environment.
• Works when sources cannot sign, but you must be explicit: you are attesting integrity after collection, not origin at the endpoint.

What auditors look for: consistency. If you mix patterns, document why, and ensure verification works across both.

Artifact: Logging architecture diagram with signing point annotated.

3) Implement key and certificate management for signing identities

Digital signatures are only as strong as your key controls. You need:

• A named key owner (service owner) and a named control owner (GRC/security).
• Documented key generation, protection, and access control (HSM/KMS-backed is common).
• Rotation and revocation approach tied to your certificate/PKI practice.
• Strict separation: signing keys should not be exportable by general admins without a controlled break-glass process.

Artifact: Key management standard or procedure section specific to “audit log signing keys,” including access approvals and emergency use.

4) Define the signature format and verification method

Make verification boring and repeatable:

• Define what exactly is signed (entire event JSON, canonicalized payload, or a batch file).
• Define the signature algorithm and encoding (don’t get theoretical; write down the exact implementation choice your engineers made).
• Define how verifiers obtain the correct public key/cert chain for a given time period (critical for old logs).

Then write a verification runbook:

• Input: signed log record(s) + signature + public key/cert.
• Steps to validate.
• Expected outputs (pass/fail) and what failure means (corruption vs. parsing mismatch vs. wrong key).

Artifact: AU-10(5) signature verification runbook with a worked example.

5) Integrate signing with log retention and immutability controls

AU-10(5) focuses on signatures, but assessors commonly test the surrounding story:

• Logs must be retained per your audit retention requirements.
• Signatures and the materials needed to verify them (public certs, intermediate certs, metadata about key IDs) must be retained for the same period.
• If you rely on immutable storage (e.g., WORM features), document how that complements signing, but don’t substitute it for the signature requirement.

Artifacts: retention schedule entry for “signed audit logs,” plus evidence your storage retains verification materials.

6) Operationalize: monitoring, failure handling, and periodic sampling

Add day-two operations so the control keeps working:

• Alert when signing fails (dropped events, signature errors, expired cert).
• Alert when verification fails during spot-checks.
• Periodically sample signed logs and verify signatures as a control test.

Artifact: monitoring rules and a recurring control test record (ticket, checklist, or GRC task) showing validation happened.

Required evidence and artifacts to retain

Use this as your assessment evidence checklist for the au-10(5): digital signatures requirement:

1. Control narrative: what you sign, where, and why (system boundary and scope). ¹
2. Architecture diagram: logging pipeline with signing and verification points.
3. Key management evidence:
   • key/cert inventory entry for signing identities
   • access control list and approval records
   • rotation/revocation procedure and recent rotation evidence (if applicable)
4. Configuration evidence:
   • signing service/agent configuration snippets
   • SIEM/collector config showing signature fields are preserved
5. Verification runbook + sample verification outputs:
   • at least one sample record verified successfully
   • documentation for handling verification failures
6. Operational evidence:
   • monitoring/alerting for signing failures
   • periodic spot-check record(s)
7. Change management records for signing components (deployments, config changes).

Daydream note (earned mention): if you manage multiple systems and third parties feeding logs into your environment, Daydream can track the AU-10(5) control owner, the implementation procedure, and the recurring evidence artifacts so audit readiness doesn’t depend on one engineer’s memory. ²

Common exam/audit questions and hangups

Expect these questions in interviews and evidence requests:

• “Which audit records are digitally signed?” If you answer “all logs,” be ready to prove it across sources and pipelines.
• “Where does signing occur?” They will compare your diagram to configs.
• “Who controls the private key?” “The SIEM admin” is a red flag if not tightly controlled.
• “Can you verify a log from last year today?” This tests retention of public certs and key IDs.
• “Show me a failed verification case and how you’d respond.” Good programs can explain triage.

Hangups that slow audits:

• Signature is implemented, but signature fields get stripped by parsing/transforms.
• Cert chain is not retained, so verification is impossible after rotation.
• Teams confuse hashing with signing and cannot show a private-key-backed signature process.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AU-10(5)	Fix
Signing only a daily archive file but treating it as “all logs signed”	Gaps exist between events and the archive boundary	Document batch boundaries clearly and ensure chain-of-custody from event creation to archive
Private key stored on a general-purpose server with broad admin access	Integrity and non-repudiation claims weaken	Put keys in managed KMS/HSM controls; restrict admin actions and log them
No documented verification procedure	Assessors can’t reproduce validation	Write a runbook and keep sample validation outputs as evidence
Transforming logs after signing	Signature breaks or becomes meaningless	Canonicalize payload before signing; sign the final stored representation
Losing old public keys/certs after rotation	Old logs cannot be verified	Retain verification materials for the full retention period

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-10(5), so treat this primarily as an assessment and incident-risk control rather than an enforcement-driven requirement. Practically, failing AU-10(5) tends to show up as:

• audit findings during ATO/recertification,
• reduced evidentiary value of logs during investigations,
• harder-to-defend timelines and root cause analysis after a security event. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and design)

• Name the AU-10(5) control owner and engineering owner.
• Produce the AU-10(5) signing scope list (systems, event types, signing point).
• Decide on signing pattern (source vs. pipeline) and document the architecture.
• Draft the verification runbook outline and evidence checklist.

By 60 days (implement and prove)

• Implement signing for the highest-value audit sources in scope.
• Stand up key/cert management for signing identities with tight access control.
• Validate end-to-end: source → pipeline → storage retains signatures intact.
• Produce sample verification outputs and store them with control evidence.

By 90 days (operationalize and audit-proof)

• Add monitoring/alerts for signing and verification failures.
• Run a recurring spot-check process and retain results.
• Train IR/SecOps on how to verify signatures during investigations.
• Package evidence in your GRC repository so an auditor can self-serve.

Frequently Asked Questions

What counts as a “digital signature” for AU-10(5)?

A cryptographic signature generated with a protected private key that can be verified with a corresponding public key/certificate. A plain hash without a signing key generally won’t satisfy the “digital signature” intent because it doesn’t prove who signed the record.

Do I have to sign every single log event?

AU-10(5) is usually scoped to audit records that matter for security and compliance outcomes. Define the scope explicitly, then implement signing consistently for the in-scope sources and event types.

If my logs are in immutable (WORM) storage, do I still need signatures?

Immutability helps preserve stored records, but AU-10(5) is about cryptographic integrity and verifiability. Use immutability as a companion control, not a replacement, unless your assessor explicitly accepts a different approach.

Where should signing occur: on the endpoint or in the logging pipeline?

Endpoint signing offers stronger provenance but can be harder to roll out. Pipeline signing is operationally simpler; document that you are attesting to integrity from the point of collection onward and control the signing service tightly.

How do we handle key rotation without breaking verification for older logs?

Store key identifiers with each signed record and retain the public cert chain needed to verify historical signatures for as long as you retain the logs. Make “historical verification” a required test case in the runbook.

Can a third party operate the signing service for us?

Yes, but treat it as a third-party risk issue: you still need evidence of key protection, access controls, and the ability to verify signatures independently. Contractually require retention of verification materials and audit support.

Footnotes

1. NIST SP 800-53 Rev. 5

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