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.

Where does LegalStamp fit in? (Non-qualified timestamping)

Let's be upfront: LegalStamp is not a Qualified Trust Service Provider (QTSP) under eIDAS. We deliver non-qualified timestamps, built on three layers:

• SHA-256: cryptographic fingerprint computed locally in your browser (your file never leaves it)
• OpenTimestamps: open-source timestamping protocol
• Bitcoin blockchain: decentralized anchoring via Merkle aggregation

Why non-qualified is enough for most use cases

eIDAS sets a clear rule (Article 41.1): a timestamp cannot be denied legal effect solely because it is non-qualified. (EUR-Lex)

This is also confirmed in real cases: the Marseille Judicial Court accepted blockchain timestamping as proof of priority in a copyright dispute in March 2025.

In practice, non-qualified timestamping covers the typical scenarios:

• Creative work and IP: prior existence of a text, design, logo, source code, photograph.
• Contracts and deliverables: versioning of a quote, terms of service, client deliverable, exported email thread.
• Protection before sharing: lock evidence before sending work to a client, publisher, or investor.
• Long-term archival: proof of file state at a date, retained for 10+ years.

When to switch to qualified timestamping

Qualified timestamping becomes a real edge when:

• The financial or reputational stakes are very high (cross-border litigation, large amounts).
• The technical reliability itself is likely to be challenged by the opposing party.
• You operate in a cross-border EU context that requires automatic qualified recognition.

In those cases, you need to use a QTSP listed in the European Trusted Lists — and that is what we honestly recommend.

For most users — creators, freelancers, businesses, lawyers

Blockchain non-qualified timestamping is:

• Fast: 30 seconds per document, no administrative procedure.
• Affordable: free up to 5 timestamps/month, €9/month unlimited — versus often tens of euros per timestamp at a QTSP.
• Decentralized: anchored on Bitcoin, independent of any single company whose shutdown would make verification impossible.
• Private: your file never leaves your browser, only the hash is transmitted.

See LegalStamp pricing → · Try free (3 timestamps/month, no card) →

FAQ

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.