What Makes an Electronic Timestamp 'Qualified' Under eIDAS

An electronic timestamp is qualified when the service that issued it appears with that status on an EU Trusted List, and when it meets the requirements of Article 42 of Regulation (EU) 910/2014. Nothing inside the timestamp file itself settles the question. That is the part most vendor pages quietly skip.

Key Takeaways

• Qualified status comes from a public register, not from the file. The policy identifier inside a token is its issuer's own statement.

• You can check it yourself in a few minutes through the EU Trusted List Browser, or read the same data machine-readably from the Commission's List of Trusted Lists.

• Check at service level, not provider level. One provider runs many services, and their statuses do not have to match.

• Article 41(2) is the payoff: a qualified timestamp is presumed to show the correct date and time, and that the bound data is intact. Your opponent has to prove otherwise.

• Your document stays where it is. Under RFC 3161 only a hash travels to the timestamping authority.

The word 'qualified' comes from EU law, but you settle it in a register rather than in a file: the Trusted List of the country where the provider is established.

Why can't you read 'qualified' off the timestamp itself?

A timestamp token issued under RFC 3161 can carry a policy identifier: a numeric string naming the policy the issuing authority says it followed. It is a self-declaration. The issuer writes it, nobody countersigns it at the moment of issue, and no parser can turn a number into a legal status.

That matters because "qualified" is not a property of the file. It is a designation that attaches to one specific service of a trust service provider, and it becomes checkable when that service appears on a national Trusted List. A token from a service that is not listed can be technically impeccable and still not qualified.

So when software prints the word "qualified" in a report, the useful question is where it read that from. If the answer is "from the token", you are looking at the issuer's marketing dressed up as a verification result. We state qualified status on the basis of a named service on a named list, never on what a token says about itself.

How do you check the EU Trusted List yourself?

The European Commission publishes the Trusted List Browser, a public interface over the Member State Trusted Lists and the Commission's List of Trusted Lists. No account, no fee, no vendor in between. Pick the country where your provider is established, open its entry, find the service that issues timestamps, and read the current status.

There is a machine-readable route as well. The List of Trusted Lists points to each national list, so a compliance team can automate the check instead of repeating it by hand every year.

Provider level is not service level

Here is the trap. "The provider is on the list" and "the service that signed my token is on the list" are different statements, and only the second is worth anything. Signature certificates, seals, website authentication and timestamping are listed separately, and those entries need not carry the same status. Reading the provider header and stopping there is the most common mistake we see in supplier questionnaires.

Our own supplier is Disig a.s. in Slovakia. When we checked the Slovak list on 28 July 2026 it carried 36 services of type TSA/QTST, all with status granted, and we traced ours down to the individual timestamping unit that signs our tokens. The provider name alone would not have told us that.

What does Article 41(2) actually give you in a dispute?

The whole legal value of the word sits in one sentence. Article 41(2) reads: "A qualified electronic time stamp shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound" (Regulation (EU) 910/2014).

Two presumptions, then, not one. The time is presumed accurate, and the data bound to that time is presumed unaltered. Without it, the party relying on the document explains why its date can be trusted. With it, the party attacking the document has to show the timestamp is wrong. Anyone who has watched a case turn on a bare denial will recognise how much that is worth.

Read it against Article 41(1), which covers every electronic timestamp, qualified or not: such a timestamp "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic time stamp". A floor, then, rather than a benefit. Admissible is not the same as persuasive. Article 41(3) adds that a qualified timestamp issued in one Member State counts as qualified in all of them.

Note what the presumption leaves alone. It says nothing about authorship, consent, or whether the content is correct. A backdated contract stamped today becomes a backdated contract with a reliable record of having existed in that form from today onward. Useful, and not proof that the agreement was made when it claims. The honest framing is narrow: this exact file existed no later than this moment, with a presumption your opponent must overcome. Identity questions belong to signatures, and our legal overview covers where those fit.

Which requirements does Article 42 impose?

Article 42(1) sets out three cumulative conditions that a timestamp must satisfy before it may be called qualified. In summary (Regulation (EU) 910/2014):

1. it binds the date and time to the data in a way that makes undetected alteration of that data unlikely;

2. it rests on an accurate time source linked to Coordinated Universal Time;

3. it is signed or sealed by the qualified trust service provider with an advanced electronic signature or seal, or by an equivalent method.

Read plainly: the clock must be tied to UTC rather than to whatever the issuing machine believes, and the provider has to put its own cryptographic weight behind the result. Change one byte and the binding no longer matches, which is why a screenshot of a file property is not in the same category.

