eIDAS Electronic Timestamping: Simple vs Qualified, What Changes (and How to Verify)

Electronic timestamping comes up a lot as a way to prove a file existed at a specific date and time. Once you look into it, the same question surfaces: what actually changes between non-qualified and qualified eIDAS timestamping?

The difference goes beyond wording. It affects evidentiary value, presumptions of reliability, and what you may have to explain if your evidence is contested.

This guide covers: eIDAS definitions, when each option is worth it, the limits of each, and how to verify whether a timestamp is genuinely qualified.

Plain-English definition

Under eIDAS, an electronic timestamp links data to a specific point in time and establishes that the data existed at that moment. (EUR-Lex)

"Simple" vs "qualified": key terms

• "Simple" timestamping: in practice, people usually mean a non-qualified electronic timestamp. "Simple" is common shorthand, not an official eIDAS legal category.
• Qualified electronic timestamp: a timestamp that meets eIDAS qualified-service requirements and is issued within a qualified trust services framework. (EUR-Lex)

eIDAS sets three core principles:

• Non-discrimination: a timestamp cannot be denied legal effect solely because it is electronic or not qualified. (EUR-Lex)
• Presumption for qualified timestamps: presumed accuracy of date/time and integrity of linked data. (EUR-Lex)
• EU cross-border recognition: a qualified timestamp issued in one Member State is recognized as qualified in all Member States. (EUR-Lex)

How it works

A solid timestamping workflow is almost always the same: hash -> timestamp -> verification.

1. 1
   Generate a file fingerprint (hash)

   Compute a cryptographic hash (for example SHA-256). If the file changes, even slightly, the hash changes.
2. 2
   Bind date/time to the data

   The timestamp binds a date/time to the data (often through the hash). For qualified timestamps, eIDAS requires a link that reasonably prevents undetectable modification.
3. 3
   For qualified: rely on UTC time and provider signature/seal

   A qualified timestamp must be based on accurate time linked to UTC and signed or sealed by the qualified trust service provider (QTSP), or equivalent.
4. 4
   Keep all proof artifacts

   Keep the original file, hash, timestamp token/receipt, and ideally a verification report. Without clean retention, practical evidentiary value drops.

What "qualified" adds in practice

eIDAS is not just about using a good algorithm. Qualified timestamping sits inside a broader qualified trust service framework, including conformity checks and trusted-list publication. (ANSSI)

In France, ANSSI explains that a qualified trust service provider must pass conformity assessment, obtain qualified status, and be listed as such before delivering qualified services. (ANSSI)

At standards level, the European Commission also publishes references used for qualified timestamping practices (including ETSI EN 319 421 and ETSI EN 319 422). (EUR-Lex)

When it is useful

When non-qualified timestamping can be enough

• Showing business priority (internal creation, versioning, routine client exchanges).
• Strengthening a pre-litigation file: date + integrity for a document, exported email, quote, PDF, or deliverable.
• IP support: showing that a work existed no later than a given date, alongside other evidence.

In these scenarios, a workflow like LegalStamp is useful to operationalize the process: hash, timestamp, archive, and verify later.

When qualified becomes a real advantage

• High-stakes matters (likely dispute, high financial exposure, reputational risk).
• Situations where you want to reduce reliability disputes through the eIDAS presumption. (EUR-Lex)
• Cross-border EU contexts where qualified recognition is operationally important. (EUR-Lex)

What it proves, and what it does not

What it proves (or strongly supports)

• Existence at a date/time: the content existed at least by that timestamp.
• Integrity: if the current file hash matches the timestamped hash, it supports that the file has not changed.

For qualified timestamping, eIDAS grants a presumption of date/time accuracy and integrity of the linked data. (EUR-Lex)

What it does not prove on its own

• Who authored or signed the content.
• Consent or overall contractual validity.
• Full context (custody chain, production circumstances, access history).

How to verify (non-qualified or qualified)

1) Verify provider qualified status (if you need qualified)

A timestamp is qualified only if it is delivered by a QTSP, and the provider/service appears in official trusted lists. (EU Digital Strategy)

In practice:

1. Check the provider in the national trusted list (for France: ANSSI resources). (ANSSI)
2. Use the EU Trusted List Browser to verify the provider, the specific service type (timestamping), and its qualified status. (eIDAS Dashboard)

