AU-10: Non-repudiation

Control ID: AU-10 Control Name: Non-repudiation Framework: NIST SP 800-53 Revision 5 Control Family: Audit and Accountability Baselines: HIGH Relevance: System (First Party and Third Party) Risk Severity: Medium

What this control requires

AU-10 requires organizations to produce irrefutable evidence that a specific individual or process performed defined actions within their systems. This obligation means binding verified identities to events like creating documents, sending messages, approving procurement requests, or signing contracts so that no party can credibly deny their involvement after the fact.

The control targets a specific accountability gap. Without non-repudiation mechanisms, any user who authored, transmitted, or approved sensitive information can later claim they didn’t. This control closes that gap by requiring organizations to define which actions demand non-repudiation protection and then deploy technical mechanisms, such as digital signatures, digitally signed receipts, or timestamped audit trails, that make denial implausible.

In practice, implementing AU-10 means selecting the actions most critical to your compliance and legal posture, then ensuring that every instance of those actions generates evidence tied to a verified identity. The evidence must be strong enough to withstand challenge in an audit, investigation, or legal proceeding.

Why it matters

Non-repudiation sits at the intersection of information security accountability and legal defensibility. When organizations lack the ability to prove who did what and when, they lose leverage in disputes, audit findings, and regulatory investigations. For systems classified at the HIGH baseline, this gap directly undermines the trust model that federal and regulated environments depend on.

The consequence extends beyond theoretical risk. Auditors evaluating AU-10 look for concrete evidence that your non-repudiation mechanisms are operational, not just documented. A missing or incomplete implementation can trigger findings that escalate review scope across your entire audit and accountability control family.

Where this accountability gap becomes especially acute is in multi-party workflows. Approval chains, contract executions, and information exchanges between organizations all depend on the ability to attribute actions to specific individuals. Without cryptographic proof tying identities to those actions, any participant can repudiate their involvement.

Specifically, non-repudiation protects four distinct claims: that an author created specific information, that a sender transmitted a message, that a receiver accepted a message, and that a signatory endorsed a document. Each of these claims requires its own evidence mechanism.

What attackers exploit:

• Weak or absent digital signature enforcement on approval workflows, allowing unauthorized actors to forge or deny authorizations
• Shared or generic accounts that sever the link between an action and an individual identity
• Audit logs that capture events but lack cryptographic integrity protections, making them alterable or repudiable without detection
• Message systems without digitally signed receipts, enabling senders or receivers to deny transmission
• Key management failures that undermine the validity of digital signatures used for non-repudiation

How to implement

Most organizations struggle with AU-10 not because the concept is complex, but because non-repudiation requires end-to-end cryptographic infrastructure that spans identity management, key lifecycle, and audit architecture. The most common failure mode is deploying digital signatures in isolation without addressing the key management and certificate validation that make those signatures trustworthy.

For your organization

The first decision that shapes everything else is defining which actions in your environment require non-repudiation protection. AU-10 uses an assignment parameter, meaning your organization must explicitly identify the actions covered. Typical candidates include document approvals, contract signatures, financial authorizations, privileged configuration changes, and the transmission of sensitive or regulated data.

From that scoping decision flows the selection of technical mechanisms that will produce irrefutable evidence. Digital signatures backed by a public key infrastructure (PKI) are the most common approach. Each user or process that performs a covered action must hold a unique signing key tied to a verified identity, and the resulting signature must be verifiable by any party with access to the corresponding public key.

In practice, the signing infrastructure must extend to your audit records as well. Your audit system should generate records that include a cryptographic hash and digital signature at the point of creation, ensuring that the record cannot be altered without detection. Pair this capability with timestamping services to establish when the action occurred.

Where this signing requirement becomes more nuanced is in message-based workflows. When a sender transmits information, the receiving system should generate a signed acknowledgment. This receipt mechanism protects against both sender repudiation (“I never sent that”) and receiver repudiation (“I never received that”).

What makes or breaks every mechanism described above is key lifecycle management. Non-repudiation keys must be protected against compromise, rotated on schedule, and revoked promptly when an individual’s access changes. Without sound key lifecycle management, the evidentiary value of any digital signature degrades.

What often gets overlooked is ongoing validation of these mechanisms. Verify that signatures validate correctly, that audit records maintain integrity, and that your PKI certificates haven’t expired or been revoked. Document these verification activities as part of your ongoing assessment evidence.

For your vendors

When evaluating vendor compliance with AU-10, focus on whether the vendor can demonstrate that their systems produce irrefutable evidence for covered actions, not just that they have an audit logging capability.

