A signature answers one question: who. A qualified timestamp answers a different one: when. Most disputes over authorship, AI disclosure, or who created something first turn out to hinge on the second question far more than the first, which is why a timestamp usually carries more weight than people expect going in.
What a qualified electronic timestamp actually is
A timestamp does not store your file. It stores a cryptographic hash of your file, a fixed-length fingerprint derived from the bytes themselves, and binds that fingerprint to a specific moment using a signature from a trusted third party. The mechanism most systems use for this is described in RFC 3161, the Time-Stamp Protocol, which sets out how a Time Stamping Authority receives a hash, attaches the current time, and returns a signed token that anyone can verify later without contacting the authority again.
Under the EU's eIDAS regulation, a timestamp only becomes qualified when it is issued by a Qualified Trust Service Provider operating under specific supervision and audit requirements. Article 41 of that regulation gives a qualified electronic timestamp a legal presumption as to the date and time it indicates and the integrity of the data it is bound to. That presumption is the entire point. A date sitting in your own file system, your own cloud storage, or your own project tool is a date you produced, and a date you can be asked to justify. A qualified timestamp is a date a licensed third party produced, under rules set by regulation rather than by you.
Why the when usually decides the argument
Take a typical authorship dispute. Two parties both claim to have created something first, or one accuses the other of copying. The identity of the creator is rarely the contested fact, both sides usually agree on who made which version. What gets argued over is order: which version existed first, and when each party actually had access to the material in question.
The same pattern shows up in AI content disclosure. Whether a piece of writing was AI generated, AI assisted, or written by a person is a claim you make at the point of publication. What makes that claim checkable later is not the label itself but proof of when the label was attached, because a label added after someone has already raised a question is worth very little.
Client work follows the same logic. A freelancer and a client disagree about which draft was delivered on which date, or whether a change request came before or after a milestone. None of this depends on who wrote the document. All of it depends on a timeline neither side controls alone.
What the records you already have do not give you
Most teams assume they already have this covered. An email with a date on it, a file's last-modified property, a commit history in a code repository, a save date inside a cloud drive. Each of these carries a date, and each of them is held, stored, and editable by the same party making the claim. A file's modified date changes the moment the file is copied or reopened on a new machine. An email date can be checked against a server log, but the server belongs to whichever provider you use, and the log is rarely something a counterparty can inspect directly. None of these records were built to survive being questioned by someone with a reason to doubt them, because none of them separate the date from the person asserting it.
A qualified timestamp is built specifically to close that gap. The date comes from a party with no interest in the outcome of any dispute you might end up in, operating under audit and supervision requirements set out in regulation, and the record can be checked by a stranger without needing your cooperation at all.
How this differs from a signature
A signature, qualified or otherwise, is an act of identity and consent. It says a specific person reviewed and agreed to a specific document. Swisscom Trust Services operates as an accredited certification service provider under Switzerland's ZertES framework, and a signature issued that way tells a reader who stood behind the document.
A timestamp does not tell you who. It requires no identity verification of the person requesting it, and it makes no claim about consent or agreement. What it tells you is that a specific hash, meaning one exact file, existed no later than a specific moment, attested by an independent party with no stake in the dispute. The two mechanisms answer different questions, and a complete record often needs both: a signature for who stood behind the content, a timestamp for when that content existed in that exact form.
This is also why a timestamp does work a signature cannot. You can timestamp a draft nobody has signed yet, an internal document that will never carry a formal signature, or a piece of AI-assisted writing where the point is not consent but chronology. It is the lighter tool, and the one that applies to more situations, which is part of why it gets used less often than it actually helps.
What the legal presumption is worth in practice
It is worth being precise about what the eIDAS presumption does and does not do. It shifts the starting position: a qualified timestamp is presumed accurate as to date, time, and data integrity, so a party disputing it carries the burden of showing otherwise, rather than the party relying on it having to prove accuracy from scratch. It does not force acceptance of every argument built on top of it, and it does not replace other evidence a case might still need. What it removes is the weakest link in most self-made records: a date that came from the same party making the claim.
That is also the practical test for whether a given date is worth anything in a dispute. A date field you can edit is not evidence, it is an assertion. A date attested by a Qualified Trust Service Provider under eIDAS, verifiable by a stranger without contacting you, is a different kind of object. Our eIDAS page goes into how that qualification works for Swiss Trust Layer specifically, including which provider issues the timestamp and what a recipient sees when they check one.
How a recipient actually checks one
The step that makes any of this worth doing is the one that happens outside your organisation. A qualified timestamp is only useful if somebody who has no reason to trust you can confirm it holds up on their own. That means a public verification page, no account required, no software to install, and no need to contact you to ask whether the record is genuine. Send the link, and the recipient checks the hash against the file, the timestamp against the record, and reaches their own conclusion.
This is where a lot of internal record-keeping quietly fails. A timeline stored in your own systems, however detailed, still requires the other side to trust your systems. A qualified timestamp moves that trust to a regulated third party instead, which is the difference that tends to matter once a disagreement turns serious enough that trust is exactly what is missing.
Where this fits with content hashing
The timestamp fixes when a specific file existed. A separate mechanism, an ISCC content hash registered in a public database, is what makes the content itself traceable later without exposing the original file, which matters for infringement checks and AI-training licensing questions that have little to do with authorship disputes but everything to do with knowing where a piece of content has since been used. The two work together rather than replacing each other. The ISCC hash makes content identifiable at scale. The qualified timestamp fixes the point in time a specific version of it existed.
None of this requires the underlying work to be finished, formally registered anywhere, or reviewed by a lawyer first. A qualified timestamp attests to a moment, not to the merit of what existed at that moment, which is exactly why it applies to a draft as readily as to a finished file.
