An organisation that issues certificates has a problem it usually does not see until someone else finds it. The certificate leaves the building as a PDF, and from that moment the issuer has no control over what happens to it. It can be edited, duplicated, backdated, or invented outright by someone who never attended anything.
The awkward part is not that forgery is possible. It is that the person receiving the certificate, an employer, a regulator, a client, usually has no way to check. They look at a logo, a signature image, and a date, and they decide whether it feels genuine. That is not verification. It is an impression.
Why a PDF certificate proves very little
A standard PDF certificate carries no evidence of its own origin. The visual elements that make it look official, the seal graphic, the scanned signature, the reference number, are all just pixels. Any of them can be reproduced by someone with basic design software and an afternoon.
Three specific weaknesses follow from that:
- The content can be altered. A name, a grade, or a completion date can be changed without leaving a trace in the file.
- The date can be moved. Nothing in an ordinary PDF establishes when it was actually created, so a certificate can appear older or newer than it is.
- The issuer cannot be confirmed. There is no cryptographic link back to the organisation that supposedly issued it.
Registry lookups help, but only partly. They require the verifier to know your registry exists, to find it, and to trust it. They also break when the issuing organisation restructures, changes systems, or stops maintaining the lookup page.
What makes a certificate verifiable
A verifiable certificate carries its own proof. Instead of asking the recipient to trust the appearance of the document, it lets any third party confirm three things independently, without contacting the issuer at all.
Integrity. A cryptographic hash of the certificate is created at issuance. If a single character changes afterwards, the hash no longer matches and verification fails. This is what turns tampering from something invisible into something detectable.
Time. A qualified timestamp records when the certificate existed, issued by an accredited timestamp authority rather than by the issuer. Under eIDAS Regulation (EU) No 910/2014, a qualified timestamp carries a legal presumption as to the accuracy of the date and time it records. That presumption is the difference between claiming a date and being able to rely on it.
Origin. A qualified electronic seal binds the certificate to the issuing organisation itself rather than to an individual employee. Seals are the organisational counterpart to signatures, and they survive staff changes, which matters for a body that issues certificates for decades.
The legal weight behind it
In Switzerland, electronic signatures and seals are governed by ZertES (SR 943.03), which sets out the requirements for qualified certificates and accredited providers. Where a qualified electronic signature is used, Article 14 paragraph 2bis of the Swiss Code of Obligations treats it as equivalent to a handwritten signature.
Within the EU, the equivalent framework is eIDAS, which gives qualified electronic signatures the same legal effect as handwritten signatures across member states and establishes the status of qualified seals and timestamps.
Separately, and often overlooked by certificate issuers, the underlying course material, assessment content, and curriculum are protected as original works under the Berne Convention. Protection arises automatically on creation, but proving that you held a specific version on a specific date is a separate evidential problem, and one that a sealed and timestamped record solves.
What this looks like in practice
For an organisation issuing qualifications, the change is smaller than it sounds. The certificate is generated as normal. Before it is sent, it is sealed and timestamped, which produces a file that carries its own verification data inside it. The recipient gets a document that looks familiar. The difference appears when someone checks it.
A verifier opens the file and confirms the seal, the timestamp, and the integrity of the contents. If the certificate has been altered in any way, that check fails immediately and visibly. No login, no registry, no phone call to your office.
This also removes an administrative burden most issuers carry quietly. Verification requests from employers and regulators stop landing in your inbox, because the person asking can answer the question themselves.
Where to start
Begin with the certificates that carry the most consequence if forged, usually those tied to regulated practice, safety, or professional standing. Those are the ones where a fake causes real harm and where a verifier is most likely to check.
From there, apply the same process to your standard issuance run. The technical work is the same whether you issue fifty certificates a year or fifty thousand, because the sealing step happens automatically at the point of generation.
You can verify any sealed document, including certificates issued by others, using the public validator at swisstrustlayer.com/validate. No account is required.
