Trusted Timestamping Explained

Trusted Timestamping Explained: How a Date Becomes Evidence

Trusted timestamping is a way of proving that a piece of digital data existed at or before a specific moment, using a time record that someone other than you vouches for. The data is reduced to a cryptographic hash, the hash is bound to a time by an independent party or system, and anyone can later check that the data still matches. It matters because the date a computer shows for a file is something its owner can change in seconds, and a record you control has little evidentiary weight.

The trouble with the date on your own computer

Right-click any file and you’ll see a “date modified.” That value is written by the operating system, from the clock on the machine, and anyone with admin rights can edit it. Email headers, cloud-drive metadata and even PDF creation fields have the same weakness: they are claims made by software the author controls.

For most of life this doesn’t matter. It starts to matter when somebody else has an interest in the date being wrong. A contractor says the drawings were final in March. A researcher needs to show a result was written down before a rival published. A company has to show a policy existed before an incident. In each case the other side can reasonably ask, “Says who?” Trusted timestamping is an attempt to give that question an answer that doesn’t depend on the person making the claim.

What a timestamp actually contains

The classic design is defined in RFC 3161, the IETF’s Time-Stamp Protocol, published in 2001. The idea is simple. You don’t send your document anywhere. You compute a hash of it and send only the hash to a Time Stamping Authority, or TSA. The TSA replies with a Time Stamp Token that includes the hash, a unique serial number, a timestamp and a digital signature made with the TSA’s private key.

A few things about that design are worth slowing down on.

The hash is a fixed-length fingerprint. Change a single character in the original and the fingerprint changes completely, so the token is tied to exactly one version of the content. The standard also says the TSA should only stamp a hash representation of the data, never the data itself, which is why timestamping is compatible with confidential material.

The signature is what turns a number and a clock reading into evidence. If the TSA’s signature verifies, then the hash and the time haven’t been altered since the TSA issued the token. The signing key is meant to be reserved for timestamping only.

The serial number matters more than it looks. It gives each token a unique place in the TSA’s own sequence, which helps auditors notice gaps or duplicates.

The standard’s own framing is modest and accurate: the TSA’s role is to establish evidence indicating that a datum existed before a particular time. Before, not “was created at.” Keep that distinction in mind, because it comes back later.

Whose word are you taking?

Here is the uncomfortable part of any trusted timestamp: “trusted” is doing a lot of work. In the TSA model you are trusting a specific organisation to keep an accurate clock, to guard its signing key, to log honestly, and to still be around, with verifiable certificates, years after you need the proof.

Each of those is a real failure mode. A TSA with a drifting clock issues wrong times. A leaked key lets someone mint tokens for any time they like. A TSA that shuts down leaves you holding tokens whose certificate chains are harder to validate as time passes, which is why long-term archiving practice involves re-timestamping and collecting validation evidence rather than just filing the token and forgetting it.

None of that makes the model bad. Well-run, audited TSAs are the backbone of long-term document signing in many industries. It simply means the evidence is only as good as the operator, and good practice is to know who the operator is and what they’re audited against.

Qualified timestamps and the European angle

In the EU, the eIDAS Regulation (910/2014) gives timestamping a legal vocabulary. Two ideas are worth separating.

First, an electronic time stamp can’t be denied legal effect or admissibility in legal proceedings solely because it is electronic or because it isn’t “qualified.” So a non-qualified timestamp isn’t worthless in court. It just doesn’t get any special treatment.

Second, a qualified electronic time stamp gets a head start. Under Article 41, it enjoys a presumption of accuracy for the date and time it shows and for the integrity of the data bound to them. To qualify, it must bind the time to the data so changes can’t go undetected, rely on an accurate time source linked to UTC, and be signed or sealed by a qualified trust service provider (or an equivalent method).

“Presumption” is the operative word. It shifts the burden of argument; it doesn’t end the argument. And it applies in the EU framework, which is not the same thing as law everywhere. Other jurisdictions treat electronic evidence under their own rules, and nobody should assume a timestamp that works in a Frankfurt courtroom works the same way elsewhere. Our separate piece on blockchain records as court evidence goes further into how courts have approached this. None of this is legal advice, and anyone relying on a timestamp in a dispute should ask a lawyer in the relevant jurisdiction.

A different answer: anchoring the hash to a blockchain

Blockchain timestamping solves the same problem by replacing the single trusted operator with a public ledger that many independent parties maintain and that is very hard to rewrite after the fact. You still hash the file. Instead of asking one authority to sign the hash, you embed it in a blockchain transaction. Once the transaction is in a block, the block’s position in the chain and its recorded time become the evidence.

