What Is a Timestamp Server (TSA)? A Complete Guide

What Is a Timestamp Server (TSA)?

A Complete Guide

The notary that never reads your document: how RFC 3161 turns a hash into proof of when.

03:12:07 UTC

A build server in a windowless room finishes compiling a firmware release, signs it, and moves on to the next job. Nobody is watching. Nobody will think about this file again for six years.

Then a regulator’s letter arrives. The signing certificate expired long ago. A key was revoked somewhere in between. The question on the table is only three words long: when was this signed?

The server’s own log says March. Of course it does. It is the only witness in the room, and it is testifying about itself.

This is the problem a timestamp server exists to solve.

In brief

At a precise moment, a trusted timestamp cryptographically seals a hash of your data to an independently attested time, creating verifiable proof that the data existed no later than that moment. Change a single bit afterward and verification exposes it.

What is a timestamp server?

Picture a notary who never reads the contract. You slide a sealed fingerprint across the desk. The notary glances at a clock that answers to UTC, not to you, and writes both onto a signed receipt. Then you leave, and the notary forgets you were ever there. Years later, that receipt still testifies, to anyone, without anyone calling the notary: this exact fingerprint existed by this exact moment.

That notary is a timestamp server. Instead of trusting the clock of the machine that created or signed a file, it draws on an independent time source and issues a digitally signed timestamp token: evidence that can be verified long after the event, offline, by anyone holding the right trust anchors.

In standards-based timestamping, the party behind the server is a Time Stamping Authority (TSA). RFC 3161 defines how requests reach a TSA, what the response looks like, and the security requirements the authority must meet.

Trusted timestamping underpins digital signatures, software releases, business records, intellectual property, audit evidence and electronic transactions: anything whose integrity may one day have to survive cross-examination.

Timestamp server, TSA, TSU, timestamping service: who is who?

Why is an ordinary computer timestamp not enough?

Every file system keeps a diary. Every database row has a “created_at.” Every signing app can print a date beside a signature. And every one of those diaries is written by the party whose honesty may later be in question. A single “touch -d” rewrites a file’s modification time; a system clock answers to whoever holds the right privileges.

An ordinary timestamp can tell you what a system recorded. It cannot prove that the recorded time deserves belief. A trusted timestamp changes the witness: an independent service, a signed token, and a cryptographic binding to a hash of the data.

How does an RFC 3161 timestamp server work?

A transaction measured in milliseconds, with consequences measured in years.

RFC 3161 defines the Time-Stamp Protocol as a simple request–response exchange. Here is the whole choreography, from the first hash to the verification that may happen long after everyone involved has moved on.

Figure 1. The RFC 3161 exchange, from local hash to verification years later. Only the digest crosses the wire.

1 · The client hashes the data

A cryptographic hash is the data’s fingerprint: change one bit and, with any sound algorithm, the digest changes beyond recognition. The client hashes the document, software object, transaction, signature value or record. What gets hashed depends on the workflow (for a signature timestamp, it is the signature itself), and that choice defines exactly what the finished token can vouch for.

2 · The client sends the imprint, not the document

The client builds a TimeStampReq: a version, the messageImprint (a hash algorithm identifier plus the digest), and optional fields such as a requested policy OID, a random nonce that binds the response to this request, and a certReq flag asking the TSA to embed its signing certificate in the token. Over HTTP it travels as a POST with the content type application/timestamp-query; RFC 3161 describes other transports as well.

The original data never leaves your environment. The TSA timestamps the imprint, not the content, which is a confidentiality feature as much as a bandwidth saving.

3 · The TSA mints the token

The TSA decides whether it will honor the request (is the hash algorithm acceptable, and does the digest length match?), reads its clock, assigns a unique serial number and assembles a TSTInfo structure. It then signs that structure as CMS SignedData with a key reserved for this purpose, and wraps the result in a TimeStampResp with a status. The TimeStampToken inside is the part that matters.

Notice the discipline built into the signing certificate. RFC 3161 requires the TSA’s key to be dedicated to timestamping, and its certificate to carry the id-kp-timeStamping extended key usage, marked critical and with no other usages alongside it. A verifier that sees anything else should walk away.

4 · The token comes home

