Qualified vs Self-Hosted Timestamping: When You Need a QTSA and When Your Own TSA Is the Right Tool

The same token, issued by different authorities

A timestamp request is simple. The client computes a hash of the data, for example with SHA-256, and sends only that hash to a Time Stamping Authority (TSA). The TSA returns a signed structure, defined in RFC 3161 and updated by RFC 5816, that contains among other fields:

• the message imprint: the hash and the algorithm used;
• the generation time (genTime), in UTC;
• the policy under which the token was issued, as an object identifier;
• a unique serial number and, optionally, the accuracy of the time;
• the signature of the TSA, made with a key whose certificate is marked for timestamping only.

Anyone holding the original data, the token and the TSA certificate chain can verify that the data has not changed since the time in the token. This works in exactly the same way whether the TSA is a public qualified service or a server in your own data centre. Adobe Acrobat, the European Commission's DSS library, OpenSSL, Java, .NET and Microsoft Authenticode all consume the same token format.

What differs is not the cryptography but the trust: who operates the TSA, under which rules, with which oversight, and therefore who will accept its tokens without further questions.

What makes a timestamp qualified

In the European Union, the eIDAS Regulation (EU) No 910/2014 defines the qualified electronic timestamp. To be qualified, a timestamp must meet the requirements of Article 42: it binds date and time to the data in a way that reasonably precludes undetectable change, it is based on an accurate time source linked to Coordinated Universal Time, and it is signed with an advanced electronic signature or seal of a Qualified Trust Service Provider (QTSP).

A QTSP is audited by an accredited conformity assessment body, usually against ETSI EN 319 401, EN 319 421 and EN 319 422, supervised by a national supervisory body, and published as qualified in its Member State's Trusted List. Validators across the EU, including Adobe Acrobat, read these lists and trust qualified services without any configuration on the user's side.

The legal consequences are set out in Article 41:

• Article 41(1): an electronic timestamp shall not be denied legal effect and admissibility as evidence solely because it is electronic or because it is not qualified.
• Article 41(2): a qualified electronic timestamp enjoys a presumption of the accuracy of the date and time it indicates and of the integrity of the data to which they are bound.
• Article 41(3): a qualified timestamp issued in one Member State is recognised as qualified in all Member States.

In practice, this is the decisive difference. A timestamp from your own TSA can be used as evidence, but if it is challenged, you have to demonstrate that your TSA was properly configured, synchronised and protected. A qualified timestamp is presumed correct, and the burden of proof shifts to whoever disputes it.

What a self-hosted TSA gives you, and what it asks of you

Running your own RFC 3161 authority gives you properties no external service can offer:

• Unmetered volume. Timestamping every log segment, every build or every record costs the same as timestamping a few documents a day. See designing a high-frequency pipeline.
• LAN latency. Timestamping stays off the internet path, which matters when it sits in the critical path of a signing or build process.
• Operation in closed networks. Air-gapped and restricted networks can use timestamps at all.
• Full control. Your key, held in an HSM if required, your certificate chain, your policy identifier and your change control.
• Data stays inside. Not even the hashes leave your infrastructure.

In exchange, the responsibilities a QTSP carries for its customers become yours:

• The TSA certificate. RFC 3161 requires the certificate to contain the id-kp-timeStamping extended key usage, marked critical, and no other purpose. It is normally issued from your internal PKI, for example Microsoft ADCS.
• Key protection. The signing key is the root of every token's credibility. An HSM accessed through PKCS#11, or at minimum a properly protected key store, is strongly recommended.
• The time source. A TSA is only as accurate as its clock. Synchronise it with a reliable reference, such as an NTP or PTP hierarchy traceable to UTC or a GNSS-disciplined time server in closed networks, and monitor its drift.
• Trust distribution. Validators trust your tokens only if they trust your CA. Inside a Windows domain this is typically done through Group Policy; Adobe Acrobat can be configured to trust the Windows certificate store or to import your root certificate.
• Records and procedures. If a token is ever disputed, logs of issuance, key management and time synchronisation are what allow you to defend it.

Side-by-side comparison

Deciding scenario by scenario

Three questions settle most cases: who has to accept the timestamp, how often you timestamp, and whether the system can reach the internet.

A short checklist

1. Can the system reach the internet? If not, use a self-hosted TSA.
2. Will anyone outside your organization need to rely on the timestamp? If not, a self-hosted TSA is sufficient.
3. Could the timestamp be challenged in court, in a tax audit or in a supervisory review? If so, you need qualified timestamps, directly or as an anchor.
4. Do you timestamp more than a few thousand times a day? If so, consider the hybrid pattern instead of qualifying every token.
5. Do you have the PKI, key protection and time synchronisation in place to run a TSA properly? If not, plan for them before deploying, or use a qualified service for the cases that matter most.

The hybrid pattern

Many real workloads need both unlimited volume and independent evidence. Security logs are the typical example: they are produced continuously, and they matter most precisely when someone questions them, including the possibility that an administrator altered them.

The hybrid pattern solves this with two layers:

1. Internal layer. Every log segment, record or file version is hashed, chained to the previous one, and timestamped by your own TSA, as often as needed.
2. Qualified anchor. At regular intervals, for example every hour or once a day, the latest hash of the chain is timestamped by a qualified TSA.

Because each element of the chain depends on all previous ones, a single qualified timestamp over the latest hash protects everything before it. Changing any earlier record breaks the chain and no longer matches the qualified anchor. Daily anchoring requires 365 qualified timestamps a year per chain, while the internal TSA handles hundreds of thousands or millions of tokens at no additional cost.

Both layers use the same RFC 3161 protocol, so the only difference in the client is the TSA URL used for each layer.

Common misconceptions

"Timestamps from our own TSA have no legal value."

Not true in the EU. Article 41(1) of eIDAS states that a timestamp may not be denied legal effect or admissibility as evidence just because it is not qualified. What it lacks is the presumption of Article 41(2): its reliability has to be demonstrated if challenged.

"Compliance always requires qualified timestamps."

Most frameworks, including NIS2 and DORA, require outcomes such as protecting logs against unauthorised modification, not a specific technology. Qualified timestamps are required in specific contexts, for example where a law or a qualified trust service explicitly calls for them, and are the strongest choice wherever evidence must convince a third party.

"A self-signed TSA certificate is good enough."

It produces valid tokens, but validators will not trust them unless the self-signed certificate is explicitly configured as trusted everywhere tokens are verified. Issuing the TSA certificate from your internal CA, whose root is already distributed, is far easier to operate.

"The server clock is accurate enough."

An unsynchronised server clock can drift by seconds per day. Since the time in the token is only as good as the clock that produced it, synchronisation with a reliable, monitored reference is part of running a TSA, not an optional extra.

Frequently asked questions