Your product claims that its signed audit records are non-repudiable evidence. What has to be true operationally for that claim to hold, and where do real systems usually fail it?

## The claim is about a system, not a primitive Unforgeability is a property of a scheme. Non-repudiation is a property of an **arrangement of people, keys, storage and process** whose cryptography is only one component. The principal-level answer is to enumerate what the arrangement must guarantee, and to be honest that most deployments claiming non-repudiation do not have it. ## Requirement 1 — exclusive control of the signing key A signature binds the *key holder*. So ask: who could possibly have used that key? - If a server-side service signs audit records with one key on behalf of all users, the record proves the *service* asserted something. That is tamper-evidence of the log, which is genuinely useful, but the user can repudiate it: "your system said I did that". - Binding a person requires a key only that person can use — hardware-backed, non-exportable, unlockable by something they hold or know, with the operation performed on the device rather than by a server holding the key. - Between organisations the equivalent is a key in a hardware security module with dual control over its use, an audit trail of signing operations, and no export path. Be precise about what your design actually achieves and use the accurate phrase: "tamper-evident log signed by the platform" is a defensible claim; "non-repudiable proof the user approved it" usually is not. ## Requirement 2 — identity binding The key-to-identity link is only as strong as the enrolment process that created it: who checked the identity, with what evidence, and what the certificate or directory entry actually asserts. A robust cryptographic chain over a self-service enrolment with an unverified email address inherits that weakness. Also decide what the binding means over time — after an employee leaves, after a rename, after a merge. ## Requirement 3 — trusted time A bare signature has no time. This creates a specific and severe failure: when a key is compromised, an attacker can produce signatures indistinguishable from earlier genuine ones, and can date the *content* however they like. Without independent time evidence, revocation forces a choice between accepting forgeries and discarding all history. The fixes are external: a timestamping authority countersigning your signature at a known moment, or inclusion in an append-only log whose entries are published and independently witnessed so a later insertion is detectable. Either way, the anchor must be created *before* the compromise, so timestamping is a routine part of signing, not a recovery action. This also resolves the revocation semantics question, the one people get wrong: the useful check is not "is the key valid now" but "was it valid at signing time, and can I prove when that was". ## Requirement 4 — storage the signer cannot rewrite If the party whose behaviour is being recorded also controls the store, they can delete inconvenient records, and deletion defeats signing entirely — a missing record has no signature to check. Countermeasures: append-only storage with hash chaining so gaps are detectable, replication to a party with different interests, periodic publication of a digest of the log, or a third-party witness. Notice this is orthogonal to signing and frequently omitted. ## Requirement 5 — verification, and long-term validity - **Someone must verify.** A signature nobody checks is a very expensive checksum. Verification should be routine and monitored, and failures must be alerted, not swallowed. - **Algorithms age.** Records that must remain evidential for years outlive their hash and signature schemes. Plan re-timestamping or re-signing under stronger algorithms *before* the old ones are broken, because a signature made with a broken hash proves nothing retroactively. - **Keep what verification needs**: the exact signed octets, the certificate chain as it was at signing time, revocation information and the timestamp token. Verification years later fails without the contemporaneous material. ## Requirement 6 — the human gap When a person is being bound, what they saw is not necessarily what was signed. If the signing device renders one document and the signature covers a different byte stream, or if the approval interface shows a summary while the payload contains more, the person can credibly deny intent. Trustworthy display, signing over exactly the rendered content, and covering every field the consumer relies on are part of the claim. ## Where systems actually fail In rough order of frequency: one shared platform key doing all signing; signing keys in configuration, environment variables or repositories, so "exclusive control" is fiction; no time anchoring, so compromise erases history; logs signed and stored by the party they incriminate; verification that never happens in practice; no plan for algorithm ageing; and a bare signature used where freshness or audience checks were also required. A per-signature nonce leaking the private key when randomness is reused is a further sharp edge in some schemes and belongs to key-generation and randomness discipline. ## When not to claim it Non-repudiation carries real cost: hardware key custody, enrolment processes, timestamping, retention and legal framing. If your actual requirement is tamper-evidence and attribution *inside* one trust domain, a much cheaper design suffices and you should say so, rather than shipping a claim you cannot defend when it is challenged. Choosing not to claim non-repudiation is frequently the correct architectural decision.