How Long Do Digital Signatures Remain Valid?

June 30, 2026 ·Gustav Poola ·

digital-signaturesignature-validitylong-term-validationltvpades-ltaxades-aadeseidasevidence-layerauthentication

A digital signature is verifiable while its underlying certificate is valid — typically one to three years. After expiry, the signature is still cryptographically intact, but extra evidence is needed to verify it. Long-term validation (LTV) under PAdES-LTA, XAdES-A and CAdES-LTA, anchored by a Qualified Timestamp from a QTSP, extends verifiability indefinitely. IdentiGate signatures embed trusted signing time but do not include a Qualified Timestamp — that is a separate eIDAS Article 41 service.

How Long Do Digital Signatures Remain Valid?

In our work shipping AdES signatures across cross-border contracting flows, the question of long-term validity lands on the engineering desk every time a customer has to defend a signed document at month forty-eight in an audit. A Rotterdam-based mid-market 4PL we work with — moving roughly 8,500 containers per year across 14 EU corridors — asked us last quarter about a 2023-vintage signed haulage contract that the German importer's compliance team had asked to re-verify in 2026; the original signing certificate had expired in 2024, and the verifier couldn't establish that the signature was valid at the time of signing without additional evidence. That is the question this post unpacks. It is a technical question, but it has a clean operational answer: signatures stay verifiable indefinitely when the right archival evidence is captured, and they become evidentially weak quickly when it isn't. The terminology behind the SES/AdES/QES tiers this post leans on is laid out in our earlier post on the difference between digital and electronic signatures.

What does "valid" actually mean for a digital signature?

Two things that the everyday word valid conflates: cryptographically intact, and verifiable as having been valid at the time of signing.

A digital signature in 2026 typically uses RSA or ECDSA over a hashed document, signed with a private key whose public certificate was issued by a Certificate Authority. The cryptographic chain holds indefinitely — the math doesn't expire. If the document and signature bytes are preserved, the signature remains cryptographically intact for as long as the underlying algorithm holds (RSA-2048 is good until at least the early 2030s; SHA-256 likewise). That is the part the cryptographers think of as "valid".

The eIDAS notion of valid is operational, not just cryptographic. Under ETSI EN 319 102-1 procedures, a signature is valid if, at the moment of validation, the verifier can establish that: the signature matches the document; the signing certificate was valid at the time of signing; the certificate was not revoked at the time of signing; the cryptographic algorithms used were acceptable at the time of signing. The second, third, and fourth checks require evidence of the past — the signing time, the certificate-status data at that time, and the algorithm policy at that time. If that evidence is missing, the verification fails as an operational check, even though the cryptographic chain still holds.

This is the gap. A signature can be cryptographically intact and operationally un-verifiable at the same time. The procurement question "is this signature valid in 2030?" is the second meaning. The honest engineering answer depends entirely on what evidence was archived when the signature was produced.

What happens when the signing certificate expires?

The verifier can no longer establish, by default, that the signature was made while the certificate was valid.

Certificates issued by commercial CAs typically have validity periods between one and three years; qualified certificates issued by QTSPs are similar. When the certificate expires, the CA stops publishing fresh CRL or OCSP status for it, and after a further period (often 7-13 years depending on the CA) stops publishing the status entirely. A verifier running validation in 2030 on a signature made in 2023 with a 2024-expired certificate will not, by default, be able to fetch the certificate's revocation status as of the signing date.

What this means operationally: the signature is still cryptographically intact, but the evidential chain that proves it was valid when signed has degraded. The verifier sees: a hash that matches, a public key that matches, an expired certificate, and no historical revocation evidence. In a procurement or audit context, this falls short of the eIDAS Article 32 validation criteria. The signature is treated as "not verifiable" — not "definitely invalid", but lacking the evidence to be definitively valid.

The fix is to capture the evidence before it degrades. This is what Long-Term Validation formats are designed for, and what every AdES profile defines as its archival variant.

What does long-term validation (LTV) actually do?

Wraps the signature in additional evidence — captured timestamps, fresh revocation data, and policy attestations — so that the signature can be verified against the captured evidence indefinitely, independent of whether the original CA is still operating.

