We set out to test two things at once: whether our own certificates hold up in software we did not write, and how a third-party validator handles a real certificate. Both answers are worth reporting.
Independent verification is the load-bearing claim of the cryptographic evidence category. A record only its issuer can confirm is not evidence. It is an assertion about evidence, which is a weaker thing entirely.
Every provider in the market makes the claim. Very few have published the result of putting their own output into somebody else's software and reporting what came back.
So we did, and the exercise had two purposes rather than one. The first was to establish whether a qualified timestamp issued through our platform would be recognised as qualified by software built by somebody else. The second was to see how a third-party validator behaves when handed a real certificate rather than the input its designers assumed.
On 23 August 2026 we took a live deposit certificate to a third-party RFC 3161 validator built by another provider and worked through the whole route a recipient would follow. The first question produced a clean answer. The second produced a more useful one.
The exercise cannot be done from a desk. Anyone can read the RFC 3161 specification and conclude that a token ought to validate anywhere that accepts tokens. Whether it does depends on file handling, reader behaviour and interface assumptions that only surface when somebody tries in earnest, with a real certificate, in software they did not write.
The headline is the part that matters. The qualified timestamp inside the certificate validated as qualified. The tool reported it as valid, identified the accredited Qualified Trust Service Provider that issued it, and returned the sealing date to the second in UTC.
That conclusion was not reached by taking our word for anything. The validator reads the cryptographic signature on the token, identifies the trust service provider that applied it, and checks that provider against the European Commission's trusted lists. Those lists are maintained by the Commission and populated by national supervisory bodies. Neither we nor the company that built the validator controls a single entry on those lists.
Two competitors in the same market, deferring to the same external register, arriving at the same answer. Neither company had to cooperate for that to happen, and neither could have prevented the result. That is the strongest available form of the claim, and it is available to anyone holding a certificate who wants to repeat the exercise.
It is worth being precise about what that confirmation covers. The validator is not endorsing our platform, our process, or the deposit that produced the certificate. It is confirming one narrow and important thing: that the timestamp bound to this fingerprint was issued by a provider on the qualified list, at the moment recorded, and has not been altered since. That is the fact a dispute turns on, and it now rests on a finding no party to any dispute produced.
That answered the first question. The second question was how the validator itself performed with a real certificate, and getting to the result above took more steps than a recipient would expect.
The certificate was rejected on the first attempt. It is a PDF carrying its timestamp tokens as embedded attachments, and the validator would not parse that format. It asked instead for a raw RFC 3161 binary file.
That is a reasonable place for a tool to draw its boundary. Raw tokens are what an engineer working with timestamping infrastructure handles, and a validator built for that audience has no reason to open PDFs looking for attachments. The design serves its intended audience well.
That refusal is a legitimate design decision rather than a defect. An RFC 3161 validator is entitled to expect an RFC 3161 file, and given the input it asks for, it parsed, validated and reported correctly and quickly. The tool does the job its designers built.
The question is whether that job matches what a recipient has in their hands. Almost nobody receives a raw token. What arrives by email, or lands in a data room, or gets attached to a letter from the other side's solicitors, is the certificate. A validator that accepts only the raw token is asking the recipient to perform an extraction step before any verification can begin.
That matters because of who the recipient usually is in practice. A forensic expert instructed for the purpose will work out the file handling. The solicitor doing an initial assessment, the insurer reviewing a claim, or the counterparty deciding whether to argue will give the record one attempt. For those readers, a verification route that begins with an unexplained rejection is a verification route they do not complete.
That extraction step is where the friction sits. The tokens are embedded in the certificate exactly as the format intends, but the most widely used PDF reader lists both attachments and then declines to open them, because of its attachment-type settings. The files are visibly there and apparently one click away.
The resolution is to save the attachment to disk rather than open it, because saving follows a different code path from opening. One word separates a recipient who verifies the record from one who concludes the record cannot be verified. None of this is a property of the evidence. It is a property of the software chain the recipient happens to be holding, and it is invisible until somebody walks the whole route.
There is a further consequence of the raw-token approach that is easy to miss. A validator given a single token can only report on that token. It has no way to know whether the certificate it came from contained others, because it never saw the certificate.
The certificate in this test carried two timestamps. A recipient who extracts one, submits it, and reads the result has a true answer about that token and no indication that a second exists. Nothing on the screen tells them the picture is partial. Getting the full position means knowing in advance how many tokens the certificate holds, extracting each one, and submitting each one separately.
We also tested what the validator does when given the certificate where it asks for the original document. It reported a mismatch, which is the correct answer to that input: the token commits to the fingerprint of the deposited work rather than the certificate describing that work. Worth knowing before a recipient sees a mismatch and draws the wrong conclusion.
Put the same certificate into our own validator and the sequence collapses to a single step. It accepts the certificate as issued, reads every embedded token without anything being extracted, and reports each one separately.
That difference is about disclosure rather than convenience. Reading the certificate rather than a token means the tool reports the certificate's full contents, including tokens the recipient had no way of knowing were present. The recipient is shown the complete position instead of assembling it from parts they had to find first.
That second part carries more weight than the convenience. The certificate in the test carried two timestamps: a qualified one from an accredited Qualified Trust Service Provider, and a free timestamp alongside. Our validator reported the qualified one as qualified, and reported the free one as valid but absent from the EU trusted lists.
Grading our own free timestamp as unqualified is the behaviour the independent-verification claim requires. A validator that returned a flattering result for everything its own company produced would be worth nothing to a recipient, and the first solicitor to look at it would say so. The value of a verification tool lies precisely in its willingness to report an unwelcome answer.
The same principle governs what a certificate should contain. Carrying both a qualified and a free timestamp, and labelling each for what it is, gives a recipient more than carrying only the stronger of the two. It lets them see the whole record and decide what weight to give each part, rather than being handed a curated version and asked to trust the curation.
The distinction it draws is the one that matters in a dispute. A qualified electronic timestamp carries a presumption under Article 41(2) of eIDAS as to the accuracy of the date and time recorded and the integrity of the bound data. A free timestamp carries no such presumption, though Article 41(1) prevents any timestamp from being denied legal effect solely for being electronic or for falling short of the qualified standard. A recipient needs to know which one they are looking at, and a validator that does not tell them is not doing the job.
The exercise is worth repeating on any certificate from any provider, and takes about ten minutes.
Start with the issuer's own validator if it accepts the certificate as issued, because that establishes what the record contains before anything is extracted. A validator that reads the certificate directly removes the extraction problem entirely, which is worth knowing when choosing where to deposit in the first place. Read what it reports for each token: valid or not, qualified or not, which trust service provider issued it, and the sealing date.
Check the issuer name against the European Commission's trusted list browser directly. This is the step most people skip, and it is the one that converts a screen saying qualified into a fact. The register is public, searchable, and maintained by an authority with no relationship to either the issuer or the recipient. A provider that appears on it is qualified; a provider that does not is not, whatever any tool displays.
Then confirm the qualified token independently. Save the embedded token to disk rather than opening it, and put the saved file into a third-party RFC 3161 validator. A qualified result from software built by a different company, checked against a register neither company controls, is the answer that settles the question.
The same question is worth putting to any provider whose evidence you might one day need. Ask which external tools accept their output, and ask them to name one. A provider who has run that test will answer immediately and tell you what the tool returned. A provider who has not will explain instead why their own validator is sufficient, and that answer is the one the question exists to draw out.
If you are checking a file against a token, supply the deposited work itself rather than the certificate. The token carries the fingerprint of the original file. Anything else produces a mismatch that says nothing about the evidence.
The limits deserve stating plainly, because a claim that overreaches gets discounted entirely. What this establishes is that a date and a fingerprint survive contact with software nobody involved controls. It says nothing about who created the deposited work, whether they owned it, or whether it is protectable. A timestamp answers when, not who, and anyone offering it as proof of authorship is overselling the record.
Recognition is also asymmetric after Brexit, and worth understanding before relying on a certificate across borders. The point affects which provider a business should choose as much as how a certificate is later read. The United Kingdom recognises qualified trust service providers established in the EU. The EU does not extend equivalent recognition to providers registered in the UK.
There is a wider point about how this category should be assessed. Providers compete on the strength of their cryptography, and the cryptography is rarely the weak part. What separates a record that gets relied upon from one that gets set aside is whether the person on the receiving end can complete the check using whatever tools and patience they bring.
Two questions, two answers. Our certificates hold up in software we did not write: the qualified timestamp was confirmed as qualified against a register neither company maintains. And a validator built for raw tokens will handle a real certificate only after the recipient does work that most recipients will not do, and will then report on whichever single token they happened to extract.
A verification claim is worth what it is worth in somebody else's software. Ours was tested there and confirmed. The exercise is repeatable by anyone holding a certificate, and no provider's claim deserves acceptance until somebody has run the exercise.
This post provides general information about the verification of cryptographic evidence. It is not legal advice. For advice on a specific matter, consult a qualified lawyer in the relevant jurisdiction.
Related Reading
EU Trusted List Browser — European Commission
Independent Verification: What Can Be Checked, and How
eIDAS Qualified Timestamps vs Free Timestamps: What the Difference Means for Evidence
James Snell is the founder of Provlyn, a platform providing cryptographic prior proof of IP ownership. provlyn.com