7 Step COSE_Sign1 Checklist for Developers Building Signed QR Codes

A digitally signed QR code is a QR symbol whose payload carries a cryptographic signature that proves integrity and who issued it. It enables offline verification when the verifier has the issuer’s trusted public key. The main trade off is straightforward: you get strong tamper detection and proof of origin without a live connection, but revocation and status checks are harder to guarantee offline.

TL;DR:

• Signed QR codes use compact COSE_Sign1 encoding for efficient size, with a focus on single-signer applications to optimize QR capacity.
• Verification relies on trusted public keys, obtained through certificates, key lists, thumbprint exchanges, or known URIs, with fail-closed policies for unknown keys or algorithms.
• Offline validation ensures data integrity and authenticity but limits real-time revocation or status checks, necessitating short validity periods and key rotation.
• Proper canonicalization, key protection, and matching QR version and error correction levels are critical for reliable encoding and verification.
• Durable infrastructure, like permanent signing systems, is essential to keep QR codes functional long-term, regardless of potential billing or hosting lapses.

Table of Contents

• What a digitally signed QR code actually proves
• Standards and formats worth building on
• A practical checklist from schema to verification
• Encoding and size trade-offs for QR symbols
• How verifiers should establish trust in a public key
• Limitations, threats and how to mitigate them
• A minimal create, sign, encode, verify sequence
• Why durable infrastructure matters as much as the cryptography
• Where QRlytics fits into durable, verifiable QR deployments
• Standards and guidance worth reading in full
• Sources
• FAQ

What a digitally signed QR code actually proves

A signed QR code bundles three things: the payload (the data you care about), the signature (proof that the payload has not changed since signing), and metadata such as a key identifier, issued-at timestamp, expiry and a nonce. Each element does a specific job, and conflating them is where most implementations go wrong.

• Integrity: the payload has not been altered since signing, confirmed mathematically by algorithms approved in NIST FIPS 186-5, including ECDSA and HashEdDSA.
• Authenticity: the signature ties the payload to a specific private key, but binding that key to a real-world issuer needs separate assurance, not just cryptography.
• Non-repudiation: the signer cannot plausibly deny having signed the payload, provided the private key was properly protected.

This is a different animal from a URL-based marketing QR code, which simply redirects a scanner to a webpage. A signed payload can be verified without contacting any server at all.

Standards and formats worth building on

For QR-sized payloads, compact binary encoding beats verbose JSON almost every time. COSE (CBOR Object Signing and Encryption) is the standards-based route most implementers should default to.

• COSE_Sign1, defined in RFC 9052, is built for single-signer objects and uses a deterministic Sig_structure for signing and verification, which keeps encoding unambiguous.
• JWS/JSON works fine for web APIs but its base64-encoded JSON overhead often pushes payloads past what a scannable QR code can hold.
• ISO/IEC 20248 offers a barcode-specific digital signature scheme worth knowing, particularly in supply chain and product authentication contexts.
• Algorithm choice should follow NIST FIPS 186-5, which specifies approved digital signature algorithms and states plainly that they detect unauthorised modification and authenticate the signatory.

Key identification matters as much as the signature itself. RFC 9679 defines COSE key thumbprints, a deterministic way to compute a stable identifier for a public key so a verifier can select the correct one even across key rotations.

A practical checklist from schema to verification

Turning the standards above into working code means following a fairly fixed sequence, and skipping a step tends to surface as a confusing verification failure much later.

1. Define a versioned schema with a minimal field set: issuer, unique id, issued-at, expiry and a nonce.
2. Canonicalise the bytes before signing, using the Sig_structure that COSE defines, so the exact same bytes get verified later.
3. Include a key identifier or thumbprint in the protected header so verifiers know which public key to fetch.
4. Protect the signing private key in a hardware security module or a tightly scoped key management service, never in application code.
5. Publish the public key via a certificate chain, a signed key list or a well-known thumbprint endpoint.
6. Encode as COSE_Sign1, test against your target QR version and error-correction level, and confirm the encoded object actually fits.
7. On verification, check the signature, issuer binding, timestamps, nonce and algorithm allow-list, and fail closed on anything malformed or unrecognised.

Pro Tip: Treat an unknown key identifier the same way you treat an invalid signature: reject it. A verifier that silently falls back to “trust anyway” defeats the entire point of signing.

Encoding and size trade-offs for QR symbols

QR capacity is finite, and error correction eats into it fast. Higher error-correction levels reduce the amount of binary data a QR code can hold, which affects version and size trade-offs. Every byte your signed object saves is a byte of scanning reliability gained.

• Minimise CBOR fields: use short integer keys instead of descriptive string labels wherever the schema allows it.
• Use COSE_Sign1 over general COSE_Sign when there is only one signer, since it drops unnecessary structure.
• Choose a self-contained signed payload when offline verification is the requirement, accepting that revocation checks will be limited.
• Choose a URL plus JWS approach when you need live revocation, analytics or frequently updated status, accepting the loss of offline capability.
• Test the actual encoded bytes against your chosen QR version and ECC level before committing to a schema, rather than estimating from field counts alone.

How verifiers should establish trust in a public key

A valid signature only proves that a particular private key signed a particular payload. It says nothing about whether that key belongs to who it claims to. NIST SP 800-89 draws this distinction clearly, recommending separate procedures for confirming domain parameter validity, public key validity and proof of private key possession, on top of the signature check itself.

Verifiers typically obtain trusted keys through one of a few patterns:

• A certificate signed by a recognised certificate authority, chaining back to a root the verifier already trusts.
• A signed key list published and periodically refreshed by the issuer.
• An out-of-band thumbprint exchange, comparing a key’s computed thumbprint against a value shared through a separate trusted channel.
• A well-known URI hosted on the issuer’s own verified domain.

