What makes a PDF court-ready

A signature image proves almost nothing. What holds up is the evidence around it: a content hash, a full audit trail, and a cryptographic attestation that the file has not moved since.

“Legally binding” is the phrase every e-signature vendor puts on the homepage, and it is close to meaningless on its own. Under the ESIGN Act and UETA in the US, and as a Simple Electronic Signature under eIDAS in the EU, an electronic signature is generally as valid as an ink one. That was settled two decades ago. It is not the interesting part.

The interesting part is what happens when someone denies signing. At that point nobody cares that the signature was legal in principle. What matters is what you can show: who signed, from where, when, what exactly they were looking at, and whether the document has changed since.

The signature image is not the evidence

A cursive rendering of someone's name is trivially forgeable and proves nothing on its own. It is a visual convention — a marker of intent that a human can recognise on a page.

The evidence is everything recorded around that marker, and whether that record can be shown not to have been edited afterwards.

What is inside a Usign signed PDF

When a contract reaches its signed state, a pipeline produces one PDF containing four things:

1. What the signer actually saw

The contract rendered with merge values substituted, every signer field filled, and signature images placed — laid out to match the signing screen. Not a template plus a diff, but the document as presented.

2. The audit log, appended

The final pages carry the contract's full event history: creation, sends, views, each signature, declines — with timestamps, IP addresses, and geolocation. The evidence travels inside the file rather than living in a dashboard you might lose access to.

3. A content hash in the metadata

A SHA-256 hash of the contract content at signing time, embedded in the PDF's metadata. Anyone holding the file can recompute it. If a clause was altered after the fact, the hash no longer matches.

4. A cryptographic signature over the whole thing

The PDF carries a PAdES baseline signature applied with Usign's signing key. Any standard reader — Acrobat, a browser's built-in viewer — detects it, reports whether the document has been modified since signing, and identifies Usign as the signer.

The signing certificate is embedded in the file, so a verifier reads it out of the PDF rather than fetching anything from us. Revocation data (OCSP, CRL) is not embedded — a self-signed certificate has no revocation source to embed. That property is what the “LT” in the PAdES long-term profiles actually means, and it arrives together with a CA-issued certificate and a timestamp authority, not before.

What that signature actually attests

This is the distinction most vendors blur, so it is worth being exact.

The cryptographic signature is Usign's, not the signer's. Your signers do not hold private keys — they are Simple Electronic Signature signers, not holders of an advanced or qualified certificate. The signature says: Usign produced this PDF in this state; this is what the signer was shown; this is what the signer signed.

That is a claim about custody and integrity, backed by a trail. It is not a claim about cryptographic identity, and any vendor implying otherwise for a click-to-sign flow is overselling.

The signing time is our server's clock at the moment of signing, not a token from an independent RFC 3161 timestamp authority. That is sufficient for a Simple Electronic Signature; it is not the same as a time that a third party attests to, and we would rather you knew which one you have.

Why the trail beats the artifact

In a dispute the sequence is what carries weight. A contract sent to maya@example.com at 14:02, opened from a Lagos IP at 14:09, signed at 14:11 from the same address, with the document hash unchanged from creation through signature, is a coherent story that is hard to argue with.

A PDF with a signature image on it and no surrounding record is a picture. The reason Usign records every view and every send, and appends all of it to the file, is that the trail — not the image — is what an adjudicator reads.

Verifying a file you have been handed

1. Open it in any PAdES-aware reader. It reports whether the document has been modified since signing, and who signed it — expect the unknown-validity warning described above, and read the modification status underneath it.
2. Read the audit appendix at the back. Timestamps, IPs, and geolocation for every event.
3. Recompute the SHA-256 content hash in the metadata against the rendered content.

All three work offline, on the file alone. Nothing depends on Usign still existing — which is the correct property for a document that may be read in five years.

The questions worth asking any vendor

• Is the audit trail inside the file, or only in your dashboard?
• Is there a content hash, and can I recompute it myself?
• Whose key signs the PDF, and what exactly does that signature assert?
• Does the signature stay verifiable after your certificate expires?
• What is recorded on a view, not just on a signature?

The answers should be specific. Where they are marketing adjectives instead, that is the answer.

Our own answers, since it would be cheap not to give them

Audit trail inside the file: yes, appended as pages. Recomputable content hash: yes, SHA-256 in the metadata. Whose key signs it: Usign's, attesting custody and integrity, not the signer's cryptographic identity. Recorded on a view as well as a signature: yes. Still verifiable after our certificate expires: not yet — that needs embedded revocation data, which needs a CA-issued certificate and a timestamp authority. Two of those three are roadmap, and we would rather write that down than let you find out by opening a file.