Most systems treat a QR code as a short URL with better ergonomics. The habit is harmless on a poster. It fails the moment a scan releases something of value: a payout, a warranty claim, an authenticity verdict, a recall instruction. At that point the code is an assertion, and assertions need a way to be checked.
Signing is the standard answer, and it is a good one inside its limits. This piece is written for architects deciding where a signature belongs in a scan pipeline: what it proves, and which controls must carry the rest.
What a signature proves
Start with the mechanism. The issuer serialises a payload in a canonical form, hashes it, and signs the hash with a private key. At scan time the verifier recomputes the hash and checks the signature against the issuer's public key. A passing check establishes two facts: the payload came from the key holder, and nobody has altered a byte of it since signing.
Canonicalisation deserves more respect than it usually gets. Two systems that serialise the same fields in different orders produce different hashes, and a verification failure caused by whitespace looks identical to one caused by fraud. Fix field ordering, fix text encoding, and test the round trip long before the first label prints.
Scheme choice is a size question as much as a security question. RSA is mature and simple to verify, and its signatures are large. Elliptic-curve schemes such as ECDSA produce much smaller signatures at comparable strength. On a printed code that difference is physical: more payload bytes mean denser modules, and denser modules mean a code that is harder to print cleanly and harder to read from a curved or scuffed label. High-volume label systems drift toward elliptic curves for this reason alone. These are properties of the techniques themselves, and they hold regardless of any single vendor's implementation choices.
The photocopy problem
Here is the objection every review board should raise: a signature travels with the image. Photograph a genuine label and the copy carries the same payload and the same valid signature. Verify it ten thousand times and it passes ten thousand times. Copying alters no bytes, so integrity checks stay green.
This is a property of the mathematics, and no key ceremony repairs it. A signature binds bytes to an issuer. It holds no memory of how many times those bytes have been printed, photographed or resold. A vendor claiming that a signature alone makes a printed code uncopyable is describing a product that cannot exist.
Where the weight sits
Picture the counterfeit that survives the previous section: a faithful photograph of a genuine label, reprinted at scale. Defeating it requires something the printed image cannot carry, which is memory. In secQR the printed image carries no readable secret; each code resolves only against a controlled record that holds the unit's identity, state and history. Every scan consults that record in real time, and the record remembers what it has seen.
That memory is what catches the copy. The original and its photograph resolve to the same record, so the moment a supposedly unique identity surfaces again, the duplicate is flagged on its first scan and the evidence is logged: location, time, device. The counterfeiter's own distribution effort generates the alert.
Signing still earns its keep here, in a role architects sometimes miss. Without centrally issued, verifiable identities, an attacker can fabricate fresh codes that never collide with a genuine record. With them, fabrication fails at verification, so the only move left is copying genuine codes. Copying funnels every fake into the same record as the original, and collisions are precisely what the record is built to notice.
A signature turns forgers into photocopiers, and photocopiers walk straight into duplicate detection.
Keys, rotation and the offline trade-off
Standard key hygiene applies with full force. Keep private keys in hardened storage, rotate them on a schedule, and give each issuer its own key pair so one compromise never taints another product line. None of this is exotic. It does need deciding before launch, because a key baked into millions of labels already in the field is expensive to regret.
One genuine trade-off deserves a plain statement. Embedding a public key in a scanning app lets a checkpoint verify signatures with no network, which matters at a border post or inside an air-gapped facility. The cost is real: an offline verifier cannot consult the record, so it sees no revocations and no duplicates. We treat offline verification as a triage layer and require online resolution before anything of value is released.
Three questions for the design review
Signature schemes fail in review documents far less often than architectures fail around them. Three questions expose most weak designs.
- Who holds the record a code resolves against. Whoever holds it controls the truth of every scan.
- What happens on the second scan of a one-per-unit identity. The answer shows whether duplication is detected or merely stored.
- What a fully decoded printed image hands an attacker. The right answer is nothing usable without the record.
A signature belongs in the design. Let it prove origin and integrity, and let the controlled record do the work that mathematics printed on paper was never going to do.