PAdES and Long-Term Validation (LTV)

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.

PAdES itself is a document-signing standard, not a code-signing one; it is not what secures an executable, an installer, or a firmware image. But enterprise code signing faces the exact same long-term validation problem PAdES was built to solve, and for the same reason: a signed artifact often has to remain verifiable for years after the certificate that signed it has expired. The rest of this post uses PAdES’s LTV model as a concrete illustration of that problem and its solution, then maps it directly onto what a code signing program needs to do.

Long-term validation for enterprise code signing, defined: preserving the certificate chain, revocation status, and a trusted timestamp for a signed artifact at the moment of signing, the same principle PAdES LTV applies to PDFs, so firmware, installers, and enterprise software with multi-year service lives stay verifiable long after their signing certificate’s validity period ends.

Key Takeaways

• PAdES and code signing are different standards for different artifact types, but they share the identical failure mode: a signature that depends on external revocation and timestamp services becomes unverifiable once those services, or the certificate itself, are gone.
• Code signing’s equivalent of PAdES’s B-LT level is an RFC 3161 trusted timestamp applied at signing time; without one, a signed artifact’s trust expires with its certificate, typically within 460 days under current CA/Browser Forum rules.
• A QSCD (Qualified Signature Creation Device) in the PAdES/eIDAS world is functionally the same requirement as an HSM in code signing: the private key must be generated in, and never leave, certified hardware.
• For the code-signing-specific timestamping and HSM requirements in depth, see Code Signing Best Practices in the SDLC and We Counted Every Format CodeSign Secure Can Sign.

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.

Mapping PAdES LTV onto Enterprise Code Signing

The concepts translate directly, even though the standards and file formats are different:

PAdES / eIDAS Concept	Code Signing Equivalent
B-T: qualified timestamp at signing	RFC 3161 trusted timestamp applied at signing time
B-LT: certificate chain and revocation data stored in the file	Certificate chain packaged with the signature; revocation checked via CRL/OCSP at verification time
B-LTA: archival timestamp, renewed on schedule	No direct equivalent yet in most code signing tooling, which is a real gap for firmware with 10+ year service lives
QSCD (Qualified Signature Creation Device)	HSM meeting FIPS 140-2 Level 2+ (required for all publicly trusted code signing certificates since June 2023)
Crypto-agility for post-quantum migration	Same requirement: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or LMS/XMSS support without a full pipeline rebuild

The gap worth naming explicitly: PAdES’s B-LTA archival re-timestamping, renewing the seal on a document before its own timestamp ages out, doesn’t have a widely adopted equivalent in code signing tooling today. For firmware and enterprise software with service lives measured in decades, that’s a real risk: an RFC 3161 timestamp keeps a signature valid past certificate expiry, but nothing in most code signing workflows re-seals that timestamp before the timestamp authority’s own certificate chain eventually ages out too. Treat this as an open operational question to plan for, not a solved problem.

Why It Matters Now: eIDAS 2.0 and EU Digital Wallets

Europe’s eIDAS regulation sets the rules for electronic signatures; the updated eIDAS 2.0 has been in force since 2024 and introduces the EU Digital Identity Wallet, which every EU Member State must make available by the end of 2026 under Regulation (EU) 2024/1183. This is a document- and identity-signing development, not a code-signing one, but it’s worth knowing about for one reason: it’s driving a large increase in the volume of long-lived signed artifacts that need to remain verifiable for decades, the same pressure that’s pushing code signing toward similar long-term validation discipline.

The more directly relevant pressure for code signing is the post-quantum transition. Quantum-safe signature algorithms have already been standardized, including ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), finalized by NIST in August 2024, so code intended to stay verifiable well beyond 2030 should be built for crypto-agility now.

For software and firmware signing specifically, 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 ML-DSA 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.

Frequently Asked Questions

Is PAdES used for code signing?

No. PAdES (ETSI EN 319 142) is a standard for signing PDF documents, not executables, installers, or firmware. It’s relevant to code signing only as a model, since both face the identical problem of keeping a signature verifiable after its certificate expires.

What’s the code signing equivalent of PAdES’s B-LT level?

An RFC 3161 trusted timestamp applied at signing time, combined with the certificate chain packaged with the signature. Without the timestamp, a signed artifact’s trust expires along with its certificate.

Does code signing have an equivalent to PAdES’s archival re-timestamping (B-LTA)?

Not in wide adoption today. This is a real gap for firmware and enterprise software with decades-long service lives, since nothing in most code signing workflows re-seals a timestamp before its own certificate chain eventually ages out. Plan for it rather than assuming it’s solved.

Is a QSCD the same thing as an HSM?

Functionally, yes, for this purpose. A QSCD is the eIDAS-specific certification for the device holding a qualified signing key; an HSM meeting FIPS 140-2 Level 2+ serves the same role in code signing, and has been required for all publicly trusted code signing certificates since June 2023.