Your signed documents have an expiry date on their proof

Michael Eagles, founder of SignedBy · 15 August 2026

Take a contract you signed electronically. It is sitting in a folder somewhere, and as far as you are concerned it is settled — signed, filed, done.

There is a date, probably in the mid-2030s, after which nobody will be able to demonstrate that it was validly signed.

Not that it becomes invalid. Nothing about the document changes. What changes is your ability to show it was valid, from the file alone, to someone who was not there.

We found this in our own product first.

Where the date comes from

An electronic signature is only as demonstrable as the certificate behind it, and certificates expire. That is not a flaw; it is the design.

So a signature carries a timestamp from a trusted authority, proving the signature existed while its certificate was still valid. Now the question moves up a level: that timestamp has a certificate too, and that one expires as well.

Follow the chain to the end and you arrive at a date. After it, the outermost proof can no longer be checked, and the whole structure beneath it stops being demonstrable.

Ours is 2037-06-24.

We checked a document signed through another vendor — a competent setup, using two separate qualified providers — and theirs is 2035-12-13.

Eleven years is fine for an invoice. It is not fine for a lease, a shareholders’ agreement, a construction contract, or anything with a retention schedule attached.

The obvious fix, and why we tested it

The standards have an answer: an archive timestamp. Apply a fresh timestamp over the whole document, and its newer certificate carries the proof forward.

That is what PAdES-LTA is for, and the library we use exposes it. So we ran it, against two authorities, on a real sealed document.

It worked, mechanically. The timestamp count went from one to two. The archive timestamp landed correctly. Nothing broke.

And the horizon did not move.

One of them made it worse.

Why

Because the archiving authority’s certificate expires at roughly the same time as the original one. Everybody’s does. Public timestamp authorities issue certificates on similar cycles, so the new proof inherits approximately the old horizon — or, if you happen to pick an authority whose certificate is younger, a shorter one.

This is not a bug in the library. It is how the mechanism actually works, and it is easy to misread. Applying an archive timestamp once, ticking the box, and believing the problem is solved is a mistake we were on course to make ourselves.

The horizon only extends through repeated re-timestamping: each new timestamp applied while the previous one is still valid, indefinitely, for as long as the document needs to stay provable. Miss a window and the chain is broken — and unlike most maintenance, you cannot fix it retroactively.

The consequence is uncomfortable. The thing that keeps a document provable is not a cryptographic operation. It is someone reliably remembering, for years, to perform one. That is a process, not a feature, and no library call substitutes for it.

Check your own

We built a page that reads any signed or timestamped PDF and tells you, among other things, that date.

It runs entirely in your browser. The file is not uploaded — it is not sent anywhere, including to us, and the page is served under a Content-Security-Policy that makes network requests impossible rather than merely absent. Save it with ⌘S and it works offline, forever, with no internet and nobody’s servers.

Drop in something you signed. The line you want begins “Provable until…”.

Checking the tool

A verification tool asking to be trusted is a contradiction, so: the source is at github.com/signedbyai/verifiedby, Apache-2.0. It is one file, small enough to read.

Publishing source for a hosted page proves nothing on its own — nothing forces the served bytes to match the published code. So confirm they do:

curl -s https://verifiedby.dev | shasum -a 256
node build.mjs && shasum -a 256 index.html

Those must match, and a CI job checks the same thing daily, in public. The rubric is published too: what is checked, in what order, what each verdict means, and what would have to be true for each to be wrong. A tool that only documents its strengths is marketing.

Method

The test ran against a real sealed PDF, trying two timestamp authorities in turn. Results were corroborated independently with pyHanko and asn1crypto rather than trusting our own output — worth doing, because both runs produced identical file sizes and the same generation time to the second, which looks like a copy until you check. It is not: the signature placeholder is fixed-width, and the requests landed in the same second.

Certificate expiries were read from the embedded certificates, not inferred.

What we are not claiming

The 2037 date is not a countdown to disaster. The seal is valid today, trusted by Adobe’s own trust list, and self-verifying. Eleven years is adequate for most commercial documents, and if yours are among them this is not urgent.

We are also not claiming other vendors are careless. The document we checked was signed competently, using two qualified providers, and its horizon is finite for exactly the same structural reason ours is. Nobody in this market has solved it. That is the point.

Nor does this tool fix anything. It tells you a date. What to do about that date is a separate question, and an honest one to sit with rather than answer quickly.