Long-Term Validation (LTV): How a Signed PDF Stays Verifiable for Decades

Long-term validation (LTV) keeps a digital signature checkable after its certificate expires. It works by sealing two things into the PDF at signing: proof of when the signature was made, and proof that the certificate was valid at that moment.

The certificate behind a digital signature is usually valid for a few years at most. The documents it signs often need to last much longer. A lease runs for five years, a loan for twenty, and a deed of sale matters for as long as the property is owned. LTV is what closes that gap.

The problem: signatures are checked in the present

When a PDF reader verifies a signature, it doesn’t just check the math. It also asks whether the signer’s certificate was valid and hadn’t been revoked. Left to itself, it asks that question about today.

Open the same contract ten years from now and the answers have changed. The certificate has expired. The certificate authority’s revocation services may have moved or closed, so the reader can’t confirm the certificate was never revoked. The document hasn’t changed by a single byte, but the reader can no longer vouch for the signature, and it says the validity is unknown. The proof has decayed while the document stayed the same.

What LTV adds

LTV fixes this by moving the questions from the present to the moment of signing, and by storing the answers in the file.

• Proof of when. A trusted timestamp under RFC 3161, issued by a timestamp authority, records when the signature was made. The question is no longer whether the certificate is valid today, but whether it was valid then.
• Proof of status at that moment. The certificate chain and its revocation status at signing, in the form of OCSP responses or certificate revocation lists, are captured and embedded in the PDF.

With both inside the file, a reader can validate the signature years later, offline, without reaching any outside service. Adobe Acrobat marks a signature like this as LTV-enabled in its signature properties.

Where the standards go further

The European PAdES standard for PDF signatures names these stages as levels: B-T adds a timestamp, B-LT adds the validation material, and B-LTA adds archive timestamps that can be renewed over the years, so the proof survives even if today’s cryptographic algorithms weaken. That last concern is real for records kept for decades, and it is one reason Twala adds a second, independent proof outside the signatures, described below.

How Twala handles it

Every completed document on Twala gets the same treatment before it is filed:

1. Converted to PDF/A-2b. The archival PDF standard (ISO 19005-2) embeds what the file needs to display, such as fonts, so it renders the same decades from now.
2. Sealed with a timestamp. The Twala Platform Seal, a digital signature over the finished PDF, carries an RFC 3161 timestamp, and so does every other signature Twala applies.
3. Validation evidence embedded. When every signature on the document has it, long-term validation evidence, the certificate chain and its revocation status at signing, is embedded, so the signatures stay checkable after their certificates expire.
4. Fingerprint anchored. The sealed file’s SHA-256 fingerprint is anchored on the Polygon blockchain with HashOrigin™.

“When every signature has it” is deliberate. A document counts as LTV-enabled only if each signature on it embedded its revocation evidence. If a certificate authority’s revocation service doesn’t answer at the moment of signing, Twala doesn’t make the signers wait for it; the document is completed and sealed, but it isn’t counted as LTV-enabled.

The anchor is the second, independent proof. It doesn’t expire, doesn’t depend on any certificate authority’s servers, and can be checked with public blockchain tools using the document’s anchor proof, which you can download alongside the PDF. If the signatures ever can’t be validated, the anchor still shows that this exact file existed, unchanged, when its batch was anchored. Our HashOrigin explainer shows how.

A records checklist

• Keep the original PDF. The signatures and their validation evidence live in the file. A printout, a scan, or a “print to PDF” copy carries none of it.
• Don’t edit or re-save signed files. Saving changes in an editor adds to the file, and those changes show up as modifications after signing.
• Check LTV on receipt. In Acrobat, open the signature properties and look for LTV. For Twala documents, Twala’s verify page checks the seal and the anchor in one step.
• File the anchor proof with the document. Download it from the document’s record details and keep both together for the life of the record.
• Store notarized documents the same way. An eNotarized document is also entered in the notary’s Electronic Notarial Book and uploaded to the Supreme Court’s Central Notarial Database, but your own copy should still be the original PDF.

For when a document needs a digital signature at all, see eSignature, digital signature, or eNotarization. The standards Twala builds on are listed on the HashOrigin technology page.

Twala is a Supreme Court-accredited Electronic Notarization Facility (ENF). HashOrigin™ is a trademark of Ohelio Inc.