The trade-offs run in both directions, and it’s worth being straight about them.

On the plus side, there is no single signing key whose compromise invalidates everything, and no single company whose disappearance leaves the record unverifiable. Anyone can check the record themselves against the public chain, without asking permission.

On the other side, block times are set by the network’s participants and are approximate, so the sensible reading is “no later than roughly this time,” not a clock reading accurate to the second. A blockchain record is also not, simply by being on a blockchain, a qualified electronic time stamp under eIDAS. Those are different legal categories, and anyone who needs the presumption in Article 41(2) needs a qualified service. For many other purposes, such as internal audit trails, research notebooks, invention records and creator workflows, independent verifiability matters more than a statutory presumption.

How Certelo handles it

Certelo takes the blockchain route, with the privacy property of the original RFC 3161 design kept intact. The SHA-256 hash is calculated locally, on the user’s device, so the original file doesn’t need to be uploaded just to create the record. That hash is then anchored to the Electra Protocol blockchain.

Verifying later works in the other direction. Someone with the original file can recompute its hash and compare it with the anchored record. If the two match, the file is bit-for-bit identical to what was stamped. If a single byte differs, they won’t match, and that is exactly the behaviour you want from an integrity check.

A hypothetical example, clearly invented for illustration: an engineer finishes a design specification as a PDF on a Monday, hashes and anchors it, and stores the certificate details alongside the project folder. Two years later, a supplier disputes which version of the spec was in circulation. The engineer produces the PDF; anyone can hash it and compare it to the on-chain record. The record doesn’t say the engineer wrote the spec. It says that exact file existed by that time, which narrows the dispute considerably.

If you want the mechanics, How Certelo Works walks through the process step by step, and the verification page lets you check a record yourself.

Where timestamps earn their keep

Timestamps are useful wherever “which version, and by when?” is a live question. Software teams use them on build artifacts and dependency inventories, which we cover in timestamping SBOMs for supply chain audits. Finance teams use them on invoices and payment records. Research groups use them on lab notebooks and datasets, and AI teams on training-data documentation, as discussed in documenting synthetic data for AI audits. Inventors and creators use them to fix a point in time for drafts, prototypes and masters.

The common thread is that the timestamp costs almost nothing at the moment of creation and can be worth a great deal if a dispute ever arrives. The reverse is not possible: you can’t timestamp something retroactively and have it mean what it would have meant earlier.

What no timestamp will tell you

This is the part most vendor pages skip, so it’s worth stating plainly.

A timestamp doesn’t prove who made the file. Anyone can hash and stamp someone else’s work, and the record will be perfectly valid. It doesn’t prove ownership, originality or copyright. It doesn’t prove the content is true, or that a document is legally binding. It proves that a particular fingerprint existed by a particular time, and that’s all it proves.

It also can’t tell you when the file was created, only a latest-possible moment. A file stamped today may have existed for ten years. And it can’t help with a file you’ve lost: if you don’t have the original bytes, the hash is just a number.

Combine timestamps with other evidence, such as version control history, signed commits, correspondence and registered rights where relevant, and the picture gets much stronger. A timestamp is one solid brick, not the whole wall.

Choosing the right tool for the job

If you need the statutory presumption in an EU context, use a qualified trust service provider and check them against the EU trusted list. If you need an auditable internal process, an RFC 3161 TSA you’ve vetted is a well-understood choice. If independent, permissionless verification and keeping the file on your own device are the priorities, blockchain anchoring is a reasonable fit. Plenty of organisations will end up using more than one, because the needs differ by document.

Questions people ask

Is a trusted timestamp the same as a digital signature?

No. A signature binds a document to a signer’s key. A timestamp binds a document’s hash to a time. They’re often used together, because a timestamp can show a signature was applied before a certificate expired or was revoked.

Does the TSA see my document?

Under RFC 3161, no. Only the hash is sent. That said, always read a provider’s actual process rather than assuming.

Can a timestamp be forged?

Forging a properly signed token would require the TSA’s private key, which is why key protection and audits matter. For blockchain records, it would require rewriting the chain’s history, which becomes harder as more blocks are added.

Is a blockchain timestamp legally valid?

In the EU, an electronic time stamp can’t be rejected as evidence solely for being electronic, but only a qualified one carries the Article 41(2) presumption. Admissibility and weight elsewhere depend on local law, so check with a lawyer for your jurisdiction.

What happens if I edit the file after stamping it?

Its hash changes, so it no longer matches the record. The original, unmodified file still does, so keep the original.

Do I need to keep the file forever?

You need to keep the exact original for as long as you want to be able to prove the record. The timestamp can’t recreate it.