The client receives the response, and a careful client does not trust it blindly. It checks the status, confirms that the nonce (number used once) and imprint match what it sent, and verifies the token before building anything on top of it. The token then travels with the artifact it protects: embedded as an unsigned attribute inside a CMS or CAdES signature, appended as a document timestamp inside a PDF, or kept beside the file as a standalone response.

5 · A verifier checks it, later

Years on, a verifier works through the token in a fixed order:

• Re-hash the data with the algorithm named in the token and compare the digest with the messageImprint, byte for byte.
• Verify the CMS signature over the TSTInfo using the TSA certificate.
• Validate the TSA chain to a trust anchor, and assess its validity and revocation status as of the relevant time.
• Check the policy OID and accuracy against what your validation policy accepts.
• Confirm the nonce, if the request was made live.

If the recomputed hash does not match, the outcome is subtle and worth stating precisely: the token itself is genuine, but it is a statement about different data. It does not validate against this version of the file.

Try it from a terminal

Everything above fits in four OpenSSL commands. The TSA URL below is a placeholder; substitute your provider’s endpoint.

What does an RFC 3161 timestamp prove?

Precision matters here, because overclaiming is how timestamps lose arguments.

An RFC 3161 timestamp supports evidence that the data represented by a particular hash existed before or at the time recorded in the token. It also lets a verifier test whether data presented later produces the same hash as the data originally timestamped.

Read the claim the way a lawyer would: before. The genTime in a token is a ceiling, not a birth certificate: the data may be older, and the token cannot say by how much. A timestamp tells you the latest moment at which something could have come into being, not the moment it did.

A timestamp does not, by itself:

• identify who created the underlying document;
• prove that every statement in the document is true;
• prove that a person understood or agreed to its contents;
• prevent someone from creating a modified copy;
• replace identity authentication; or
• automatically satisfy every legal or regulatory requirement.

Those questions call for other controls: digital signatures, identity verification, audit trails, access controls, preservation services or qualified trust services.

Is a timestamp server the same as a Certificate Authority (CA)?

Two Authorities, two different questions.

No. A CA issues and manages certificates that bind a public key to an identity or other subject information. A Time Stamping Authority issues tokens that bind a hash of data to a trusted time. Both operate inside the same PKI toolbox (certificates, signing keys, policies and trust chains), yet they perform different trust functions.

A certificate helps answer who or what holds this key. A trusted timestamp helps answer when did this data exist.

There is a twist worth savoring: a TSA is also a customer of the CA world. Its signing certificate is issued by a CA, with its own validity period and revocation status. A token’s longevity therefore depends on the PKI beneath it, and that is exactly the thread the long-term-validation story pulls on.

How does timestamping support digital signatures?

A digital signature ties a signer or signing system to particular data and makes later changes detectable. Timestamping adds independent evidence about when the signed data or the signature existed.

The payoff arrives when a signing certificate later expires or is revoked. A timestamp lets a verifier ask the right question, whether the certificate was valid at the time, instead of the wrong one, whether it is valid now. Whether the answer comes back clean depends on the signature format, validation policy, application, certificate-status information, timestamp type, algorithm strength and preservation of the required validation evidence. GlobalSign describes its timestamping services as supporting continued validation of signed documents and code after a signing certificate expires.

What is qualified electronic timestamping under eIDAS?

The same protocol, wearing a legal uniform.

Under the European eIDAS framework, an electronic timestamp cannot be denied legal effect or admissibility as evidence solely because it is electronic. A qualified electronic timestamp goes further. It enjoys a presumption of accuracy for the date and time it indicates and for the integrity of the data bound to it (Article 41), and it must be recognized across Member States.

What earns the qualification? Article 42 sets three requirements, which a qualified trust service provider (QTSP) must be able to demonstrate:

• The timestamp binds the date and time to the data so as to reasonably preclude undetectable changes.
• It is based on an accurate time source linked to Coordinated Universal Time.
• It is signed or sealed with an advanced electronic signature or seal of the QTSP, or by an equivalent method.

In practice, ETSI standards turn those clauses into auditable controls: EN 319 421 for the policy and security requirements of providers issuing timestamps, and EN 319 422 for the timestamping protocol and token profiles. One consequence is worth knowing: if a TSA’s clock drifts outside its declared accuracy, a conforming service stops issuing tokens rather than guessing.

