LTV vs LTA: the difference in qualified electronic signatures.

Asignature has to hold up the day it is made. A contract, a will or a company resolution has to hold up far longer: through audits, disputes and retention periods of ten, twenty or thirty years. Long-term validation is the craft of making a signature outlive the certificates, servers and algorithms it was built on.

LTV keeps a signature checkable after the certificates behind it have expired. B-LTA keeps it checkable decades later, even after the cryptography behind it has aged.

Both are technical profiles, not legal levels. A qualified electronic signature stays qualified whichever profile it is stored in. What changes is how long, and how easily, anyone can still prove it.

Much of the confusion comes from mixing two different questions: what is this signature worth in law? and what is packed into the file so it can be checked?

The legal level: QES. The EU’s eIDAS Regulation knows three levels of electronic signature: simple, advanced (AES) and qualified (QES). A qualified signature is an advanced signature made with a certified signature device and based on a qualified certificate, issued by a supervised trust service provider after an identity check. Under Article 25(2) eIDAS it has the same legal effect as a handwritten signature in every member state. eIDAS says nothing about how long the signature must remain checkable.

The technical profile: PAdES baseline levels. How a signature is stored inside a PDF is defined by ETSI, the European standards body, in the PAdES standard (EN 319 142-1). It describes four cumulative levels, each adding evidence to the one below:

So “QES B-LT” and “QES B-LTA” are both fully valid qualified signatures. Even a QES at B-B is legally a QES. The profile decides only how well the signature holds up over time.

“LTV”, long-term validation, is older than today’s levels. ETSI introduced it in 2009, in the first PAdES standard, under the name “PAdES-LTV”. Adobe adopted it for Acrobat and Reader, and that is where most people meet it today. The current standard still uses the phrase for the mechanisms behind long-term validation, but no longer as the name of a level.

In everyday use, “LTV” roughly means B-LT: the validation data is embedded in the file. And here lies the catch.

A signature on its own only says “this key signed this document”. To trust it, a validator needs to know whose key it was, whether that key was still good, and when it was used. At level B-LT, the file answers all three questions itself:

1. 1
   The certificate chain

   The signer’s certificate and every certificate above it, up to the root of the trust service provider. A validator follows this chain to a source it trusts, such as the EU Trusted Lists.

2. 2
   The revocation answers

   Proof that no certificate in the chain had been revoked at signing time: an OCSP response (a signed live answer from the issuer) or a CRL (the issuer’s signed list of revoked certificates).

3. 3
   A trusted timestamp

   An independent confirmation of when the signature existed. Without it, nobody could say whether the signature was made before or after a certificate expired or was revoked.

4. 4
   The Document Security Store

   In a PDF, this material lives in a dedicated area of the file called the DSS. A validator reads it from there instead of asking servers that may no longer exist.

The benefit is independence. The signer’s certificate typically expires after a few years, and the provider’s revocation services do not run forever. With B-LT, anyone can still confirm that the signature was valid when it was made, even once the certificate has expired or the provider has gone offline. eIDAS asks exactly this: under Article 32 a qualified certificate must be valid at the time of signing. A later expiry does not undo the signature, as long as the time of signing can be proven.

B-LT has a limit: its evidence is only as strong as the timestamp that holds it together, and as the algorithms behind it. Two things wear out over time.

The timestamp’s own certificate expires. A timestamp is itself a signature, made by the timestamp authority with a certificate of its own. These certificates typically run from a few years to about a decade. ETSI’s standard for timestamp authorities (EN 319 421) notes that a timestamp usually becomes unverifiable once that certificate has expired, because revocation information for it is no longer published.

Cryptography weakens. Hash functions and key lengths that are secure today will not be secure forever. ETSI and Germany’s Federal Office for Information Security (BSI) publish horizons for each algorithm. For example, RSA keys under 3000 bits are already considered legacy, and the BSI expects a move to quantum-safe signatures by 2035 at the latest.

When either happens, a validator following the European validation standard (EN 319 102-1) does not call the signature invalid. It returns indeterminate: it can no longer establish the facts on its own. The signature has not become worse. Its proof has simply run out of strength.

B-LTA is B-LT plus a document timestamp over the whole file: the document, the signature and all the validation data in the Document Security Store. This timestamp is often called the archive timestamp. It freezes the entire package at a moment when every certificate in it was still valid and every algorithm still secure.

The decisive part is that it can be repeated. Before the archive timestamp itself ages out, its own validation data is added to the file and a new timestamp is laid over everything, with current algorithms. Each layer proves that the layer beneath it existed while it was still secure. The chain grows for as long as someone renews it in time.

That is how a signature can stay provable for decades. The IETF’s standard on evidence records (RFC 4998) puts the need plainly: digitally signed data must in some cases be archived for 30 years or more. Renewed timestamps are the established way to get there.

For most business documents, the honest question is not “is my signature qualified?” but “will I still be able to prove it when it matters?”. Disputes tend to arise years after signing, and retention periods for contracts and company records often run ten years or more. A signature that is legally perfect but no longer provable helps nobody in court.

That is why swipesign applies B-LTA to every signature, with a qualified timestamp from A-Trust, and stores the result as PDF/A, the archival form of PDF. This gives every document the archival level from the first day. Renewing the archive timestamp over the years is a separate step: it is not part of every account, but of the optional long-term archive, or of your own archive system. What each signature carries from day one is described in Why your signature stays valid for decades.

Every statement in this article can be traced to these documents:

• Regulation (EU) No 910/2014 (eIDAS), Articles 25, 32, 34, 41 and 42, as amended by Regulation (EU) 2024/1183.
• ETSI EN 319 142-1: PAdES digital signatures, baseline levels B-B to B-LTA.
• ETSI EN 319 102-1: procedures for creating and validating signatures, including proof of existence and the result “indeterminate”.
• ETSI EN 319 421: policy requirements for timestamp authorities, Annex D on timestamp validity.
• ETSI TS 102 778-4: the original PAdES-LTV profile from 2009.
• ETSI TS 119 312: cryptographic suites and their lifetimes.
• BSI TR-02102-1: cryptographic mechanisms, recommendations and key lengths.
• IETF RFC 4998: Evidence Record Syntax, on archiving signed data for 30 years or more.
• Adobe Acrobat Digital Signature Guide: what Adobe means by long-term validation.
• European Commission DSS documentation: signature levels and archive timestamps in practice.
• Vigil, Buchmann et al.: Integrity, authenticity, non-repudiation, and proof of existence for long-term archiving: a survey, Computers & Security 50 (2015).

Adobe, Acrobat and Reader are trademarks or registered trademarks of Adobe Inc. in the United States and/or other countries. swipesign is not affiliated with or endorsed by Adobe.