AU-10(5): Digital Signatures

AU-10(5): Digital Signatures is an audit and accountability enhancement in NIST SP 800-53 Rev. 5 focused on making audit records tamper-evident and attributable. If your audit logs can be modified, replayed, truncated, or forged without detection, your incident investigations, insider-threat monitoring, and compliance reporting degrade fast. Regulators and assessors don’t need you to have “perfect logs”; they need you to show that the logs you rely on are trustworthy and that you can prove whether they were changed.

In practice, this control becomes a design decision: which audit trails are “high value” enough to sign, what the signature covers (event, batch, file, stream segment), and how you manage signing keys so the signature actually means something. Many teams fail AU-10(5) not because they lack cryptography, but because the program cannot demonstrate consistent operation: ownership, scope, evidence, and verification steps.

This page translates AU-10(5) into an implementable requirement for a Compliance Officer, CCO, or GRC lead. It prioritizes fast operationalization: control scope, runbook steps, concrete artifacts, and common audit traps.

Regulatory text

Requirement excerpt: “NIST SP 800-53 control AU-10.5.” ¹

What the operator must do (practical interpretation of AU-10(5)):
AU-10(5) is the “Digital Signatures” enhancement to AU-10 (Non-repudiation). Read operationally, it means: for audit records where you need strong integrity and accountability, you must implement digital signatures so you can later prove (1) the audit record was produced by an authorized source and (2) it was not altered after signing. The signing approach must be repeatable, verified, and supported by managed keys/certificates and retention of verification evidence. ²

Plain-English interpretation (what this requirement is asking)

You must make certain audit logs tamper-evident using digital signatures. If someone changes a log entry (or a batch/file/stream segment you’ve decided to sign), verification should fail and you should be able to show that failure in evidence. “Digital signatures” here are not generic “checksums” written next to a log. The point is cryptographic non-repudiation tied to controlled keys, so an auditor can trust your forensic timeline.

What this is not

• A policy statement that “logs are protected.” Assessors will look for proof the signing is implemented and verified.
• A one-time “signed file” example with no key management story.
• A substitute for access controls, retention, or centralized logging. It complements them.

Who it applies to

Entity scope (typical):

• Federal information systems and programs aligning to NIST SP 800-53.
• Contractors and service providers handling federal data where 800-53 controls are contractually flowed down. ³

Operational scope (where AU-10(5) usually matters):

• Central logging / SIEM pipelines (collectors, forwarders, aggregators).
• Security-relevant audit sources: identity systems, privileged access, admin actions, security tooling, and key business systems where audit trails support investigations.
• Any environment where logs are exported to third parties, moved across trust boundaries, or stored in object/file storage where admins could alter content.

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

Use this as a build-and-run checklist. Treat it like a control card with a runbook, owner, and evidence bundle.

Step 1: Assign ownership and define the “signed audit record” scope

1. Name a control owner (Security Engineering or Platform; GRC coordinates).
2. Define “high-value audit trails” that require non-repudiation. A practical scoping method:
   • Logs used for incident response and legal/regulatory attestations.
   • Logs tied to privileged activity, IAM events, and security control changes.
   • Logs that cross trust boundaries (agents → collectors → SIEM; SIEM → archive).
3. Decide the signing unit:
   • Per-event signing (strongest, more overhead)
   • Per-batch signing (common for log shippers)
   • Per-file/object signing (common for archives)
   • Per-stream segment signing (common for pipelines)

Deliverable: “AU-10(5) Signing Scope” document: systems, log types, signing point(s), signing unit, and verification expectations.

Step 2: Choose the signing architecture and verification model

Pick one model and document it:

• Source-signing: each producer signs events/batches before forwarding. Best for proving origin, harder to implement broadly.
• Pipeline-signing: a trusted logging service signs at ingestion and re-signs at key transformation points. Common in modern platforms.
• Archive-signing: sign immutable archived log objects plus their manifest. Works if your primary integrity concern is long-term storage.

Define verification:

• Who verifies (SIEM, archive process, independent verifier job)?
• When verification runs (on ingestion, on read, on export, periodic sampling)?
• What happens on failure (alert, quarantine, incident ticket, block export)?

Deliverable: Architecture diagram showing signing and verification points.

Step 3: Implement key/certificate management that makes signatures defensible

Digital signatures only help if keys are controlled. Require:

• A documented key hierarchy and where private keys live (HSM/KMS/service).
• Access control: only the signing service can use signing keys; restrict human access.
• Rotation/renewal and revocation process.
• Backup/recovery procedures and how you preserve the ability to validate old signatures after rotation (critical for audits and investigations).

Evidence expectations: configuration screenshots/exports, key policy docs, access review records, and operational runbooks.

Step 4: Build the signing and verification controls into the logging pipeline

Operational implementation tasks:

1. Configure the signing mechanism in your logging agents/services (or implement signing in your pipeline code).
2. Ensure the signature covers the right content:
   • event payload (or canonicalized payload)
   • timestamp fields (or batch interval metadata)
   • source identity (system/service identity)
   • sequence/offset identifiers to detect deletion/reordering in a batch model
3. Implement verification and logging of verification results.
4. Protect signature metadata from tampering (store alongside the event in a protected envelope, or store separately in an append-only ledger/manifest).

Step 5: Add monitoring, exception handling, and operational cadence

• Alert on verification failures, missing signatures, or unexpected signing key usage.
• Define an exception path for systems that cannot sign (legacy), with compensating controls and a dated remediation plan.
• Schedule a control health check: confirm signing is enabled, keys are valid, verification jobs are passing, and evidence is retained.

This is where many programs fail: implementation exists, but nobody checks it after the initial rollout.

Step 6: Document the control so an auditor can test it quickly