Specifically, start by verifying the vendor’s list of actions designated for non-repudiation protection. Confirm that the list is specific and justified, not a generic statement that “all actions are logged.” Ask for documentation of the mechanisms in use, whether digital signatures, signed message receipts, or equivalent cryptographic controls.

Deeper scrutiny should go to the vendor’s key management practices. Ask how signing keys are generated, stored, distributed, and revoked. Look for integration with a formal PKI or a managed certificate authority rather than self-signed certificates with no lifecycle governance.

Where this scrutiny most often reveals gaps is in key management specifics: shared signing keys across multiple users, no documented key rotation schedule, and no revocation process.

The most telling evidence, however, comes from sample audit records that demonstrate non-repudiation in action. The records should show a verifiable binding between an identity, an action, and a timestamp. If the vendor cannot produce this evidence on request, their AU-10 implementation is likely incomplete.

What separates compliant vendors from checkbox vendors is how they protect the integrity of non-repudiation evidence itself. Signed audit records stored in a system where administrators can delete or modify them without detection do not satisfy the control’s intent. Look for separation of duties, append-only storage, or independent integrity verification.

Where the vendor holds ISO 27001 certification, review their cryptographic controls as well, since the requirements overlap with AU-10’s cryptographic foundation.

Evidence examples

Auditors assess AU-10 by examining artifacts across the audit and accountability control family that demonstrate non-repudiation mechanisms are operational.

Cross-framework mapping

No applicable content for this control.

Related controls

• AU-09 — Protection of Audit Information: protects the integrity of audit records that serve as the evidentiary foundation for non-repudiation claims
• PM-12 — Insider Threat Program: leverages non-repudiation evidence to attribute insider actions to specific individuals during investigations
• SA-08 — Security and Privacy Engineering Principles: embeds non-repudiation requirements into system design from the earliest engineering phases
• SC-08 — Transmission Confidentiality and Integrity: protects messages in transit so that non-repudiation evidence attached to transmissions remains trustworthy
• SC-12 — Cryptographic Key Establishment and Management: governs the key lifecycle that underpins the digital signatures used for non-repudiation
• SC-13 — Cryptographic Protection: defines the approved cryptographic algorithms and mechanisms that AU-10 implementations rely on
• SC-16 — Transmission of Security and Privacy Attributes: ensures that identity and authorization attributes transmitted alongside actions support non-repudiation binding
• SC-17 — Public Key Infrastructure Certificates: manages the PKI certificates that validate the digital signatures used to prove authorship and approval
• SC-23 — Session Authenticity: verifies that sessions are authentic, preventing attackers from injecting actions into a legitimate session and repudiating them later

Frequently asked questions

What is NIST SP 800-53 AU-10

AU-10 requires organizations to provide irrefutable evidence that a specific individual or process performed defined actions such as creating information, sending messages, or approving documents. The control applies to systems at the HIGH baseline and mandates mechanisms like digital signatures and digital message receipts that bind a verified identity to each covered action. Organizations must define which actions fall under non-repudiation protection and deploy cryptographic mechanisms capable of producing evidence that withstands audit or legal scrutiny.

What happens if AU-10 is not implemented

Without AU-10, any individual who authored, transmitted, or approved sensitive information can deny their involvement, and your organization has no cryptographically verifiable evidence to prove otherwise. Auditors reviewing systems at the HIGH baseline will flag the absence of non-repudiation mechanisms as a finding, potentially expanding the scope of their review across your entire audit and accountability control family. The gap also weakens your legal posture in disputes over document authorship, contract execution, or approval workflows where digital signatures or signed receipts would otherwise provide definitive proof.

How do you audit AU-10

Start by reviewing the organization’s list of actions designated for non-repudiation protection and verifying that the list aligns with the system security plan. Examine system configuration settings to confirm that digital signature enforcement, certificate validation, and cryptographic algorithm selections are active and correctly applied to covered actions. Test the evidentiary chain by selecting sample audit records and verifying that each record contains a valid digital signature binding a verified identity to the action, along with a trusted timestamp that establishes when the event occurred.

What are examples of non-repudiation mechanisms

Digital signatures are the most widely deployed non-repudiation mechanism, using asymmetric cryptography to bind a signer’s verified identity to a document or action. Digital message receipts provide proof of transmission and delivery by generating a signed acknowledgment when a receiver accepts a message. Trusted timestamps issued by an independent timestamping authority establish when an action occurred, preventing disputes over timing. PKI certificates underpin all of these mechanisms by providing the identity verification framework that makes digital signatures and receipts trustworthy.