The standard LTV profiles in eIDAS are: PAdES-LTA for PDFs, XAdES-A for XML, CAdES-LTA for CMS-based formats. All three follow the same architectural pattern. At the moment of signing or shortly after, the signature is augmented with: (a) the validation data (full certificate chain plus the revocation status of each certificate at the time of signing — CRL or OCSP responses), and (b) a Qualified Timestamp issued by a QTSP under eIDAS Article 41-42 that vouches for the moment all this evidence was captured.

The Qualified Timestamp is the crucial anchor. It is a cryptographic attestation from an eIDAS-recognised Time Stamping Authority (TSA) — a QTSP listed on the EU Trusted List — that the signature and its validation data existed at a specific moment. When the underlying signing certificate later expires, or even when the CA's revocation status is no longer fetchable from the CA's own infrastructure, the verifier can still rely on the captured validation data plus the Qualified Timestamp's attestation that the validation data was correct at the moment of timestamping.

What we tell customers when they ask about long-term validity is that LTV is not a one-time decision — the timestamp itself eventually approaches the limits of its own cryptographic algorithm. The full LTV profiles (PAdES-LTA, XAdES-A, CAdES-LTA) define an augmentation mechanism: re-timestamping the entire archive every several years with a fresh Qualified Timestamp using current cryptographic suites. Each augmentation re-anchors the validity for another archival period. Under ETSI TS 119 312 cryptographic-suite recommendations, this typically means a fresh timestamp every 5-10 years. Done diligently, signatures remain verifiable for decades.

The bit the validation-only marketing skips is that LTV requires the Qualified Timestamp from a QTSP — it is not something the AdES signature alone provides. It is an additional trust service, with its own cost, its own contract, and its own operational integration. The platforms that ship LTV-capable signing flows do so by integrating with a QTSP timestamp endpoint. The platforms that don't ship LTV produce signatures with a built-in signing time but no qualified-timestamp anchor, which is enough for the cryptographic-intact check and not enough for the operational-verifiable check at month forty-eight.

What can IdentiGate do here, and what is a separate Qualified Timestamp service?

IdentiGate ships AdES signatures with embedded trusted signing time. IdentiGate is not a QTSP and does not issue Qualified Timestamps.

The distinction is operationally important. Our Signatures product produces an AdES record under eIDAS Article 26 that captures the signer's identity (through the Identity Verification product — chip-anchored or document-plus-face-match), the document hash, and the moment the signing was produced. The signing-time attestation we embed is a trusted time in the eIDAS Article 3(33) sense — a verifiable moment captured at signing, signed by us — but it is not a Qualified Timestamp in the eIDAS Article 3(34) sense, which requires issuance by a Qualified Time Stamping Authority on the EU Trusted List under Article 41-42.

For customers who need PAdES-LTA / XAdES-A / CAdES-LTA long-term archival, the integration pattern is: produce the AdES signature using the IdentiGate Signatures product, then wrap the signature with a Qualified Timestamp obtained from any QTSP on the EU Trusted List. The two services sit at different layers of the trust framework — IdentiGate at the signature-production layer with chip-anchored identity, the QTSP at the time-stamping layer that anchors archival validity. We do not compete with the QTSP and we do not ship the QTSP integration as part of our core flow; customers who need long-term archival run the QTSP integration alongside our signing service.

The retention layer — keeping the augmented signature, validation data, and Qualified Timestamp wrapped together in a format that survives a forty-eight-month audit — is what we ship as the Evidence Layer product. That product is about retention quality: storing the augmented LTV record in a form that the verifier in 2030 can actually read and validate. The Evidence Layer accepts wrapped signatures (with or without external Qualified Timestamps) and retains them in audit-defensible form. It does not issue timestamps itself; it stores what the LTV process produced.

What I'd push back on hardest is the conflation customers sometimes hear from vendor marketing — that "our signatures are valid forever because we add a timestamp". That claim only holds if the timestamp is a Qualified Timestamp from a QTSP, the validation data is captured at the right moment, and the archive is refreshed periodically. Our position is honest about the boundary: we ship the trusted-signing-time and chip-anchored identity layer, customers integrate the QTSP timestamp layer separately, and we retain the wrapped record at the Evidence Layer. That stack has been audit-defensible at forty-eight months in the cases we have shipped against; the stack without the QTSP timestamp has not.

Sources

Primary — eIDAS and signature framework

Primary — ETSI signature and timestamp standards

Primary — IETF time-stamp foundation

RFC 3161 — Internet X.509 PKI Time-Stamp Protocol (TSP)

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.