A fiduciary in Zug opens a client folder from 2026: a signed share purchase agreement and the certificate that came with it. It is 2036, the other side wants proof that the agreement existed in this exact form before a disputed board resolution, and the certificate that signed the PDF ran out years ago. Whether it still verifies depends on what was put inside it on the day it was sealed.
Why a signature can stop verifying
A cryptographic signature is checked against a certificate, and certificates have an end date. Once the signing certificate has expired, a PDF reader that has to fetch the certificate chain and its revocation status from the internet may find that those services no longer answer. The signature was valid when it was made. The material needed to prove that is what has gone.
A second, slower problem sits behind it. Over a very long period a cryptographic algorithm can age, and a signature made with an aged algorithm is easier to challenge than it was when fresh.
Long-term validation answers both problems in advance, by packing the evidence into the document while it is still available.
The four levels in the standard
The European standard for PDF signatures, ETSI EN 319 142-1, sets out four baseline levels in clause 6.
B-B is the signature itself, with the attributes signed at the moment of generation.
B-T adds a trusted token proving that the signature existed at a certain date and time.
B-LT adds all the material required for validating the signature into the document itself: the certificates and the revocation information. Ten years on, nobody has to fetch anything from a server that may have been switched off.
B-LTA adds further electronic time-stamps that allow validation long after generation. The standard's notes say the B-LT and B-LTA levels are appropriate where validity must be preserved after the certificate has expired or been revoked, or after the algorithm has become obsolete, and that B-LTA can help validate a signature beyond weakness of the algorithms used or the expiry of the validation data.
Put plainly: B-LT keeps the evidence with the file. B-LTA keeps re-stamping the evidence so that the evidence itself does not age out.
What a sealed document carries today
This is what Swiss Trust Layer produces, read from the signing code rather than from a brochure.
When you seal a folder, a cryptographic fingerprint of each document is computed, and that fingerprint, not the file, is sent to Swisscom Trust Services, the qualified trust service provider. Swisscom signs it with a key that never leaves its hardware. The signature already contains an RFC 3161 timestamp from Swisscom, and it is embedded back into the PDF. The original file is not altered.
After signing, the certificates and the revocation information needed to validate the signature are embedded into the PDF's document security store. A PDF reader shows the signature as LTV-enabled. In the terms of the standard, that corresponds to the B-LT level.
The product does not add a separate archive time-stamp on top, so it is not B-LTA today. What that means in practice: the expiry of the signing certificate is covered, because the proof that it was valid at signing time travels inside the file. The slow aging of cryptographic algorithms over very long periods is what archive time-stamps exist for, and the seal on its own does not address it. The checklist below shows how to put a fresh dated proof on the same file yourself.
What the timestamp proves
A qualified timestamp proves that the exact file existed at that moment and has not changed since. It does not prove who wrote the file. It says nothing about whether the contents are true, or about who owns the rights. Under Article 41(2) of the eIDAS Regulation, a qualified electronic time stamp enjoys the presumption of the accuracy of the date and time it indicates and of the integrity of the data to which that date and time are bound. Article 41(1) adds that a time stamp cannot be denied legal effect and admissibility as evidence solely because it is electronic or not qualified.
The ten-year checklist
None of this works if the file itself is lost or changed. A fingerprint matches the exact bytes and nothing else.
- Keep the sealed PDF and its certificate unchanged, in two places. Not a re-saved copy, and not a version with a comment added.
- Check it once a year, and after any migration. Upload the sealed PDF to the public validator. It takes a signed PDF without an account, checks the signature chain, the issuing certificate authority, certificate expiry and timestamp integrity, and tells you whether the content was modified after signing. It does not store the document. For Swiss business records, the Business Records Ordinance (GeBüV) already asks in Article 10 that stored media be checked regularly for integrity and readability, and that any migration be logged. A yearly validator run is a simple way to produce that log entry.
- Write a note on each version; the portal lets you attach one to every version. A decade later, "countersigned copy, sealed before the 2026 general meeting" is worth more than a file name.
- When you need a fresh dated proof, seal a copy again as a new version. The new version gets a new timestamp from that day and its own certificate. The old timestamp stays valid as it was, and nothing about an issued version is rewritten.
One step this week
Pick the one document you would least like to explain in 2036, maybe a share purchase agreement or a manuscript, and run it through the validator today. If it was never sealed, seal it now. A timestamp cannot be added backwards, and a seal from this week is the oldest date you will ever be able to show for it.
Seal your first document on Swiss Trust Layer or read the full mechanism on how it works.
