Two numbers, two jobs
A serial number is for the issuer. It orders the register, answers a telephone call from a graduate and lets a registrar find the record in a file of ten thousand. It is read by people and typed by people, so it should be short, regular and readable aloud.
A verification code is for the reader of the certificate. It opens the public page that confirms the certificate exists, who it was granted to and whether it remains valid. Because it is the only thing that separates a genuine certificate from an invented one, it must not be possible to guess it from a neighbouring certificate.
Emitcert issues both. Each certificate receives a unique serial and a code that cannot be guessed, printed together with a QR code that leads to the verification page. The verification page accepts either the code or the full link.
Designing a serial
A serial worth keeping tells the issuer something and tells outsiders nothing. A common pattern is the year of issue, a hyphen and a running count, such as 2026-001, which also happens to be the form of the reference in the sample import file. The year helps archiving; the count helps finding.
- Keep it short enough to be read over the telephone.
- Use only letters, digits and hyphens, so that it survives being copied between systems.
- Never reuse a serial, including one belonging to a certificate that was withdrawn.
- Where several programmes issue under one institution, a short prefix per programme prevents collisions.
What to keep out of a serial
A serial that contains a national identity number, a date of birth or a full student number turns a printed, shared and photographed document into a personal-data leak. The W3C data model for verifiable credentials notes, about identifiers in general, that they increase correlatability and may harm privacy where pseudonymity matters. The same reasoning applies to a serial: it travels with the certificate wherever the certificate goes.
A student number is better stored in the separate reference field, which makes the certificate searchable by the issuer without printing the number for others to read.
Supplying your own, or letting one be minted
When a class is imported from a spreadsheet, the serial column may be left out and one is minted for each row. An institution that already numbers its diplomas in its own register supplies its own serial in that column; it must then be unique, and a duplicate is reported as a problem before anything is granted. Our guide to issuing certificates in bulk describes that check.
Why the serial is not the proof
A serial that runs 2026-001, 2026-002, 2026-003 is predictable by design. A reader who sees one can write the next. That is acceptable for a register, and unacceptable as proof, which is why verification rests on the code and on the issuer's signature rather than on the serial. See how to verify a diploma for the checks a reader performs, and certificate fraud for what a forger attempts.
A checklist
- Choose a pattern once and record it in the register's documentation.
- Exclude every personal identifier from it.
- Keep the student number in the reference field.
- Print the code and the QR code where a reader can see them without unfolding the document.
- Never reuse a serial, withdrawn or not.
Frequently asked questions
Can the serial be chosen by the institution?
Yes. It may be supplied in the import file or left out, in which case one is minted. It must be unique among the institution's certificates.
Is the serial enough to prove that a certificate is genuine?
No. A serial is a register entry and can be predicted. Proof rests on the verification code and the issuer's signature.
Should a student number be used as the serial?
It is better kept in the reference field. A printed serial is seen by everyone who sees the certificate, and a student number is personal data.
Sources
The factual statements on this page rest on the documents listed below. Legislation and services change; consult the current version before relying on any of them.
