Signed COAs: how a digital signature shows a peptide report was not edited

What a signed COA is

A signed COA is a lab report whose data carries a digital signature. The lab makes the signature with a private key that never leaves its control. Anyone can check the signature with the lab’s public key, which the lab publishes. If one character of the signed data changes, the check fails.

That gives buyers something a PDF alone cannot: a way to confirm the report without trusting the seller who posted it, and without trusting the page it was posted on. It adds a layer on top of a normal lab lookup, and it is still rare. Our guide on how to verify a peptide COA covers the lookup itself.

Why a PDF on its own proves little

A PDF can be edited in minutes. Numbers can be retyped, a lot number changed, a logo pasted in. An image file is easier still. Even a lab-hosted copy proves only what the lab’s server shows today. If the lab changes the file in place, the old version is gone.

The market reflects this. In HK Analytical’s September 2026 review of public COAs from 25 labs and one rating site’s certificate wrapper (1 to 6 COAs per lab):

• none offered a public-key signature that anyone could check (two had partial schemes);
• 7 showed records edited or re-rendered in place, with no visible version number;
• only 1 showed a public change history.

A signed record makes silent edits visible. It does not stop anyone from making a fake. It makes the fake fail a check that any buyer can run. The other warning signs are in our guide to fake peptide COAs.

How a digital signature works, in plain words

A signature scheme uses a pair of keys made together:

• The private key stays with the lab. It is used to sign.
• The public key is published. It is used to check.

Signing takes the report’s data and the private key and produces a short code, the signature. Checking takes the data, the signature and the public key and answers yes or no. Without the private key, nobody can produce a signature that checks out, even with many signed reports to study.

Think of a wax seal that anyone can test but only one person can press. The public key is the pattern everyone knows. The private key is the stamp.

Ed25519

Ed25519 is one widely used signature scheme. It is defined in RFC 8032 and included in NIST’s Digital Signature Standard, FIPS 186-5 (2023). Its public keys are 32 bytes and its signatures are 64 bytes, short enough to print on a page or carry in a web address. It is built into common software, including Node.js and the Web Crypto interface of many current browsers.

Why a lab signs a canonical record, not the look of the page

A report can be shown many ways: a PDF, a web page, a phone screen. Signing the look of one of them would tie the signature to fonts and layout. A lab signs the data instead: every field of the report, in one fixed form called a canonical record.

“Canonical” means there is exactly one way to write the record down. The JSON Canonicalization Scheme (RFC 8785) sets rules for this: key order, spacing and number format are all fixed. The same data always gives the same bytes. The same bytes always give the same SHA-256 fingerprint and the same signature check.

What goes into the record matters as much as the signature. A good record holds the results as printed, the methods, the dates, the sample description, and the fingerprints of attachments such as chromatograms and photos. Anything inside the record is protected. Anything outside it, such as a seller’s caption, is not.

Where the public key comes from

A signature is only as trustworthy as the public key used to check it. If a forger can hand you a key, the forger can sign anything. So the key must come from the lab’s own website, through an address you typed yourself.

Many web standards use a fixed folder called /.well-known/ for files like this. A key file should list each key with an ID, a status such as active or retired, and the dates it may sign. When a lab changes keys, old reports should still check against the old key, and a compromised key should be marked revoked with a date.

What a signature proves, and what it does not

A valid signature proves	A valid signature does not prove
The record was signed with the lab’s private key	That the measurements are right
Not one byte of the record changed since signing	That the evidence supports the result
Which key signed it, and that key’s status	That your vial came from the batch tested
Which version of the report you hold	When the record was signed, unless a timestamp or public log backs the date

The last row needs a word. A signed date says when the lab says it signed. Proving the time independently takes an outside timestamp (RFC 3161) or an append-only public log of record fingerprints, the pattern Certificate Transparency uses (RFC 9162).

Custody before testing is a separate question too. A signature covers the record from the moment of issue. How the sample reached the lab is shown by the custody record and the lab’s photo of the vial on arrival. Our sample custody form shows what that record holds.

Signature, hash, seal or blockchain claim: how they compare

Method	Who can check it	What it shows	Weak point
File hash (SHA-256) on the lab’s site	Anyone	The file matches the lab’s stored copy	You trust the lab’s stored value
HMAC “seal”	Only the holder of the secret key	The data matches what the operator sealed	The operator can re-seal edited data
“Blockchain anchored” claim	Anyone, if a hash and transaction are given	A fingerprint existed at a point in time	Proves nothing without a checkable hash and transaction
Public-key signature	Anyone with the public key	Who signed, and that nothing changed	Depends on the lab keeping its private key safe

A hash and a signature work well together. The hash proves that the PDF you hold is the PDF the lab issued. The signature proves who issued the data and that it was not changed.

Signed records and signed PDFs

PDF readers can show their own signature panel. That uses a different standard, PAdES (ETSI EN 319 142-1), with certificates that the reader software trusts. A PAdES seal and a signed data record solve related problems. A signed record can be checked by anyone with a public key and a few lines of code. Re-saving or printing a PDF changes its fingerprint either way, so always ask for the original file.

Corrections: why a signed report is never edited

Signing only works if issued reports stay as issued. ISO/IEC 17025 clause 7.8.8 says an amendment after issue must be a further document, clearly marked, and a full replacement report needs a new ID that refers to the one it replaces. A signed system follows that rule by design. A correction is a new signed version. The old version stays on record, marked as replaced, with the reason.

If you find a report that a lab has changed in place, with no version and no reason, its signature (if it had one) would no longer check. That is the point.

How HK Analytical signs its reports

Each HK Analytical report is a signed record: an Ed25519 signature over the canonical record. Our public keys are at hkanalytical.com/.well-known/hk-coa-keys.json, and the verify page lists each key’s ID, fingerprint and status. One key is marked demo. It signs only our example reports, and a report signed with it is never shown as valid.

To check a report without our website, download its signed record and our key file, then run the short script printed on /verify. It reports whether the signature is valid and prints the PDF fingerprint we signed. The signed record also states how the client is related to HK Analytical, so that statement cannot be cropped off. Reports are never edited after issue: a change makes a new version and the old one is marked superseded. We do not hold ISO/IEC 17025 accreditation. See our quality page for the rest.