A digital signature that verifies perfectly today can become unverifiable in three years, without anybody touching the document. The certificate expires, the certificate authority retires the issuing key, the revocation information that proved the certificate was good at signing time is no longer published. The signature has not changed and the document has not changed, but a validator can no longer reach a confident answer. Long-term validation is the machinery that prevents this, and it is the difference between a signature that survives an archive and one that quietly rots.
Why signatures decay
Verification is not self-contained. To validate a signature a checker needs:
- the signer's certificate, and the chain of intermediate certificates up to a trusted root;
- revocation information — a CRL or an OCSP response — proving the certificate had not been revoked at the moment of signing;
- confidence about when the signing happened, so the previous two can be evaluated at the right point in time.
All three are external and time-sensitive. Certificates expire, typically after one to three years. CAs stop publishing revocation data for expired certificates. Intermediate certificates get replaced. Root programmes remove authorities. None of this is misconduct; it is normal lifecycle management. The consequence is that a signature relying on live external lookups has a shelf life measured in years.
Timestamps: fixing the "when"
A trusted timestamp is a signature over your signature, made by a Time Stamping Authority (TSA), attesting that the signed data existed at a particular moment. It is defined by RFC 3161 and is the foundation of everything else here.
Without one, the only signing time in the document is the value the signer's own computer reported — unverified, unsigned, and adjustable by anyone who can change a system clock. With one, an independent third party asserts the time, and that assertion is itself cryptographically verifiable.
This is what makes expiry survivable. If a certificate was valid from 2024 to 2027 and a trusted timestamp proves the signature was made in 2025, then in 2030 a validator can still conclude the signature was good when it was made — which is the question that actually matters. Without the timestamp, the same signature in 2030 is just "signed by an expired certificate", and no conclusion is available.
Free and commercial TSAs both exist; most e-signature platforms and certificate providers include timestamping, and Acrobat lets you configure a default TSA server under Preferences → Signatures → Document Timestamping.
Long-Term Validation: fixing the rest
A timestamp fixes the time. LTV fixes the availability of the validation material by embedding it in the document itself. When a signature is LTV-enabled, the PDF carries:
- the full certificate chain, not just the signer's certificate;
- the OCSP responses and/or CRLs collected at signing time, proving non-revocation then;
- all of it in a Document Security Store (
/DSS), a dictionary added to the file for exactly this purpose.
A validator in 2035 no longer needs to reach the CA's servers. Everything required is inside the file. This is why LTV matters for archives: it converts validation from a network operation into a local one.
Adobe Acrobat shows this as "Signature is LTV enabled" in the signature panel, and offers Add verification information on the signature's context menu when it is not.
Document timestamps and renewal
There is one remaining weakness: the timestamp itself is a signature, made with the TSA's certificate, which also expires — and cryptographic algorithms weaken over time. A timestamp from 2010 signed with SHA-1 is not something you want to be relying on in 2040.
The solution is timestamp renewal: before the outermost timestamp's certificate expires or its algorithm weakens, apply a fresh document timestamp over the whole file, including the previous one. Each new timestamp attests that everything beneath it existed and was intact at that moment. The result is a chain of timestamps, each protecting the ones before, extendable indefinitely.
This is exactly the archival practice: check your signed archive every few years and re-timestamp. It costs a batch job and preserves verifiability across decades. The general principle is the same one behind the OAIS model for document preservation — preservation is an ongoing activity, not a storage decision.
PAdES levels, briefly
The European standard for PDF signatures, PAdES (ETSI EN 319 142), names the levels so people can specify what they need:
- PAdES B-B (Baseline) — a basic signature, no timestamp. Fine for a document with a short life.
- PAdES B-T — adds a trusted timestamp. This is the minimum for anything with a horizon beyond the certificate's expiry.
- PAdES B-LT — adds long-term validation material: certificates and revocation data embedded in the DSS.
- PAdES B-LTA — adds archival timestamps, renewable as above. The level to require for records with a multi-decade retention obligation.
If you are writing a specification or evaluating a provider, these four labels are the vocabulary to use. "We need PAdES B-LTA" is a precise requirement; "we need signatures that last" is not.
Where this actually matters
Not every document needs LTV. It is worth the trouble when:
- The retention period exceeds the certificate lifetime, which is nearly always: certificates last one to three years, and record retention runs to seven, ten, or permanent. See document retention policies.
- The signature is evidential — contracts, deeds, board minutes, regulatory filings, anything that might be produced in a dispute years later.
- You are the archive. If you hold documents on other people's behalf, their verifiability is your responsibility.
- A regulator requires it. Several sectoral regimes specify archival-grade signatures explicitly.
It is not worth it for an internal approval that becomes irrelevant next quarter.
Practical steps
When signing:
- Configure a TSA and make timestamping the default, not a per-document choice. Most people who omit a timestamp did so by not knowing the option existed.
- Enable LTV at signing time if your tool supports it. Collecting revocation data at signing is easy; collecting it in 2033 is impossible.
- Sign the final document. Any later edit either breaks the signature or requires a second one, and a stack of partial signatures is a validation problem all of its own.
When archiving:
- Store the signed original untouched. Do not compress, convert, flatten, or "optimise" it — every one of those rewrites the bytes and breaks the signature. Keep working copies separately.
- Record the validation result at the time of receipt: a saved validation report is evidence even if the signature later becomes unverifiable.
- Diary a re-timestamping cycle — every three to five years is typical.
- Consider PDF/A-3 or PDF/A-4 alongside, since PDF/A addresses the rendering half of long-term readability while LTV addresses the evidentiary half. They are complementary, not alternatives.
When receiving:
- Check whether the signature is timestamped and LTV-enabled, not merely valid. Acrobat's signature panel states both.
- If it is neither and the document matters, you can add validation information yourself on receipt — Acrobat's Add verification information collects the current chain and revocation data. Doing so on the day it arrives is worth far more than doing it later. Verification technique is covered in how to verify a digital signature in a PDF.
Summary
Signatures depend on external, expiring information, so left alone they stop being verifiable. A trusted timestamp proves when signing happened, so certificate expiry stops mattering. LTV embeds the certificates and revocation data in the file, so validation stops needing the network. Archival timestamps, renewed every few years, extend the whole arrangement indefinitely. If a signed document has a retention period longer than a couple of years — and most do — B-T is the floor and B-LTA is the target.
