What it means
Non-repudiation concerns evidence that supports the origin, submission, delivery, or integrity of an action or message when someone later disputes it. A digital signature can support this by binding signed data to a signing key and allowing alteration to be detected. The surrounding process still matters: how the key was associated with an identity, who controlled it, whether it was compromised, and how evidence was retained. A username in an application log is useful attribution evidence but does not automatically establish non-repudiation, human intent, or a legal conclusion.
The idea at a glance / Evidence
A signature supports a later review of exact bytes.
Keep a valid original signature beside the key association, receipt and unresolved human intent.
Fictional SupplierDesk’s registry binds public key K201 to its supplier signing service. That service signs exact UTF-8 purchase order PO201 with quantity 10 and a final newline. Receiver receipt R201 and the original signature are retained. A later independent verifier compares the original with a copy changed to quantity 11. The private key stays at the signer.
READ THE PICTURE
Evidence for later review
PO201 quantity 10 verifies with K201; the changed quantity 11 copy fails. Registry and R201 supply separate context, while individual intent and approval remain unresolved.
Keep in mindThe registry association and evidence custody are assumed, not established by signature arithmetic. The local Ed25519 exercise is not a certified implementation, real contract or legal conclusion. Key status at signing, compromise history, individual key access, human understanding and transaction approval need separate evidence. A receipt record supports what this receiver recorded; it is not proof of every later delivery or action.
Read the complete example
- Evidence for later review. PO201 quantity 10 verifies with K201; the changed quantity 11 copy fails. Registry and R201 supply separate context, while individual intent and approval remain unresolved. The signed byte sequence is PO201, LF, quantity=10, LF, encoded as UTF-8. A generated Ed25519 private key signs those complete bytes and remains with the synthetic signing service. The retained public key K201 lets an independent verifier check the original signature later. Original bytes verify; replacing 10 with 11 under that same signature fails, as does using a different public key. The assumed trusted registry associates K201 with SupplierDesk’s supplier signing service, not automatically with a named human. A distinct local receiver stores R201 with the exact document digest and receipt time; this is receipt evidence from that service, not proof that a human read or approved it. Later verification retains the original bytes, signature, public key and receipt. Key custody, identity proofing, compromise history, approval authority and human intent are separate review questions. These bounded records can help evaluate a later denial; no legal outcome or impossible-repudiation guarantee follows.
The registry association and evidence custody are assumed, not established by signature arithmetic. The local Ed25519 exercise is not a certified implementation, real contract or legal conclusion. Key status at signing, compromise history, individual key access, human understanding and transaction approval need separate evidence. A receipt record supports what this receiver recorded; it is not proof of every later delivery or action.
Diagram references: NIST: contextual definitions of non-repudiation · NIST FIPS 186-5: signature and key assurances
AN ILLUSTRATIVE SCENARIO
A later reviewer compares the signed order and changed copy
SupplierDesk’s service signs exact PO201 quantity 10 bytes. The retained K201 public key validates the original; the same signature fails for quantity 11. An assumed registry links that key to the service, while R201 separately records receipt. A later reviewer still needs key custody, compromise history, identity and approval evidence to interpret a human denial. Signature arithmetic alone establishes no legal result.
Put it to work
- Define the event a later reviewer must be able to establish and the applicable assurance requirements. Specify whose identity, what exact content, and which point in the transaction need evidence.
- Use an established signing and verification process where appropriate, with controlled key custody and identity binding. Preserve the signed content and validation context rather than retaining only a screenshot of approval.
- Protect evidence over the necessary retention period and plan for certificate expiry, key compromise, and later validation. Keep duties and credentials distinct enough to support meaningful attribution.
How to check your work
Verify a test signature, then change the document and confirm validation fails. Review how the signing identity was established, who could use its key, and whether an independent reviewer can validate the retained evidence later.
Connect the ideas
- Audit trail
An append-oriented history of security-relevant actions that can be shown to a later reviewer.
- Integrity
The property that data and processes remain complete and unaltered except by authorized action.
- Identity
The record an organization uses for a person, device, or workload that can be authenticated.