The European Commission’s Trusted List Browser lets you search national trusted lists by provider name and by trust-service type, including timestamping. It is the authoritative way to verify which services are listed as qualified. GlobalSign nv/sa publishes a dedicated practice statement for its eIDAS qualified timestamping service, which states conformance with ETSI EN 319 421.

Common uses for a timestamp server

Four Scenes where proof of time changes the outcome.

Code signing: the signature that outlives its certificate

A timestamp records when signed software existed, so a build signed during its certificate’s validity period can still be assessed later, subject to the platform’s validation policy and revocation status.

Intellectual property records

Hash a design, a manuscript, a research dataset or a source tree, timestamp the hash, and you hold evidence that a particular version existed by a stated time. A timestamp does not establish legal ownership, but it can contribute strong time-related evidence.

Audit logs and transactions

Where the integrity and ordering of records matter, timestamp the records themselves, or periodically timestamp the head of a hash-chained log or the root of a Merkle tree, so that everything beneath it inherits a provable time.

Regulated records

Legal, financial, government, healthcare, manufacturing and archival workflows may require reliable evidence of when records existed or were signed. The exact requirements depend on jurisdiction, regulation and validation policy.

What should organizations look for in a timestamping service?

Evaluate it as trust infrastructure, not as a URL added to a signing tool.

• Standards support. Confirm support for RFC 3161 and the profiles that match your signing formats (CAdES, PAdES, XAdES, code-signing toolchains).
• Documented policies and practices. Read the timestamping policy, practice statement, certificate policies and service documentation.
• Key protection. Ask how TSU signing keys are generated, stored and used, and whether the controls meet the assurance level your use case demands.
• Reliable time. Look for UTC-traceable sources, documented synchronization controls, and defined behavior when the clock drifts.
• Availability and capacity. Timestamping often sits in the hot path of automated signing, build pipelines and high-volume workflows. Latency, throughput, monitoring and support are operational requirements, not nice-to-haves.
• Verification and long-term support. Plan how tokens, TSA certificates, certificate-status information and policies will be retained and verified over the lifetime of your records.
• Integration options. Check fit with signing applications, document systems, build processes, APIs and enterprise workflows.

EU AI Act Article 50: where trusted time fits

Article 50 of the EU AI Act began to apply on 2 August 2026. The transparency duties it creates are split across two roles, and it pays to keep them apart:

• Providers of generative AI systems must ensure that synthetic audio, image, video and text outputs are marked in a machine-readable format and detectable as artificially generated or manipulated (Article 50(2)). Providers of systems that interact directly with people must also make that interaction transparent (Article 50(1)).
• Deployers must disclose deepfakes and AI-generated or manipulated text published to inform the public on matters of public interest (Article 50(4)), and must inform people exposed to emotion-recognition or biometric-categorisation systems (Article 50(3)).

The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026) left Article 50 in place but gave a narrow transition for the machine-readable marking duty: generative systems already on the EU market before 2 August 2026 have until 2 December 2026 to implement Article 50(2) marking, while systems placed on the market from 2 August 2026 must comply from the outset.

The Commission’s final Code of Practice on marking and labelling AI-generated content, published on 10 June 2026, is voluntary. It does not prescribe one technique; it steers providers toward layered marking in which secured metadata is one of the layers.

Where does a timestamp come in?

Article 50 does not name timestamping, and a timestamp does not mark content. What it can do is answer the question every audit eventually asks: when? Seal the content hash together with its marking metadata under an independent time, and you hold tamper-evident proof that this output, carrying this marking, existed no later than that moment.

PKI enthusiasts will recognize the pattern in the wild. C2PA Content Credentials, a common vehicle for secured provenance metadata on media, are COSE-signed manifests that can carry an RFC 3161 token in the signature’s unprotected header. That token is what lets a manifest signature remain verifiable after the signing certificate’s own lifetime has ended. Check that the TSA you choose is accepted by the validators and trust lists your ecosystem relies on.

Build trusted time into your digital workflows

As more documents, software, transactions and audit records are born digital, establishing when data existed becomes as important as protecting who signed it and whether it changed.

GlobalSign provides RFC 3161-aligned timestamping services for document, code-signing and qualified timestamping use cases, supported by published timestamping practice documentation.

Talk to GlobalSign about integrating trusted timestamping into your signing, compliance or digital evidence workflows.

Editor’s Note: This article 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.