Do not check only the company name. Check the specific service and status.

2) Verify the timestamp token

In eIDAS/ETSI-aligned systems, timestamping often relies on signed structured tokens (commonly around RFC 3161 profiles). (ETSI EN 319 421)

At minimum, a serious verification should:

• Recompute the file hash.
• Confirm it matches the hash carried by the timestamp.
• Validate timestamp signature/seal and certificate chain.
• If qualified, confirm qualified status through trusted lists.

3) Verify time consistency (UTC and sources)

For qualified timestamping, eIDAS requires accurate time linked to UTC. (EUR-Lex)

In all cases, keep context artifacts that explain:

• time source,
• production environment,
• relevant logs where needed.

4) Produce a readable verification report

The strongest evidence package is usually the one a third party can understand quickly:

• original file (or hash if confidentiality requires),
• hash + algorithm,
• timestamp token/receipt,
• provider-status proof (if qualified),
• verification report (tool, date, outcome).

That is the logic behind workflows like LegalStamp: hash → timestamp → archive → verify, with evidence you can reuse without overclaiming.

Best-practice checklist

• [ ] Timestamp early, as soon as the version is ready to share.
• [ ] Keep the original file (or a bit-by-bit copy) and its hash.
• [ ] Keep hash + algorithm (for example SHA-256), not just screenshots.
• [ ] Keep the token/receipt in durable storage (ideally redundant).
• [ ] Document chain of custody: who had the file, where, when, how.
• [ ] If qualified is required: verify QTSP/service in trusted lists and archive proof of that check. (EU Digital Strategy)
• [ ] Do not confuse timestamping and electronic signature.
• [ ] Plan periodic verification for long-term evidence retention.

FAQ

1) Does eIDAS require qualified timestamping?

No. eIDAS states that timestamps cannot be denied legal effect solely because they are electronic or not qualified. (EUR-Lex)

2) Is "simple timestamping" an official eIDAS category?

Not really. "Simple" is common shorthand for non-qualified. Legally, eIDAS primarily distinguishes electronic timestamps and qualified electronic timestamps. (EUR-Lex)

3) What is the core evidentiary difference?

Qualified timestamping benefits from a presumption (date/time + integrity) and EU recognition as qualified. (EUR-Lex)

4) How do I confirm a provider is QTSP for timestamping?

Check trusted lists. They identify qualified providers and qualified services. The Trusted List Browser is the practical tool for this. (EU Digital Strategy) (eIDAS Dashboard)

5) Is blockchain timestamping automatically eIDAS-qualified?

No. Blockchain can strengthen technical integrity and chronology, but eIDAS-qualified status requires compliance with eIDAS requirements and a qualified provider/service. (EUR-Lex)

6) What should I retain so the evidence remains useful?

Minimum set: file (or exact copy), hash + algorithm, and timestamp token/receipt. Best case: add a verification report and qualified-status proof when relevant.

7) Is a qualified timestamp recognized across the EU?

Yes. eIDAS provides recognition across Member States. (EUR-Lex)

8) Timestamping or electronic signature: which one should I use?

• If identity/consent matters: use electronic signature.
• If existence at a date and integrity matter: timestamping is central.

In many cases, both are used together. (ETSI EN 319 421)

9) How does eIDAS technically frame qualified timestamping?

eIDAS sets core requirements (binding date/time to data, UTC-linked clock, provider signature/seal). ETSI standards provide the technical framework used in practice. (EUR-Lex) (EUR-Lex)

10) Does LegalStamp replace a qualified timestamping service?

LegalStamp is primarily designed to structure and strengthen evidence through the workflow hash -> timestamp -> archive -> verify. If your use case specifically requires qualified eIDAS timestamping, verify that the selected service is delivered by a listed QTSP.

Conclusion

eIDAS timestamping has two modes. Non-qualified is admissible and works well day-to-day when you handle retention and traceability properly. Qualified gives you the same core logic, plus a legal presumption and EU-wide recognition that can simplify disputes.

Either way, the process is the same: hash → timestamp → archive → verify. The mode you choose determines how much you have to argue about reliability if it ever comes up.

Disclaimer: This article is provided for informational and educational purposes only. It is not legal advice. For specific disputes, procedures, or compliance decisions, seek advice from qualified legal counsel.