For revocation and status, offline signed objects lean on short validity windows rather than live checks: keep expiry tight, rotate keys regularly, and where connectivity allows, add an online status check or transparency receipts as described in RFC 9942 for auditability.

Pro Tip: When an algorithm or key identifier falls outside your allow-list, reject the object outright rather than attempting a best-effort verification. Fail closed, always.

Limitations, threats and how to mitigate them

Signing a QR payload does not make the whole system tamper-proof, and the weak points tend to sit outside the cryptography itself.

• Counterfeit verification pages are a real risk: the GS1 digital signatures guideline warns that a page linked from the scanned code can itself be fake, so verification logic should run independently of anything the QR code points to.
• Replay attacks are mitigated with a nonce, a short expiry window and issued-at checks, so a captured valid signature cannot be reused indefinitely.
• Binding to a physical object matters for anti-counterfeit use cases: pair the signed payload’s unique id with a separate physical security mark, such as UV ink, rather than relying on the signature alone.
• Canonicalisation and key rotation are the quiet failure modes: a serialiser that reorders fields, or a verifier still checking against a retired key, breaks verification even when nothing malicious happened.

A minimal create, sign, encode, verify sequence

A working proof of concept follows a short, repeatable path.

1. Assemble the canonical payload, including the key identifier or thumbprint in the protected header.
2. Sign it as a COSE_Sign1 object, using a hedged signing pattern where the algorithm supports one, to reduce the risk of nonce reuse.
3. Encode the result for QR embedding, typically base64url or base45, whichever your target scanner ecosystem expects.
4. On the scanning side, decode the QR, recreate the Sig_structure, fetch the public key by its identifier, and run verification, checking expiry and nonce as part of the same pass.
5. Test against edge cases early: a malformed signature, an unknown key identifier, an expired timestamp and a mid-rotation key change all deserve their own test vector.

For teams thinking beyond the cryptography to the printed code’s whole lifecycle, our QR code best practices guide covers versioned schemas and expiry planning in more depth, and our secure QR solutions checklist walks through fail-closed operational patterns for teams shipping this at scale.

Why durable infrastructure matters as much as the cryptography

A signed QR code is only as trustworthy as the systems around it. A perfectly designed COSE_Sign1 payload does nothing for you if the printed code itself expires or the redirect behind it goes dark because a subscription lapsed. Independent verification, well-managed key distribution, and QR codes that keep working for the life of a print run all matter together, not separately. Our explainer on QR identity verification looks at how self-contained and URL-based approaches differ in practice.

— The.

Where QRlytics fits into durable, verifiable QR deployments

Cryptographic signing solves data integrity. Keeping the printed code itself alive for the life of your campaign is a separate problem, and it is the one QRlytics was built to solve. Codes created during an active QRlytics subscription keep working permanently, even if billing lapses later, which matters for product authentication labels, certificates and long-run physical deployments where a broken redirect means a costly reprint.

• Dynamic QR codes let you update the destination URL without reprinting anything, useful when a signed payload’s endpoint changes.
• Real-time scan analytics with GDPR-compliant tracking give you visibility into where and how often codes get scanned.
• API access on paid plans supports programmatic generation for teams building signing and encoding into their own pipeline.

Start on the Free plan with no credit card required, or explore the dynamic QR code generator to see how lifecycle management works before committing to a paid tier.

Standards and guidance worth reading in full

For implementers who want the primary sources rather than a summary: NIST FIPS 186-5 defines approved signature algorithms, RFC 9052 and RFC 9679 cover COSE structures and key thumbprints, and the GS1 digital signatures guideline alongside NIST SP 800-89 address real-world assurance procedures beyond the cryptography itself. Teams weighing physical binding methods against QR authentication may also find it useful to read how authenticity in branding builds trust, and hardware options like NFC cards and physical display stands for pairing a signed code with a tangible security mark.

Sources

• NIST releases FIPS 186-5 and SP 800-186
• RFC 9052 - CBOR Object Signing and Encryption (COSE): Structures and Process
• NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications
• GS1 Digital Signatures Technical Implementation Guideline

FAQ

What is a QR code digital signature?

A QR code digital signature is cryptographic proof, embedded in the QR payload, that the data has not been altered and identifies which private key signed it. Verification uses the corresponding public key, following algorithms such as those in NIST FIPS 186-5.

What is the FBI warning about QR codes?

Public warnings about QR codes generally centre on scammers replacing legitimate codes with malicious ones that redirect to phishing sites or fraudulent payment pages. This risk applies to ordinary URL-based QR codes rather than properly implemented signed payloads, which are designed to resist tampering.

Why does my scanner say a digital signature is invalid?

An invalid signature result usually means the payload bytes were altered, the wrong public key was used for verification, or the signing and verifying sides serialised the data differently. Canonicalisation mismatches, expired keys and unrecognised key identifiers are the most common causes, as outlined in RFC 9052.

Is it legal to display a QR code on a billboard?

Yes, QR codes on billboards and other outdoor advertising are legal in most jurisdictions, since they function as a graphic linking to content, much like a printed web address. Local advertising and signage regulations that apply to the billboard itself still apply regardless of the QR code.

How do I keep a signed QR code working for years without reprinting?

Signing addresses data integrity, but the printed code’s destination or hosting also needs to stay live for the life of the campaign. Platforms like QRlytics guarantee that codes created during an active subscription keep functioning permanently, which removes a separate and common cause of QR failure unrelated to the cryptography itself.

Recommended

• Checklist for QR code printing that actually works
• Secure QR solutions checklist for business teams
• Verifiable QR codes: a practical guide for security teams