Non-repudiation: a careful definition for compliance and claims teams
Non-repudiation is the property a system aims for when it tries to make it hard for a party to credibly deny having sent, approved or submitted something, by producing a record an independent third party can check without relying on either side's account.
What does non-repudiation mean?
The word gets used in two registers that do not quite line up, which is the source of most of the trouble.
In the engineering register it is narrow and precise. FIPS 186-5 defines it as "a service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified and validated by a third party as having originated from a specific entity in possession of the private key". Read the last clause slowly. The assurance runs to the key, not to the human.
In the operational register it gets shorter and looser. NIST SP 800-53 Rev. 5 phrases it as "protection against an individual who falsely denies having performed a certain action". By the time it reaches a vendor datasheet it has usually become "the customer cannot deny they submitted it", which is a claim the underlying technology does not make.
How non-repudiation is supposed to work
- A credential only one party should hold, typically a private key, sometimes an authenticated session.
- A signature over the actual content, so the record covers what was submitted rather than the fact that something was.
- Independent verifiability, so a third party can check it without the system that produced it. That is the job of public key verification.
- A tamper-evident log of the surrounding events, not just the final artefact.
- A time reference from the receiving system rather than from a device clock anyone can set.
Get all five and you have a strong record. What you do not have is proof of who was holding the phone.
Why non-repudiation is contestable in law
Carl Ellison and Bruce Schneier made the argument plainly in "Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure" (2000). Their second risk, "Who is using my key?", points out that vendors took a cryptographic term and pressed it into legal service. The cryptographic claim is only that the signature algorithm is not breakable. It was never that a named human intended to sign.
Everything that breaks the link between key and person is ordinary rather than exotic. A shared workstation. A phone handed to a colleague. Credentials in a password manager the whole team can open. Malware. A family member completing a capture on someone's behalf because the policyholder is in hospital. Duress. None of that is a cryptographic failure, and all of it is a real defence.
The legal instruments are correspondingly modest. Article 25(1) of the eIDAS Regulation (910/2014) says an electronic signature "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form". Article 25(2) goes further for one specific category: "a qualified electronic signature shall have the equivalent legal effect of a handwritten signature". Which is worth sitting with, because handwritten signatures get disputed in court all the time.
Non-repudiation example: the approval nobody remembers giving
A fleet manager approves a 4,000 euro repair through a link sent to his phone. The record holds the session events, his answers, the signed package and the receipt time. Six months later he disputes ever authorising it and says an apprentice had his phone in the yard that afternoon.
The record does real work here. It moves the burden: he now has to explain how his device came to be used, rather than the supplier having to prove anything happened at all. It does not end the argument, and a policy that assumed it would has put the supplier in a worse position than an honest one.
How non-repudiation differs from authentication and integrity
- Authentication asks who is presenting themselves right now, at the moment of access.
- Integrity asks whether the data has changed since it was recorded or received.
- Non-repudiation asks whether a party can plausibly walk away from it later, which needs both of the above plus independent verifiability and a reliable time reference.
They are frequently sold as one feature. They fail separately, and a case can turn on which of the three you actually have.
How to write it into a policy without overstating it
Describe the record, not the conclusion. "The submission is signed on receipt, the session events are logged in server time, and the package can be verified by a third party using our published key" is defensible in front of an ombudsman. "Submissions cannot be repudiated" is not, and the first time someone tests it you lose more than the point.
Three habits keep this honest. Say "supports" rather than "proves". Keep a human decision-maker between the record and the outcome, the same discipline that applies to evidence integrity generally. And treat a sealed submission as a strong starting position in a dispute rather than the end of one, with the chain of custody carrying the rest.
Harder to deny is not the same as impossible to deny. The gap between those two phrases is where the cases get fought, and it is better to know that before you are in one.