A QR code tells you where it points.
Not whether you should go.

Scanning a QR code is a decode, not a trust decision. QR Trust is a layered framework that gives scanners a real answer: who issued this code, whether its destination is still approved, and whether it is safe right now.

Video transcript
  1. Every day, billions of people point a camera at a QR code and follow whatever link appears. That action is pure decoding — not verification.
  2. The code itself carries no proof of origin. Anyone can print one, and a sticker placed over a real code inherits its context.
  3. Attackers exploit that gap: fake parking payments, tampered menus, phishing posters. The scan feels trustworthy precisely because the surface looks official.
  4. Today's defenses inspect the destination address, or check it against blocklists. Both lag behind attackers who rotate domains faster than lists can update.
  5. Encryption does not close the gap either. A padlock proves the connection is private — it says nothing about who is on the other end.
  6. Digital signatures help, but a signature only proves who signed a payload. It cannot prove the signer was vetted, or the destination still safe.
  7. The paper argues QR trust is not one question but four separate decisions, each answered by a different part of the system.
  8. First: issuer legitimacy. Was this code created by an organization that a trusted authority actually vetted and holds accountable?
  9. Second: destination binding. Is the link inside the code cryptographically bound to that issuer, so substitution or tampering becomes detectable?
  10. Third: runtime safety. Is the destination still approved at the moment of the scan — or has it been compromised or revoked since issuance?
  11. Fourth: presentation. Given those answers, what should the scanner actually show, so an ordinary person can act on the verdict instantly?
  12. The architecture mirrors the web's certificate ecosystem: a root program sits at the top, admitting operators under published, auditable rules.
  13. Operators delegate to issuers with constrained scopes. An issuer for one brand cannot sign codes for another — delegation is bounded by design.
  14. Signed policy flows down to scanners, so a phone can verify a code offline, without calling home on every scan.
  15. When compromise happens, revocation propagates through the same channel. A destination that was safe yesterday can be blocked within minutes, everywhere.
  16. Scanners collapse all of this into five verdicts: unverified, signed by an unknown issuer, verified, risky, or blocked outright.
  17. The hard problems left are governance: who operates the root, how issuers are vetted at scale, and how incentives stay aligned.
  18. The full model, threat analysis, and proof of concept are open. Read the paper, run the code, and challenge the design.
See how it worksRead the paper

The problem

When a phone scans a QR code, it decodes a payload and hands over a link. Three questions stay unanswered:

Signatures and HTTPS don't settle this. A valid signature can come from an issuer nobody vetted; a certificate can protect a destination that has drifted or been compromised. They are inputs to a trust decision — not the decision itself.

Diagram: the gap between decoding a QR payload and making a trust decision

The trust stack

QR trust is a layered systems model — not a new QR format or a new cryptographic primitive. Four layers compose into one scanner-visible decision:

  1. 1
    Issuer legitimacy

    Is the party that issued this QR code a vetted, accountable issuer inside a managed trust program?

  2. 2
    Destination binding

    Is the destination cryptographically bound to that issuer, so the link can't be swapped without detection?

  3. 3
    Runtime destination safety

    Is the destination safe at scan time — not at print time — under current policy and threat data?

  4. 4
    Scanner decision state

    What should the scanner actually show the user, composed from all of the above plus governance state?

Trust state has to move: a root trust program delegates to operators and issuers; signed policy and status flow to verifier caches and into scanners — with freshness bounds and scoped issuer namespaces.

Diagram: the QR trust model graphDiagram: authority flow from root trust program to scanner

What the scanner shows

The point of the stack is a scanner that can say more than "here's a link". Five scanner-visible states cover the common cases:

Unverified

No trust metadata. The scanner shows a plain destination with no endorsement.

Signed, unknown issuer

A valid signature from an issuer outside the trust program. Valid is not trusted.

Verified issuer

Issuer vetted, destination bound and currently approved. The scanner can endorse the handoff.

Verified, risky destination

Legitimate issuer, but runtime checks degrade the destination. Proceed with caution, visibly.

Blocked

Policy or revocation says no. The scanner refuses the handoff and says why.

Evaluate it yourself

The reference implementation is open source: a verifier, a scanner UX lab, browser evidence, native iPhone scanner experiments, and draft trust-network contracts — runnable locally without any private files.

GitHub repository

github.com/unixtime/qr-trust-poc — Apache-2.0.

Technical documentation

Trust model, scanner decision matrix, test vectors, deployment graphs.

Architecture at a glance

Issuer tooling signs QR payloads; a verifier service backed by a verifier cache evaluates issuer legitimacy, destination binding, and runtime policy; and a scanner UX lab renders the five decision states. Browser evidence captures and native iPhone scanner experiments round out the PoC.

Run it locally
git clone https://github.com/unixtime/qr-trust-poc.git
cd qr-trust-poc
make up-admin

The paper

QR Navigation Security Is Not Primarily a Cryptography Problem: A Trust-Model Framework for Managed Issuer Verification, Destination Binding, and Runtime Safety (SSRN preprint, 2026) argues that useful scanner states require managed trust composition — and that the hard remaining problem is governance: who operates the trust layer and owns its failures.

Read on SSRN
Cite this work
@article{elmasri2026qrtrust,
  author = {El-Masri, Hassan},
  title  = {QR Navigation Security Is Not Primarily a Cryptography Problem:
            A Trust-Model Framework for Managed Issuer Verification,
            Destination Binding, and Runtime Safety},
  year   = {2026},
  doi    = {10.2139/ssrn.6577478},
  url    = {https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6577478},
  note   = {SSRN preprint}
}