Create a requirement-level control card:

• Objective: audit record integrity and non-repudiation via digital signatures.
• Owner: named team/role.
• Trigger events: new log source onboarding, pipeline change, key rotation, incident.
• Operating procedure: signing config, verification job, alert triage.
• Evidence bundle: exactly what you retain and where.

If you run Daydream for control operations, this is a natural fit for a “control card + evidence bundle + recurring health check” workflow. The main win is consistency: every cycle produces the same artifacts, and exceptions have an owner and closure date.

Required evidence and artifacts to retain

Auditors test AU-10(5) like an engineering control. Keep evidence that proves design and operation:

Minimum evidence bundle (keep per environment)

• Signing scope document (systems/log types, signing point, signing unit).
• Architecture diagram of signing + verification flow.
• Configuration evidence:
  • log pipeline settings showing signing enabled
  • verification job settings and schedules
• Key management evidence:
  • key/cert inventory for signing keys
  • key policies/permissions (who/what can sign)
  • rotation and revocation procedures
• Operational proof (most important):
  • sample signed audit records (redact sensitive fields)
  • verification logs showing pass/fail outcomes
  • alert/ticket example for a simulated failure (tabletop or test)
• Change management linkage:
  • change tickets for pipeline modifications and key rotations
• Retention location and retention rule for signed logs and verification outputs

Common exam/audit questions and hangups

Expect questions like:

• “Which audit records are digitally signed, and why those?”
• “Where in the pipeline do you sign, and how do you prevent alteration between signing and storage?”
• “Show me a signed log sample and the verification result.”
• “How do you manage signing keys? Who can access them? What happens at rotation?”
• “What alerts fire if verification fails or signatures are missing?”
• “How do you validate integrity for logs signed under retired keys?”

Hangups that slow audits:

• No clear scope statement, so the assessor can’t tell what you intended to protect.
• You can sign, but you can’t show routine verification evidence.
• Key management is informal (“only admins have access”) without enforceable policy or logs.

Frequent implementation mistakes (and how to avoid them)

1. Signing only at the archive layer while the SIEM uses unsigned working logs.
   Fix: align signing to the logs you rely on for detection and investigations, not only cold storage.

2. Using hashing without key control and calling it a digital signature.
   Fix: confirm your method is a cryptographic digital signature tied to controlled private keys, with verification using trusted public keys/certs.

3. No story for transformations. Parsing, normalization, or enrichment can invalidate signatures.
   Fix: sign the canonical form you will verify later, or re-sign after transformation with documented chaining.

4. Key rotation breaks historical verification.
   Fix: retain certificate chains/public keys needed to verify prior signatures and document the process.

5. Verification exists but no one watches it.
   Fix: make verification failures page the on-call or open a ticket; test the alert path.

Enforcement context and risk implications

No public enforcement cases were provided for AU-10(5) in the supplied source catalog, so you should treat this as an auditability and assurance requirement rather than a directly case-driven one. The practical risk is straightforward: if you cannot prove audit record integrity, you lose evidentiary value during incident response, insider investigations, and contractual disputes. That can also cascade into failed assessments where your system authorization depends on trustworthy logging. ³

Practical 30/60/90-day execution plan

Use timeboxed phases to drive implementation without pretending every environment is identical.

First 30 days (scope + design + proof of feasibility)

• Assign control owner and publish the AU-10(5) control card (objective, scope, operating steps, exceptions).
• Identify the high-value audit sources and decide signing unit and signing point(s).
• Select signing architecture (source/pipeline/archive) and define verification and failure handling.
• Run a proof of concept in one environment or one log source: produce signed records and verify them.

Next 60 days (build + integrate + evidence)

• Roll out signing to the agreed in-scope sources/pipelines.
• Implement key/certificate management procedures (inventory, access control, rotation, revocation).
• Implement verification jobs and monitoring with documented triage steps.
• Produce the minimum evidence bundle and store it in your GRC evidence repository (Daydream or your existing system).

Next 90 days (operate + test + harden)

• Run a control health check and record results: signing enabled, verification passing, keys valid, alerts tested.
• Exercise one failure scenario (missing signature or verification failure) and capture tickets/alerts as evidence.
• Close exceptions with compensating controls or expand signing coverage based on lessons learned.
• Add AU-10(5) checks to change management gates for logging pipeline changes.

Frequently Asked Questions

Do we have to digitally sign every log entry to meet AU-10(5)?

No. Define a risk-based scope for “high-value” audit records and document which logs are signed and why. Auditors mainly want clarity, consistent operation, and evidence that your signed logs are verified.

Where should we apply signatures: at the source, in the pipeline, or in the archive?

Any of those can work if the choice matches your threat model and you can prove integrity across the path you care about. Document the point of signing and how you prevent tampering between signing, transport, storage, and access.

How do we handle log enrichment or normalization if it changes the record after signing?

Either sign the canonical representation that remains stable through processing, or re-sign after transformation and keep a chain of custody record. Avoid “sign early, transform later” without a plan to preserve verifiability.

What evidence is most persuasive in an audit?

A signed log sample plus a successful verification output, and a record of what happens when verification fails (alert or ticket). Pair that with key management artifacts showing who/what can sign and how keys rotate.

Can we rely on immutable storage (like WORM/object lock) instead of digital signatures?

Immutable storage helps with tamper resistance after write, but it does not prove origin or protect integrity across earlier pipeline stages. If you use immutability as a compensating control, document the gap and why the residual risk is acceptable.

How should we treat third-party logging services or SIEMs?

Treat them as a third party in your logging chain of custody. Contractually and technically confirm where signing happens, how verification works, how keys are managed, and how you receive verification evidence for audits.

Footnotes

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

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5