Long-term PDF validation: why a compliant PDF today may fail verification in 2035

A document archive is only useful if the documents in it can be verified at the time an auditor asks for them. Not at the time you created them. Not when your lawyers want them. When someone outside your organization asks you to prove something.

For digitally signed and timestamped documents, verification has a shelf life. The cryptographic mechanisms that make a PDF/A-3 document trustworthy today depend on certificates, algorithms, and trust chains that can expire, be revoked, or be deprecated. Building a document archive without planning for this is building an archive that will fail at the worst possible moment.

The problem with certificate-dependent verification

A PDF digital signature is verified using a chain of certificates: the signer’s certificate, the issuing CA’s certificate, and the root CA’s certificate. Each certificate has a validity period, typically one to three years for end-entity certificates.

If you verify a signature after the signer’s certificate has expired, the verification will fail unless the verifier can establish that the certificate was valid at the time of signing. Establishing that requires:

1. Knowing when the document was signed (a trustworthy timestamp)
2. Having the certificate revocation status at the time of signing (OCSP response or CRL)
3. Having the full certificate chain as it existed at signing time

Five years after signing, the certificate is long expired. The CA may no longer be operating. The OCSP responder is definitely no longer serving responses for that certificate. The revocation status from signing time exists nowhere online.

Without this information, a strict verifier will refuse to confirm the signature, even if it was perfectly valid when applied.

Long-Term Validation (LTV)

Long-Term Validation (LTV) is the technique for embedding the evidence needed for future verification directly inside the document. The standard for PDF is defined in ETSI EN 319 132 (PAdES) and ISO 32000.

An LTV-enabled PDF/A-3 document contains:

• The signature and timestamp tokens (as always)
• The full certificate chain of every certificate involved in signing and timestamping
• The revocation information (OCSP responses or CRL snapshots) captured at the time of signing, while the certificates were still valid and the OCSP responders were still operational

With this information embedded, a verifier in 2035 can reconstruct the complete trust chain as it existed in 2026 without any network access.

Adding LTV information requires embedding it before the certificates involved expire. This is typically done immediately after signing, or within a short window, not years later.

Algorithm deprecation

SHA-1 was deprecated as a signature algorithm in 2017. Certificates signed with SHA-1 are no longer trusted by major verifiers. Any PDF signed with a SHA-1 certificate is now unverifiable in strict mode.

SHA-256 is the current standard and is expected to remain secure for the foreseeable future, but “foreseeable future” in cryptography is a qualified term. NIST has been working on post-quantum cryptographic standards since 2016, and the transition to quantum-resistant algorithms is expected to occur within the next 10 to 15 years.

For a document that must remain verifiable until 2040, the signing algorithm chosen in 2026 may have been deprecated before the archive period ends. The mitigation is archival timestamping: applying a new timestamp before the old one’s algorithm is deprecated, with the new timestamp covering the document plus the old timestamp. This preserves the chain of trust across algorithm transitions.

Archival timestamping

An archival timestamp extends the validity of a timestamped document past the point where the original timestamp’s algorithm or certificate might be considered weak.

The process:

1. The document has an existing RFC 3161 timestamp from 2026
2. Before SHA-256 is deprecated (hypothetically, around 2036), you request a new timestamp
3. The new timestamp covers the document plus the existing 2026 timestamp token
4. The new timestamp uses the current recommended algorithm (quantum-resistant, circa 2036)
5. A verifier in 2040 verifies: the 2036 timestamp (using the 2036 algorithm) covered the 2026 timestamp, which covered the document with its original hash

This chain telescopes the trust: each new timestamp vouches for all previous ones. You do not need to re-sign the original document; you only need to add a new timestamp before the previous one becomes cryptographically insufficient.

For a 10-year tax archive, a single re-timestamp at the midpoint is usually sufficient. For 20-year or 30-year archives (medical records, real estate, public procurement), a re-timestamping schedule should be established at the time of initial archiving.

Font and color profile stability

Cryptographic concerns aside, PDF/A-3 has a simpler long-term advantage over regular PDF: it mandates that all fonts and color profiles be embedded in the file. A PDF that references an external font or uses a system color profile may render differently in ten years when the font is no longer installed or the color profile has been updated.

PDF/A-3 prohibits external references, JavaScript, and any content that requires runtime resolution. What is in the file is everything that is needed to render it identically on any conformant viewer, now and in the future.

This is why PDF/A-3 is the correct archival format for any document that must be readable by a human auditor years from now. A regular PDF that validates today may look wrong or be unreadable in 2035 not because of cryptography, but because a font renderer changed.

Validating long-term archives

VeraPDF is the reference implementation for PDF/A validation. It is open source, maintained by the PDF Association and the Open Preservation Foundation, and is the tool used by national archives and regulatory bodies across Europe.

Running VeraPDF against a PDF/A-3 archive confirms:

• The document conforms to ISO 19005-3 (PDF/A-3)
• All fonts are embedded
• Color profiles are self-contained
• No prohibited features (JavaScript, external content, encryption) are present
• The XMP metadata is valid and correctly identifies the conformance level

VeraPDF does not validate cryptographic signatures or timestamps. For those, use a PAdES-aware verifier such as the ETSI Signature Validation API or DSS (Digital Signature Service), the open-source library maintained by the European Commission.

A complete long-term validation workflow runs both: VeraPDF for PDF/A conformance, DSS for signature and timestamp verification.

Building archives that survive their retention period

The practical checklist for a document archive that will remain verifiable at the end of its retention period:

1. Use PDF/A-3 for all archived documents (all fonts and color profiles embedded)
2. Apply PAdES signatures with LTV information embedded at signing time
3. Use RFC 3161 timestamps from TSAs on the EU Trusted List
4. Include the full certificate chain and revocation data in the document at archiving time
5. Store documents in WORM storage with compliance-mode retention locks
6. Include a re-timestamping schedule in your retention policy, triggered before any embedded certificate or algorithm approaches deprecation
7. Verify the archive periodically (annually for long-retention archives) using VeraPDF and DSS

Steps 1 through 4 are executed at archiving time. Steps 5 through 7 are operational commitments for the life of the archive.

SealDoc and long-term validity

SealDoc generates PDF/A-3 documents with LTV-enabled signatures and RFC 3161 timestamps from qualified EU TSAs. The certificate chains and OCSP responses are embedded at the time of document creation, not retroactively.

The evidence pack includes the verification material: the full certificate chain, the revocation snapshots, and the timestamp tokens in their original CMS encoding. An auditor in 2035 can verify the pack using VeraPDF, DSS, or OpenSSL without any network access or any dependency on SealDoc’s infrastructure.

Re-timestamping for long-retention archives is available as a scheduled operation via the SealDoc API, allowing organizations to maintain algorithmic currency for archives that extend past the expected lifetime of current cryptographic standards.