A training certificate does one job: it tells a stranger that a specific person completed a specific course. The trouble starts when that stranger cannot check the claim without picking up the phone and calling your office.
Every training provider that issues certificates at any volume already knows this call. An HR department wants to confirm a hire completed the safety course listed on their CV. A client wants proof that the consultant they hired holds the certification the invoice references. A regulator wants to know the record is genuine before renewing a license. Each of those checks currently lands on your admin inbox, because a PDF with a logo and a signature image cannot answer the question on its own.
Why a PDF certificate is not proof
A PDF certificate looks finished the moment it is generated. It has a course name, a date, a signature, sometimes a seal graphic. None of that survives a determined edit. Any PDF editor can change a name, a grade, or a date in under a minute, and the result looks exactly as convincing as the original, because nothing in a standard PDF ties its content to a fixed, checkable value.
This is not a hypothetical risk. Certificate fraud shows up wherever certificates matter for employment or compliance, from safety training to professional accreditation. The fix is not a better looking template. A more elaborate seal graphic is still just an image, and an image can be copied onto a fake document as easily as a real one.
What "verifiable" actually requires
A certificate a recipient can check on their own, with no message to your office, needs four things working together.
A hash computed from the exact file, so that changing a single character changes the value and breaks the match. A timestamp issued by a party other than the training provider, so the date is not something you could have set yourself after the fact. A signature or seal tied to a verified identity at the point of issuance, not typed into a template. And a public verification page that checks all three and reports the result to anyone who opens the link, with no login and no account needed on their side.
Leave any one of these out and the certificate still looks complete, but it stops functioning as evidence the moment somebody actually tests it. A hash without an independent timestamp only proves a file exists, not when. A signature without a hash proves an identity signed something, not which exact document. The three only work as a set.
The legal ground under this
None of this is a private convention your organization invents on its own. Under eIDAS, a qualified timestamp issued by a Qualified Trust Service Provider carries a legal presumption as to the date and time it indicates and the integrity of the data it covers. That presumption is what lets a verification page state a date with confidence, rather than repeating a date typed into a form.
On the signature side, Swiss law gives a qualified electronic signature the same legal effect as a handwritten signature, under Article 14 paragraph 2bis of the Swiss Code of Obligations, provided the signature is qualified under the Federal Act on Electronic Signatures (ZertES). That effect depends on the identity behind the signature having already been verified by an accredited provider, at the point the certificate was issued, not on a name typed into a form field.
Why this needs to hold up wherever the certificate travels
A training provider rarely knows in advance where a certificate will end up. A student completes a course in Zurich and applies for a job in Singapore. A contractor's safety certification gets checked by a client in another country entirely. If verification depends on a phone call to an office in one time zone, in one language, during one set of business hours, the certificate is only as useful as your office hours allow.
A record built on a hash, an independent timestamp, and a verified signature is checkable data, and checkable data works the same way wherever somebody opens the link. That is a different property from a locally issued proof that only means something inside the system that produced it. The certificate should be globally valid on its own terms, not something that only stands up as long as the person checking it happens to be inside your own systems or your own country. Stated narrowly, because narrow is accurate: a verification page confirms the file, the date, and the signing identity match. It does not decide how a specific court or regulator weighs that evidence in a specific dispute, but the underlying record is the same, checkable the same way, regardless of which border the check happens to cross.
What this looks like in practice
A recipient opens a link on the certificate, on their phone or a browser, no account required. The page shows the course, the date, the recipient's name, and a status that confirms the file matches the sealed record exactly. If a single character in the certificate has been altered, the match fails and the page says so.
You can see the same mechanism live on any certificate sealed through the platform at the public verification page: paste in a certificate reference or open the link printed on the document, and the page confirms the file, the date, and the identity without any message to the issuing office.
For a training provider, the operational shift is straightforward. Certificates are generated as usual, then sealed: hashed, timestamped by a Qualified Trust Service Provider, and signed under a verified identity, before they go out. Each certificate carries a short verification link or QR code. Nobody on your side has to answer a verification email again, because the answer already lives on a page anyone can open.
Common half-measures that do not solve this
A few fixes look like they solve the problem and do not. A QR code that opens your homepage confirms that your organization exists, not that the specific certificate is genuine. A "verified" badge printed on the certificate itself is just another graphic, no different from the seal it sits next to, since a copied badge looks identical to a real one. A verification portal that requires the checker to create an account before seeing a result adds friction at exactly the point where the checker wants a fast, low effort answer, and many will simply give up and call your office anyway, which puts you back where you started.
A verification page also has to fail loudly when it should. If a certificate has been altered, the page needs to say so clearly, not stay silent or show a generic "not found." A system that only ever returns positive results has not been tested against the case that actually matters.
What this changes for admin load
The volume of "please confirm this certificate is genuine" requests scales with how many certificates you issue and how long ago they were issued. A five year old certificate from a student you barely remember still generates the same phone call as a certificate issued last week, because the verification burden has always sat with your office, not with the document.
Moving that burden onto a public verification page does not remove your responsibility to issue accurate certificates. It removes the repeated, manual step of confirming what should have been provable from the start. A regulator, an employer, or a client checks the link once and gets an answer immediately, at any hour, in any location, without waiting on a reply.
A short checklist before you call a certificate verifiable
Four questions decide whether a certificate you issue can actually be checked without contacting you: does it carry a hash tied to the exact file rather than a description of it; was the date set by a party other than your own organization; is the signature or seal tied to an identity verified before issuance, not typed into a template; and can a stranger open a link and get a confirmed answer with no account and no message to your office. A certificate that answers yes to all four is verifiable. A certificate that answers yes to one or two is a well designed document that still depends on your phone line.
If your organization issues training certificates and wants to see what a fully verifiable one looks like end to end, open the verification page and check a sealed certificate the same way a recipient's employer would.
