A signature is a promise. A certificate is a lease. The timestamp is the witness who was in the room when the promise was made.
2034 · DISCOVERY
A contract signed in 2027 has surfaced in litigation, and the other side’s expert has run it through a validator. The cryptography is spotless: the hash matches, the signature verifies.
But the signing certificate expired in 2028, and a validator that anchors on the present moment asks a question about now: is this certificate valid today?
No. Of course not. It was never meant to be.
The question that actually matters is about then: was this certificate valid at the instant of signing? On that question, the signature itself is silent. Something else has to speak.
A digital signature can reveal who signed a document and whether its contents have changed. But when a document resurfaces years later and the original certificate has lapsed, a harder question arrives:
Can the organization prove that the signature existed while the signing certificate was still valid?
Certificates expire, and some are revoked even earlier. The signature itself may remain cryptographically intact, untouched since the instant it was made. Yet without trusted evidence of when that instant occurred, a future verifier may be unable to establish whether the certificate was good at the time of signing.
A trusted timestamp preserves that missing moment. By binding the signature to independently verifiable time, it provides evidence that the signature existed before a specific point. As RFC 3161 itself notes, this kind of evidence can help show that a signature was applied before the corresponding certificate was revoked. Combined with the certificate’s validity window, it supports the conclusion that the signature was created while the certificate could be relied upon.
For organizations whose signed records must outlive their certificates, timestamping is more than a technical enhancement. It preserves the evidence behind the signature, carrying trust forward through time.
Important distinction
A trusted timestamp does not renew a certificate, prevent its expiration, repair an invalid signature, or guarantee that every signature will remain valid forever. Depending on the signature format, retention period and validation policy, certificates, revocation status and additional archival timestamps may also need to be preserved.
Digital signatures answer who and what. Not when.
A certificate-based digital signature normally provides two core assurances:
- Signer authentication. It connects the signature to a private key associated with the signer’s certificate.
- Document integrity. It lets a verifier detect whether the signed content changed after signing.
Powerful, but silent on time. A signing application may record the time shown on the signer’s device, and a CMS signature can even carry a signingTime attribute. Yet that attribute sits inside signed attributes because the signer put it there. It is the signer’s own claim, controlled by the device or its operator, and it is not equivalent to time attested by an independent Time Stamping Authority (TSA).
Adobe Acrobat draws the same line, distinguishing a signature time taken from the signer’s computer from a signature backed by a timestamp server. Whether a timestamped signature then meets long-term validation requirements is a separate assessment that also depends on the availability of certificate and revocation information.
An electronic signature with timestamp should therefore be judged on more than whether a date appears beside the signature. The real question: does the workflow produce cryptographically verifiable time evidence from a trusted source?
What is a trusted timestamp?
A signed assertion from a third party that has no stake in your outcome.
A trusted timestamp is a cryptographically signed assertion issued by a TSA, giving evidence that specified electronic data existed before or at a particular time. In a standard RFC 3161 exchange, it unfolds in five beats:
- The signing system computes a hash, the message imprint, of the data to be timestamped. For a digital signature with timestamp in CAdES or PAdES, that data is the signature value itself; for a PDF document timestamp, it is the byte range of the whole file. What gets hashed defines what the token can vouch for.
- The imprint goes to the TSA in a timestamp request. The request carries the imprint, never the document content.
- The TSA binds the imprint to a trusted time value read from a UTC-traceable clock.
- The TSA signs the result and returns a Time-Stamp Token.
- The token is embedded in, or retained with, the signature or digital object.
Step five hides a lovely detail. The token covers the signature, so it cannot live inside what the signature signs. In CAdES and PAdES it is therefore attached as an unsigned attribute, riding alongside the signature it protects.
You will sometimes hear the phrase timestamp signature for a digital signature with timestamp. In RFC 3161 vocabulary, the standardized artifact the TSA returns is a signed Time-Stamp Token.
Why certificate expiration creates a long-term verification challenge
Certificates are leases on identity. Leases end. Records outlive them.
Digital certificates are intentionally time-limited. Expiration forces periodic renewal of identities, keys and security controls, which is healthy. The friction is that many signed documents must be retained far longer than any certificate lives.
A future verifier may need to establish much more than whether a hash still matches. Depending on the signature format and validation policy, the assessment can include:
- whether the signature cryptographically matches the signed data;
- whether the signing certificate was within its validity period at the relevant time;
- whether the certificate chained to an accepted trust anchor;
- whether the certificate had been revoked at the relevant time;
- whether the certificate’s policy and key usage supported the intended signature; and
- whether the timestamp and supporting validation evidence remain trustworthy.
Here is what the timestamp changes, in PKI terms. Path validation takes a validation time as an input. Without a trusted token, that input defaults to the present. With one, the verifier can use the token’s genTime instead, evaluating the certificate chain, revocation information and policy as of the moment the token vouches for. The certificate’s later expiration does not, by itself, show that the signature was made with an expired certificate.
That is the standalone business value of timestamping: it preserves evidence of when the signature existed, instead of trying to stretch the life of the signing certificate.
A trusted timestamp is not just a date printed on a document
A visible date beside a signature may have been typed by hand, generated by an application, or read from a device clock. Even when the displayed date is correct, it may not be independently attested or cryptographically bound to the signed data.
The timestamp is the keystone. The arch needs more stones.
A trusted timestamp provides the crucial proof of time. Complete long-term validation (LTV) may also require preserving the signing and timestamp certificate chains, certificate-status information such as OCSP responses or Certificate Revocation Lists, and whatever else the applicable signature profile demands.
PAdES, the ETSI framework for PDF Advanced Electronic Signatures, shows the ladder clearly:
- PAdES B-B provides the basic signature requirements.
- PAdES B-T adds trusted proof that the signature existed at a particular time: the signature timestamp.
- PAdES B-LT adds the material needed for long-term validation (certificates and revocation information), stored in the PDF’s Document Security Store (DSS).
- PAdES B-LTA adds a document timestamp over the whole file, DSS included, protecting the long-term availability and integrity of the validation material.
Two details separate the practitioners from the dilettantes. First, revocation evidence is usually gathered after the timestamp, and validation policies commonly allow a grace period, because a revocation takes time to propagate and a status fetched at the instant of signing can be stale. Second, the chain is recursive. The TSA’s own certificate expires, and algorithms weaken. B-LTA answers by letting you apply a fresh document timestamp over everything before it, renewing the protection before the old one ages out. Outside PDF, RFC 4998 Evidence Record Syntax solves the same renewal problem for archives.
No single timestamp should be described as an unconditional guarantee of permanent validity. Records kept for very long periods may need additional archival timestamps as cryptographic algorithms and validation evidence age.
Timestamp early
A timestamp is a ceiling: it proves the signature existed by a given time, not that it existed before any earlier event. If a key is later declared compromised with an invalidity date that precedes your token’s genTime, a late timestamp cannot rescue the signature. In practice, request the timestamp as part of the signing transaction itself, never as a clean-up job.
From compliance checkbox to evidentiary control
Timestamping is sometimes treated as the last configuration option in a digital signing project. That perspective understates its value.
For contracts, approvals, regulated reports, employee records, financial documents and long-lived archives, an organization may need to show not only that a document is authentic, but that it existed before a deadline, before a certificate expired, or before a certificate was revoked. RFC 3161 identifies timestamping as relevant to proving that a signature was applied before certificate revocation, and to recording submission or transaction time where timing is important.
A trusted timestamp can therefore support:
- Long-term verification: time evidence that can be evaluated alongside the certificate and retained validation information.
- Auditability: cryptographically protected time evidence for auditors, instead of displayed dates or application logs alone.
- Dispute readiness: stronger evidence of when specified signed data existed.
- Deadline assurance: support for showing that a submission, approval or transaction existed by a required time.
- Integrity verification: binding trusted time to a message imprint, so changes to the protected data are detected during validation.
- AI content traceability: evidence that AI-generated content, or the marking metadata attached to it, existed no later than a given moment. This complements, and does not replace, the marking and disclosure duties of EU AI Act Article 50.
The business point is plain: a digital signature protects identity and integrity, while trusted timestamping preserves an independent time reference that may be needed to defend the transaction later.
The legal value of electronic timestamps
The legal effect of an electronic signature or timestamp depends on the jurisdiction, the transaction, the evidence and the applicable law. Timestamping should never be described as automatically making every document legally binding in every country.
Under the EU eIDAS Regulation, an electronic timestamp cannot be denied legal effect or admissibility as evidence solely because it is electronic or does not meet the requirements for a qualified electronic timestamp. A qualified electronic timestamp additionally benefits from a presumption of accuracy for the date and time it indicates and for the integrity of the data to which they are bound (Article 41). Article 42 separately sets the requirements a qualified timestamp must meet.
That is why organizations distinguish between a conventional trusted timestamp and a qualified one. Both can provide cryptographic evidence, but their regulatory status and associated presumptions differ, and legal teams should determine the required signature and timestamp type for each jurisdiction and use case.
A note on EU AI Act Article 50
The same evidentiary logic now has a second audience. Article 50 of the EU AI Act began to apply on 2 August 2026. Its clear, machine-readable and detectable marking duty falls on providers of generative AI systems (Article 50(2)), while deployers must disclose deepfakes and AI-generated public-interest text (Article 50(4)). Under the Digital Omnibus on AI, generative systems already on the market before 2 August 2026 have until 2 December 2026 to implement the marking requirement; newer systems must comply from the outset.
Article 50 does not specify timestamping as the marking mechanism, and a timestamp does not mark content. What a qualified timestamp can offer is a documented way to evidence that content, or its marking metadata, existed no later than a given moment, backed by the Article 41 presumption of accuracy. For teams already using trusted timestamps to preserve signature evidence, extending the same approach to AI-generated content and its metadata can strengthen an Article 50 compliance record without re-architecting the pipeline.
What organizations should look for in a timestamping solution
- Support for recognized standards. RFC 3161 provides an interoperable model for requesting and issuing timestamp tokens.
- A trusted TSA. The TSA should be trusted for the intended document ecosystem, regulatory environment and use case.
- Reliable time sources. The evidentiary value of the timestamp depends on the integrity and accuracy of the time asserted.
- Long-term-validation support. The workflow should preserve the certificates, revocation evidence, timestamps and other material required by the applicable signature format and retention policy.
- Compatibility with existing workflows. Timestamping should plug into document-signing applications and services without forcing unnecessary replacement of the wider signing environment.
- A standalone deployment option. Organizations with a signing platform may need to add trusted timestamping without replacing the whole solution. A buyer may not need a new signature application. The immediate gap may be that existing signatures lack independent, trusted proof of when they were created.
Bringing trusted timestamping into digital signing workflows
GlobalSign Trusted Timestamping provides standards-based time evidence designed to support the long-term verification of digital signatures, documents, code and other digital data. GlobalSign publicly positions its timestamping service as RFC 3161-based and offers timestamping for AATL document signatures, qualified timestamping use cases and code signing.
Organizations modernizing a broader document-signing workflow can use GlobalSign Digital Signing Service, a cloud-based solution designed to integrate certificate-based digital signing into existing workflows. Organizations that already have a signing solution can instead add standalone trusted timestamping to close the proof-of-time gap. The two paths are complementary.
In both cases, the value is larger than ticking a box. The organization is preserving an essential part of the signature’s evidence lifecycle.
The signature may endure; its proof requires planning
A digitally signed document may need to survive long after the signing certificate, the original application and the organization’s technology stack have all been replaced. That longevity should never be assumed.
A digital signature establishes identity and integrity. A trusted timestamp establishes independently verifiable time. Long-term-validation controls preserve the additional certificates and status evidence needed to evaluate the signature in the future. Together, they can turn a signature that validates today into evidence designed to remain verifiable tomorrow.
2034 · THE VALIDATOR RUNS AGAIN
The same contract, the same validator, the same expired certificate. But this time a token travels with the signature, issued in 2027 by an authority with no stake in the outcome.
The validator no longer asks about now. It asks about then, and then answers: the hash matched, the clock read 2027, the certificate was good, and the chain held.
Trusted time doesn’t make the signature immortal. It makes the signature testifiable.
If signed records must outlive the certificates that created them, a digital signature timestamp is not a finishing touch. It is the trusted time evidence that connects the signature to the period when the certificate could be assessed as valid, which makes trusted timestamping a standalone business requirement, not a checkbox inside the signing process.
Editor’s note: This tech blog provides general technical information and is not legal advice. Organizations should evaluate applicable laws, regulations, evidence requirements and retention policies for each jurisdiction and use case.
Talk to GlobalSign about integrating trusted timestamping into your signing, compliance or digital evidence workflows.
