Short answer. A long-term electronic signature (LTV, long-term validation) is an ordinary QES with two kinds of evidence added: a TSP timestamp (proving when the signature was applied) and OCSP/CRL certificate status data (proving that the certificate was valid at that very moment). When both pieces of evidence are embedded directly in the signature container, it remains verifiable even 10 years later — even offline, and even if the trust service provider no longer exists. In CAdES this is the CAdES-XL level; in PDF it is PAdES-B-LTA. In DSTUcrypt the option format:'CAdES-XL' is all you need — the widget enables certificate status checking (checkStatus) automatically.
The problem: the signature was valid — but you can't prove it
Imagine a contract signed with a QES in 2026. In 2031 a dispute arises, and a court or auditor needs to confirm the signature is genuine. The verifier takes the signer's certificate — and it expired long ago: QES certificates live for one to two years. Next you need to establish whether the certificate had been revoked at the moment of signing — but the provider's OCSP service no longer responds, nobody kept the old CRLs, and the provider itself may have ceased operations or lost its accreditation over those years.
Formally, nothing about the signature has "gone bad" — the math is the same. But the evidence base has crumbled: there is no independent confirmation of the moment of signing and no way to verify that the certificate was valid back then. For documents that outlive their certificate — contracts, archives, tender documentation — this is a real legal risk, and protection against it has to be built in at the moment of signing, not years later.
The two ingredients of longevity: time and status
For a signature to outlive its certificate, two independent pieces of evidence are added to it at creation time:
- A TSP timestamp — an attestation signed by a qualified provider: "this signature existed no later than moment T". It proves the signature was applied within the certificate's validity period and protects against manipulation of the clock on the signer's computer.
- Certificate status data — an OCSP response or a CRL obtained at signing time. They prove that at moment T the certificate had not been revoked. Without them even a timestamp does not help: the certificate's validity "back then" remains unproven.
The timestamp answers the question "when?"; OCSP/CRL answers "was the certificate good at that time?". A long-term signature is one where both answers are sealed inside the container itself rather than depending on external services that will eventually disappear.
The CAdES level ladder: BES → T → C → XL
The CAdES standard describes signature levels as a ladder — each rung adds another layer of evidence:
| Level | What it adds | What it gives you for longevity |
|---|---|---|
| CAdES-BES | basic signature with the certificate | verifiable while the certificate is valid and the provider's services are alive |
| CAdES-T | + a TSP timestamp over the signature | a proven moment of signing; certificate status still has to be checked online |
| CAdES-C | + references to the certificate chain and OCSP/CRL | records exactly which data is needed for verification — but the data itself is still external |
| CAdES-XL | + the certificates and OCSP/CRL responses themselves in the container | the full evidence set inside: verification works offline and years later |
The logic is simple: -T proves the time, -C lists the evidence, -XL (also known as -LT in the newer nomenclature) physically embeds it in the file. That is why for the -C and -XL levels, certificate status checking is not an option but a mandatory part of the format: without revocation data these levels are incomplete.
Counterparts in PAdES and XAdES
The same ladder exists in every signature family, just under different names: PAdES (signatures in PDF) and XAdES (signatures in XML) use the newer ETSI baseline nomenclature:
| Evidence level | CAdES (.p7s) | PAdES (.pdf) | XAdES (.xml) |
|---|---|---|---|
| basic | CAdES-BES | PAdES-B-B | XAdES-BES |
| + timestamp | CAdES-T | PAdES-B-T | XAdES-B-T |
| + data for long-term validation | CAdES-C / CAdES-XL | PAdES-B-LT | XAdES-B-LT |
| + archival timestamp | — | PAdES-B-LTA | XAdES-B-LTA |
The -LTA levels add an archival timestamp on top of the long-term data — a "seal over the seals" that preserves all the embedded evidence and lets you extend the signature's life as older algorithms weaken. For PDF documents with a long retention period the target format is PAdES-B-LTA; for XML it is XAdES-B-LTA. Mind the nomenclature: the "with timestamp" level is CAdES-T, but PAdES-B-T and XAdES-B-T.
Offline verification: everything needed is inside the container
The key practical consequence of the XL/LT/LTA levels: verification no longer depends on the outside world. The container holds the document itself (for attached signatures), the signer's certificate and the full chain up to the root, the timestamps, and the OCSP/CRL responses captured at signing time. Ten years later, a verifier simply unpacks this evidence and checks it cryptographically — without a single request to the provider.
This removes three risks at once: certificate expiry (the timestamp proves the signature is older), disappearance of OCSP/CRL services (the responses are already inside), and disappearance of the provider itself (the certificate chain is preserved). You only need to be online once — at the moment of creating the signature, to obtain a fresh timestamp and OCSP response.
How to create a long-term signature in DSTUcrypt
In DSTUcrypt — a service of embeddable QES widgets — the long-term level is enabled with a single value of the format option. All cryptography runs in the user's browser (WebAssembly), and the key and password never leave our iframe:
A long-term CAdES-XL signature — a single option
import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';
const signer = await embed('sign', { mount: 'modal' });
const { signature } = await signer.sign(fileBytes, {
format: 'CAdES-XL', // chain certificates + OCSP/CRL are embedded in the container
// checkStatus is enabled automatically: without revocation data, -C/-XL levels are incomplete
includeContentTS: true, // extra: a timestamp over the data itself (contentTS)
});
signature.download('contract.p7s'); // a file with the full evidence set inside
For PDF it works the same way — format:'PAdES-B-LTA'; for XML — format:'XAdES-B-LTA'. The hash function is under your control too: the default is GOST 34.311-95 (accepted by government validators), and the modern Kupyna (DSTU 7564:2014) can be enabled with the digest:'kupyna-256' option — the choice of hash does not depend on the signature level.
Why it is easy here specifically. OCSP responses and timestamps are embedded directly in the container — the signature can then be verified offline, without any external service. For the -C/-XL levels the checkStatus option is enabled automatically — forgetting the revocation data is impossible. And all requests to the TSP and OCSP go through DSTUcrypt's built-in CORS proxy with automatic fallbacks — the client configures neither server addresses nor proxies.
Who needs this most
The long-term level is needed wherever a document will outlive its certificate:
- Lawyers and contract work — contracts, powers of attorney, settlement agreements: a dispute may arise five to seven years later, and that is exactly when you will have to prove the signature was valid.
- Archives and HR document workflows — orders, employment documents, records kept permanently: retention periods are measured in decades.
- Tenders and procurement — bids and protocols must remain verifiable throughout the entire cycle of appeals and audits.
- Medical records — reports and case histories are kept for years, and their authenticity must be provable at any moment.
A practical rule of thumb: if a document matters more than routine correspondence and will live longer than a year — sign it at the CAdES-XL / PAdES-B-LTA level right away. The difference in code is one line; the difference in evidentiary strength is fundamental.
Frequently asked questions
How does CAdES-XL differ from CAdES-T?
CAdES-T adds only a TSP timestamp to the signature — it proves the moment of signing, but verifying the certificate's status still requires the provider's live OCSP/CRL services. CAdES-XL additionally embeds the chain certificates and the OCSP/CRL responses themselves in the container, so the signature can be verified even when the provider's services are no longer available.
What happens to a CAdES-BES signature when the certificate expires?
Cryptographically the signature does not break, but proving its validity becomes hard: CAdES-BES has neither a timestamp (it is unknown exactly when it was signed) nor data about the certificate's status at signing time. The verifier sees an expired certificate and has no grounds to consider the signature applied within its validity period. That is why documents with a long life need at least the T level, and preferably XL.
Do you need the internet to verify a CAdES-XL signature?
For basic verification — no: the chain certificates, OCSP/CRL responses, and timestamps are already embedded in the container, so the verifier has everything it needs offline. Online access is only required when creating such a signature — to obtain a timestamp from the TSP and a fresh OCSP response.
Which format should I choose for a PDF document with a long retention period?
PAdES-B-LT embeds long-term validation data (certificates and revocation statuses) in the PDF, while PAdES-B-LTA adds an archival timestamp that "preserves" all this evidence. For contracts, HR documents, and archives, choose PAdES-B-LTA — in DSTUcrypt it is a single option, format:'PAdES-B-LTA'.
Read next
- Electronic signature formats: CAdES, PAdES, XAdES, ASiC — which one to choose
- QES in PDF: how to sign a PDF document with the PAdES standard
- Verifying an electronic signature on your website: cryptography, the chain, OCSP, and timestamps
Long-term signatures on your website — in 10 minutes
Ready-made widgets for signing, verification, and encryption under DSTU — including CAdES-XL and PAdES-B-LTA. The key and password never leave the user's browser. Every new domain gets 7 days free.
Live demoHow to integrate