Imagine a contract that was signed electronically three years ago. The file still opens, and the signature still looks fine. But here is a fair question: could you actually prove, today, that the signature was valid the moment it was signed? And could you prove the same thing ten years from now? For most digital signatures, the honest answer is no. That is exactly the problem that PAdES (PDF Advanced Electronic Signatures) and Long-Term Validation(LTV) are built to solve.
PAdES, defined by ETSI standard EN 319 142, is the European standard for adding digital signatures to PDF files. LTV is the part of PAdES that stores everything a signature needs to be trusted, the certificates, the revocation checks, and a trusted timestamp, directly inside the PDF. Because all that proof travels inside the file, the signature can still be checked years later, even if the services that originally issued it no longer exist. To understand why LTV is needed, it helps to first see why an ordinary digital signature does not stay trustworthy forever.
Why Digital Signatures Stop Working over Time
A digital signature relies on public key infrastructure (PKI). The signer holds a private key tied to a digital certificate issued by a trusted Certificate Authority; signing creates a unique fingerprint of the document and locks it with that key, so anyone with the matching public key can confirm the document is unchanged. This works well in the short term, but none of the pieces last forever: certificates expire after one to three years, Certificate Authorities shut down, the online services that confirm a certificate is still trusted go offline, and over time the underlying mathematics becomes easier to break.
When that happens, anyone checking the signature years later hits a wall: they cannot confirm the certificate was valid when it was used, cannot check whether it was later revoked, and may no longer trust the algorithm. The document still exists, but the proof behind it is gone, which is a real and costly risk in a dispute or an audit.
LTV removes this dependency on outside services: it stores all that proof inside the document at the moment of signing, and locks in the exact time of signing so the signature is always judged as of that date. That is why an LTV signature stays valid long after the signer’s certificate has expired. To see how it builds that proof, it helps to look at how PAdES is put together.
What PAdES and Long-Term Validation do
PAdES is one of a few signature formats recognised in Europe, and it is the right one to use for PDF files. It works in levels, where each level adds more protection than the one before. You do not need to memorise the technical names, but the idea behind each step is worth understanding.
PAdES defines four levels, each building on the one before. The table below shows what each adds and how long the resulting signature can be trusted.
| PAdES level | What it adds | How long it can be trusted |
|---|---|---|
| B-B (Baseline) | The signature plus the signer’s certificate. | Only while the certificate is still valid. |
| B-T (Timestamp) | A qualified timestamp from a Qualified Trust Service Provider (QTSP), proving when the document was signed. | Establishes signing time, but verification still depends on obtaining certificate and revocation information from external sources. |
| B-LT (Long-Term) | The full certificate chain and revocation data, stored inside the PDF. | Verifiable from the file alone, with no external service needed. |
| B-LTA (Long-Term + Archival) | A cryptographic timestamp token that seals all stored proof; renewable before it expires. | Decades, provided the cryptographic timestamp is renewed on schedule. |
As a simple rule, any document that needs to last more than a few years should use at least the long-term validation level, and any document that must stay valid for decades should use the highest level together with a renewal plan. All of this is becoming far more pressing because of new European rules, which is where we turn next.
Why It Matters Now: eIDAS 2.0 and EU Digital Wallets
Europe has a regulation called eIDAS that sets the rules for electronic signatures. The updated version, eIDAS 2.0, has been in force since 2024. It keeps the strongest type of signature, the Qualified Electronic Signature, or QES, which carries the same legal weight as a handwritten signature. What changes is how easily these signatures can be created.
The biggest new idea is the EU Digital Identity Wallet. Under Regulation (EU) 2024/1183, every EU Member State must make at least one compliant EU Digital Identity Wallet available by the end of 2026. It is a phone app that lets people create a qualified signature straight from their smartphone, with no physical card or USB token. The EU’s Digital Decade target is for 80% of its citizens to be using a digital identity solution by 2030, so the number of legally binding signed documents is about to grow enormously.
That growth is exactly why LTV matters so much. Employment contracts, healthcare forms, property records, and legal filings signed this way may need to be checked five, ten, or even thirty years later. If LTV is not built into the signing process from the start, those documents slowly drift into legal uncertainty as their signatures age.
There is also a longer-term concern worth keeping in mind. Powerful quantum computers, which many experts expect within the next couple of decades, could one day break the mathematics behind today’s signatures. Quantum-safe algorithms have already been standardised, including the signature schemes ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) finalised by NIST in 2024, so any document meant to stay valid well beyond 2030 should be built so its cryptography can be upgraded later, a flexibility often called crypto-agility.
For software and firmware signing in particular, the NSA’s CNSA 2.0 suite sets a firmer deadline. Vendors should support and prefer post-quantum algorithms by 2025 and use them exclusively by 2030. It approves only ML-DSA-87 (FIPS 204) and the hash-based LMS/XMSS (NIST SP 800-208) for signing, not SLH-DSA. Knowing all this is one thing; getting it right in practice is another, so the checklist below distils it into the habits that actually keep a signature valid.
Getting LTV Right: A Practical Checklist
Most broken long-term signatures fail for ordinary, avoidable reasons, not exotic cryptography. These are the habits that keep a signature verifiable for the long haul:
- Sign at the long-term level (B-LT) as a minimum, and use B-LTA for anything that must survive for decades.
- Use a qualified timestamp service (QTSP), and apply the timestamp at the moment of signing, never bolt it on afterwards.
- Store the revocation data (OCSP or CRL) inside the PDF; don’t just check it once and discard it.
- Keep signing keys in a Qualified Signature Creation Device (QSCD), typically a certified hardware security module (HSM), as qualified signatures require.
- Renew archival timestamps before they expire, because a missed renewal cannot be repaired later.
- Never flatten or re-save a signed PDF in a tool that isn’t signature-aware, as that can silently break it.
- Build for crypto-agility, so today’s algorithms can be upgraded to quantum-safe ones without starting over.
None of this is difficult in isolation. The hard part is doing all of it consistently, across every signing workflow and for years on end, which is where outside expertise earns its keep.
How Encryption Consulting Can Help
This is exactly what Encryption Consulting’s CodeSign Secure is built to do. It signs documents and code with private keys that are generated and stored inside a FIPS 140-2 Level 3 HSM and never leave it, and it applies RFC 3161 secure timestamps at the moment of signing, the same foundation that long-term validation depends on. Before a signature is ever applied, the platform validates the integrity of what it is signing, and every signing action is governed by role-based access control, M-of-N quorum approvals, and a complete, signed audit trail. So, you can prove not only that a file was signed, but exactly when, by whom, and under which policy.
CodeSign Secure is also built for the long horizon this blog is about. It ships with native post-quantum support, including the ML-DSA and LMS (Leighton-Micali Signature, NIST SP 800-208) signature algorithms, and offers hybrid signing that pairs a classical algorithm with a quantum-safe one, so signatures created today stay trustworthy as standards change. It runs on-premises, in the cloud, or as a hybrid deployment, integrating with leading HSMs and your existing CI/CD pipelines. Whether you are preparing for the EU Digital Identity Wallet rollout or safeguarding a long-term archive of signed documents, it gives you a single, verifiable place to sign with confidence.
Conclusion
A signature you cannot prove later is not really a signature you can rely on. PAdES and LTV close that gap by storing all the proof, the certificates, the revocation checks, the timestamps, and the archival seal inside the signed PDF. That turns a fragile file into something that stays valid for decades.
With eIDAS 2.0 and EU Digital Identity Wallets about to put qualified signing in the hands of millions of people, the number of long-lived signed documents is going to climb quickly. Organisations that have not built LTV into their signing process will face growing legal risk as their older documents pass the point where their signatures can still be trusted.
The path forward is clear, and the checklist above captures it: sign at the long-term level, prove the time of signing, keep the proof inside the file, and stay ready to renew timestamps and upgrade cryptography as standards change. Do that, and your signatures will still hold up long after they were created.
If you would like to check your own signing setup against these points, or you are planning for the EU Digital Identity Wallet, reach out to us for a technical consultation.