One correction worth carrying into a memo. Article 42 holds the requirements, Article 41 holds the legal effect. Several published guides attribute the presumption to Article 42, which is the wrong article to cite in a submission. Supporting standards exist as well, notably ETSI EN 319 421 and EN 319 422, but the presumption lives in Article 41(2).

Does your document leave the building when you timestamp it?

No, and for anyone under a duty of confidentiality that should settle the matter. RFC 3161 defines a request carrying a message imprint: a hash of the data, and nothing else. The document never reaches the timestamping authority. What comes back is a signed token holding a serial number, the authority's view of the time, and that same hash again.

A hash cannot be run backwards. From the imprint, the authority cannot reconstruct a sentence, a client name, a figure or a filename. It learns only that someone asked for a timestamp over data of a fixed length. Privilege and professional secrecy stay intact.

One consequence follows. Since the proof binds to exact bytes, you have to keep the exact file. Re-exporting the PDF or running it through a conversion produces a different hash, and the token stops matching. Archive what you stamped, not a later version of it.

What does the green checkmark in Adobe Reader really mean?

Less than people assume. A valid indicator tells you that the cryptographic signature over the document verifies, that the reader treats the certificate behind it as trustworthy according to the trust lists that reader carries, and that the file has not changed since the signature was applied. It does not tell you the content is true, or that the person named in the document agreed to anything.

Where a document timestamp is involved rather than a personal signature, nobody has signed in the ordinary sense: an authority attested to a moment, not to a party's consent. Readers render both with similar reassuring iconography, which is why the distinction gets lost. The trust decision also belongs to the software: a green mark reflects that reader's own configuration, not a finding under eIDAS.

How does this compare with doing it yourself in Adobe Acrobat?

Acrobat can apply a document timestamp, but it does not supply one. You point it at a timestamp server yourself, so whether the result is qualified depends on which service you chose, and on whether you checked that service against the Trusted List first.

Neither column is the right answer in every case. If your firm already runs Acrobat and buys timestamps from a qualified provider, carry on. The point of the table is narrower: your software does not determine qualified status, and neither does your invoice.

Frequently asked questions

Do I have to send my document to the timestamping authority?

No. RFC 3161 sends only a message imprint, which is a hash of the file. The document never leaves your environment, and the authority cannot reconstruct its contents from the hash it receives.

Can I put a timestamp on a PDF that somebody else sent me?

Yes, and it is often sensible. Understand what you get: proof that this exact file existed in this exact state from the moment you stamped it. It says nothing about the period before that, so stamping incoming material on receipt beats stamping it once a dispute has started.

Can't I just check the PDF's creation date instead?

Not for anything contested. Creation and modification dates inside a PDF are ordinary metadata fields and can be rewritten without special skill. A timestamp works because the record sits outside the file, with a third party's signature over it.

Is a qualified timestamp the same as a qualified electronic signature?

No, and they answer different questions. A signature is about who committed to a document. A timestamp is about when a specific set of bytes existed and whether it has changed since. Article 41(2) gives the timestamp its presumption of accurate time and intact data, and stops there.

What happens to my proof if the provider disappears?

An RFC 3161 token is a self-contained file, so a third party can check it with standard tooling rather than with the issuer's software. Keep the stamped file and the certificate chain alongside it, and verification stays possible regardless of whether the original supplier is still trading.

Who can use the timestamp tool at PDFen, and what does it cost?

The tool is open to paid accounts, one-time or premium, and each stamp costs 20 credits for a single PDF of up to 50 MB. Free and test accounts have no access. Credit bundles and plans are listed on the pricing page.

One line in that panel deserves a footnote. Acrobat reports "Signature is LTV enabled", but that verdict comes from its own trusted lists rather than from data inside the file — this PDF embeds no revocation information. Adobe documents that the same signature can be LTV enabled on one machine and not on another. It changes nothing about the green checkmark; it does mean a validator without the EU trusted list can reach a different conclusion.

Check it yourself, then decide

If you take one habit away from this, make it the two-minute check. Open the Trusted List Browser, find the service that actually signs your timestamps, and read its status. Do it for us as readily as for anyone else: our stamps come from Disig a.s. in Slovakia, service type TSA/QTST, status granted on the Slovak list when we verified it on 28 July 2026. A falsifiable claim is the only kind worth making.

When you want a stamp on a specific PDF rather than a policy discussion, the qualified timestamp tool does exactly that: one PDF up to 50 MB, 20 credits, and a token from a qualified service embedded in the file you get back.

Daan van Tongeren is the founder of PDFen, where he built the qualified timestamping service described here and checked its Trusted List entry himself.