TL;DR: A certificate verification system is the part of an issuer's setup that lets anyone confirm a certificate without contacting the issuer. It ties every certificate to a record the issuer controls, answers a QR scan or a link in seconds, and shows whether the certificate is valid, expired or revoked. Blockchain anchoring adds a record outside the issuer's own servers, so the answer survives a new system or a closed vendor. For a company, a school or a public authority, setting one up comes down to a template, an issuing route and a domain.
A certificate verification system is the set of records and checks that lets a stranger confirm three things about a certificate: that it came from the organisation named on it, that it was issued to the person holding it, and that nobody has changed it since. The issuer runs the system. The employer, the client or the inspector uses it, usually without knowing it is there.
The phrase covers two different jobs. Someone holding one certificate wants to check it, and that need is met by a lookup tool such as TRUE Verify or by TRUE's guide on how to check if a certificate is fake or real. This article is about the other side. A company, a school or a public authority issues hundreds or thousands of certificates a year and has to make every one of them checkable by people it will never meet, for as long as the certificate matters.
Every certificate verification system has three parts, whatever technology sits underneath. A record of what was issued. A way for the reader to reach that record from the certificate, usually a link or a QR code. And an answer the holder of the certificate cannot write themselves.
An issuer needs a certificate verification system because most people who rely on its certificates never check them, and the few who do end up in the issuer's inbox. A system that answers on its own closes both gaps. Checking becomes a scan, and nobody at the issuer has to dig out a record for a course that ended six years ago.
A YouGov survey of 526 HR decision makers for Hedd, the UK's degree verification service, carried out in April 2025 and reported by Prospects Luminate in November 2025, found that 45 percent of large employers had uncovered false qualification claims. Only 52 percent of large businesses verified all academic credentials, and the share fell to 37 percent of medium and 29 percent of small organisations. Cifas, the UK fraud prevention service, reported on 3 February 2025 that 18 percent of UK people had lied on a CV or job application in the past year, or knew someone who had.
Looking at the paper no longer settles it. The same Prospects Luminate article says that “traditional checks like visual inspection of certificates are no longer enough.” A forged certificate carries a real issuer's name, because the real name is what the reader trusts. Only that issuer can disprove it, and a certificate verification system lets the issuer do so without being asked.
A certificate verification system must tie each certificate to the issuer's own record, answer anyone without an account, show the current status, keep working for as long as the certificate is used, and reveal no more personal data than the certificate already does. A system that misses one of these leaves the reader with a page that looks official and proves nothing.
The sixth point is the one a database lookup cannot meet on its own. A lookup in the issuer's own database answers only while that database runs, under that address, with that vendor under contract. The web's own standards body writes the other requirements into its definitions. The W3C Verifiable Credentials Data Model 2.0, a W3C Recommendation since 15 May 2025, describes a verifiable credential as “a set of tamper-evident claims and metadata that cryptographically prove who issued it”, and defines a status property for discovering whether a credential “is suspended or revoked”.
A certificate verification system using blockchain writes a cryptographic fingerprint of each certificate to a public blockchain at the moment of issue. At every check, the system computes the fingerprint again and compares it with the one on record. A match shows that the certificate is the one the issuer recorded and that nothing in it has changed.
The certificate itself stays off the chain. Only the fingerprint, a hash, goes there, and a hash cannot be turned back into a name or a course. That answers most of the data protection question before anyone asks it. The mechanics are explained step by step in how blockchain certificates work, and the reader's side of the check in blockchain certificate verification.
For the issuer, the blockchain adds what a database cannot: a record nobody at the issuer can edit afterwards, kept on a network no single organisation owns. MIT tested the idea in 2017, when 111 graduates could receive their diplomas digitally alongside the paper version. MIT News wrote on 17 October 2017 that the verification portal “essentially uses the blockchain as a notary, locating the transaction ID (which identifies when the digital record was added to the blockchain), verifying the keys, and confirming that nothing has been altered since the record was added.”
Chris Jagers, co-founder and CEO of Learning Machine, the company that built the pilot with MIT's Registrar's Office, named the property an issuer cares about most: “MIT has issued official records in a format that can exist even if the institution goes away, even if we go away as a vendor.”
The blockchain does not vouch for the course. The issuer still does that, as with paper. What the record proves is who recorded the certificate, when, and that it is unchanged. Status sits on top of the record: a revoked certificate keeps its original entry, and the answer the reader sees changes to revoked.
Most issuers combine methods rather than pick one. A database lookup gives live status, a digital signature or an eIDAS seal gives legal weight inside the EU, and blockchain anchoring gives a record that survives the issuer's own systems. The table shows what each method proves on its own and where it stops.
| Method | What the reader checks | What it proves | Where it stops |
|---|---|---|---|
| Lookup in the issuer's database | A page or a search on the issuer's website | What the issuer's record says today | Ends when the database, the address or the vendor changes, and anyone with access can edit the record |
| Digital signature or eIDAS seal on a PDF | The signature inside the file | Who signed the file, and that it is unchanged | The file carries no live status, so a revoked certificate still shows a valid signature |
| Blockchain anchoring | The certificate's fingerprint against a public record | Who recorded the certificate, when, and that it is unchanged | Says nothing about status unless the system shows it next to the record |
| W3C Verifiable Credential | A signed credential, often held in a wallet | The issuer's signature on the claims inside | The reader needs software that reads the format |
The legal question is separate from the technical one. A blockchain record has no eIDAS status by itself, and an issuer that needs one adds an eIDAS seal or signature, as TRUE sets out in is a blockchain timestamp legally valid under eIDAS?. The signature standard is covered in TRUE's guide to W3C Verifiable Credentials. TRUE Verify rates the combination: a document with a blockchain record and an eIDAS signature reaches Signed + Secured, the highest of its five security levels.
Compare how a stranger verifies a certificate, what happens to verification if you leave the vendor, whose domain the answer appears on, how a change of status reaches the reader, and how certificates get into the system from the tools you already run. Price and design matter too, and they come after these five.
A vendor that answers the second question with a contract clause rather than a mechanism has answered it. TRUE's longer evaluation framework, with weighted criteria and a five week timeline, is in how to choose a digital credential platform, and five providers with published prices are compared in TRUE Original and the best digital credential platforms 2026.
You set up a certificate verification system by starting with the certificates people check most, deciding what each record and status holds, choosing the domain the answers open on, and connecting issuing to the system where the course or the decision already lives. Then you tell the people who check where to look.
The decisions in steps two and six take the longest. The technical steps are short. With TRUE Original a custom domain is one CNAME record, and most organisations have it live the same day.
TRUE Original issues each certificate as an original published online, on the issuer's own domain if the issuer wants it there, and anchors a fingerprint of it on a public blockchain at the moment of issue. Anyone can check it by scanning the QR code, opening the link or pasting it into TRUE Verify, free and without an account.
TRUE Original is blockchain agnostic and uses several public blockchains, among them Ethereum and Polygon, and a customer who wants a specific chain can have it. No personal data goes on the chain. Expiry and revocation show in the answer from the moment the issuer sets them, and a revoked certificate still opens and shows its status rather than a dead page. Certificates go out from the TRUE dashboard, by structured email, through a REST API with five endpoints, or from integrations such as Canvas LMS, Moodle, Learnster and Salesforce.
TRUE Original has issued over 900 000 documents for more than 200 issuers in over 15 countries, and has saved its customers more than 100 000 hours across issuing, handling and verification. Karolinska Institutet issues course certificates straight from Canvas. SSF Stöldskyddsföreningen issues blockchain secured certificates that anyone can verify without contacting SSF. Bolagsverket, the Swedish Companies Registration Office, built its Proof of Business concept with TRUE.
Hedd has carried out over 1.75 million degree verifications for employers since 2011. Every one of them was a certificate that could not answer for itself.
A certificate verification system is the set of records and checks that lets anyone confirm a certificate came from the organisation named on it, was issued to the person holding it and has not been changed. The issuer runs it, and the reader reaches it through a link or a QR code on the certificate.
It is a system that writes a cryptographic fingerprint of each certificate to a public blockchain when the certificate is issued, and compares the certificate with that fingerprint at every check. A match proves who recorded the certificate and that nothing in it has changed, without contacting the issuer.
No. Only a hash of the certificate is written to the blockchain, and a hash cannot be turned back into a name or a course. With TRUE Original no personal data is stored on the chain.
With a lookup in a database, verification ends when the database or the address goes. With blockchain anchoring the record stays on a public network no single organisation owns, so the certificate can still be checked against it.
The technical part is short: with TRUE Original a custom domain is one DNS record, and most organisations have it live the same day. The decisions take longer: which certificates come first, what each record holds, and when a certificate expires or is revoked.
Every organisation we work with started with the same question. Give us thirty minutes and we will show you what your own documents would be worth.
Book a callNot sure where to start? Let us help!
Trusted by leading organisations worldwide
