TRUST LAYER FOR QR NAVIGATION
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
- 0:00Every day, billions of people point a camera at a QR code and follow whatever link appears. That action is pure decoding — not verification.
- 0:10The code itself carries no proof of origin. Anyone can print one, and a sticker placed over a real code inherits its context.
- 0:20Attackers exploit that gap: fake parking payments, tampered menus, phishing posters. The scan feels trustworthy precisely because the surface looks official.
- 0:30Today's defenses inspect the destination address, or check it against blocklists. Both lag behind attackers who rotate domains faster than lists can update.
- 0:40Encryption does not close the gap either. A padlock proves the connection is private — it says nothing about who is on the other end.
- 0:50Digital signatures help, but a signature only proves who signed a payload. It cannot prove the signer was vetted, or the destination still safe.
- 1:00The paper argues QR trust is not one question but four separate decisions, each answered by a different part of the system.
- 1:10First: issuer legitimacy. Was this code created by an organization that a trusted authority actually vetted and holds accountable?
- 1:20Second: destination binding. Is the link inside the code cryptographically bound to that issuer, so substitution or tampering becomes detectable?
- 1:30Third: runtime safety. Is the destination still approved at the moment of the scan — or has it been compromised or revoked since issuance?
- 1:40Fourth: presentation. Given those answers, what should the scanner actually show, so an ordinary person can act on the verdict instantly?
- 1:50The architecture mirrors the web's certificate ecosystem: a root program sits at the top, admitting operators under published, auditable rules.
- 2:00Operators delegate to issuers with constrained scopes. An issuer for one brand cannot sign codes for another — delegation is bounded by design.
- 2:10Signed policy flows down to scanners, so a phone can verify a code offline, without calling home on every scan.
- 2:20When compromise happens, revocation propagates through the same channel. A destination that was safe yesterday can be blocked within minutes, everywhere.
- 2:30Scanners collapse all of this into five verdicts: unverified, signed by an unknown issuer, verified, risky, or blocked outright.
- 2:40The hard problems left are governance: who operates the root, how issuers are vetted at scale, and how incentives stay aligned.
- 2:50The full model, threat analysis, and proof of concept are open. Read the paper, run the code, and challenge the design.
The problem
When a phone scans a QR code, it decodes a payload and hands over a link. Three questions stay unanswered:
Who issued it?
Anyone can print a QR code. A decode says nothing about the issuer's legitimacy.
Is the destination still approved?
Destinations drift. A link that was fine at print time may not be fine today.
Is it safe right now?
Even a legitimate destination can be compromised at the moment of the scan.
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.
The gap is being exploited
The argument above stands on its own, but it does not show that anyone is acting on it. Q1 2026 telemetry does: QR phishing rose sharply through the quarter while the email phishing category containing it declined.
QR phishing rose while email phishing fell
Both series indexed to January 2026 = 100.
- Both series are indexed to January 2026 = 100. A 2.6-billion total and an 18.7-million subset cannot share a linear axis at absolute scale, and two independently scaled axes would make the crossing point an authoring choice rather than a property of the data.
- February total email phishing is not published, so that series draws as a single segment rather than through an invented midpoint.
- The February QR value — index 159, about 12.1 million — is derived from Microsoft's published month-over-month deltas of −35%, +59%, and +55%. Only January and March are stated outright.
The volume is one half of the picture; the mechanics are the other. FBI FLASH AC-000001-MW, published 8 January 2026, maps a North Korean Kimsuky campaign against U.S. policy and research targets to six ATT&CK techniques. The first two run before the victim types anything, and both are invisible at the moment of the scan:
- 01
The QR code carries the URL
T1660
A spearphishing message embeds the malicious URL inside a QR code, so the link never appears as text a scanning engine can read.
- 02
A redirector fingerprints the device
T1598 / T1589
The first hop collects user-agent, operating system, IP address, locale, and screen size before deciding what to serve.
- 03
A mobile credential page takes the login
T1056.003
Web Portal Capture: a mobile-optimised page impersonating Microsoft 365, Okta, or a VPN portal harvests the credentials.
- 04
The stolen session token bypasses MFA
T1550.004
The live session cookie is replayed, so the second factor the victim already satisfied is bypassed rather than defeated.
- 05
Account manipulation makes access persistent
T1098
Changes to the compromised account keep access alive after a password rotation.
- 06
Lateral phishing runs from the victim's mailbox
T1566
The next wave arrives from a real, trusted internal sender inside the same organisation.
Steps one and two are exactly the window a scanner-side trust decision closes. Issuer legitimacy is unestablished, the destination is unbound, and runtime safety is unevaluated — and the code on the poster looks the same either way.
- Microsoft — Email threat landscape: Q1 2026 trends and insights
- FBI — FLASH AC-000001-MW, 8 January 2026
- MITRE ATT&CK — T1660 — Phishing (Mobile)
Figures as of Q1 2026 (January–March), published 30 April 2026.
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:
- 01
Issuer legitimacy
Is the party that issued this QR code a vetted, accountable issuer inside a managed trust program?
- 02
Destination binding
Is the destination cryptographically bound to that issuer, so the link can't be swapped without detection?
- 03
Runtime destination safety
Is the destination safe at scan time — not at print time — under current policy and threat data?
- 04
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.
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, unaccepted 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. The 37-case corpus, expected residual vectors, and the machine-generated evaluation report are pinned at tag trust-residuals-v1.
conformance-corpus scenarios passing
formal-table comparisons, zero disagreements
median verdict latency (1,250 ns p95)
What single-signal scanners give up
On the 35 attention-requiring corpus cases, each baseline consults exactly one evidence channel. Red: asserts positive trust where the expected outcome forbids it. Amber: demands strictly less user attention than required.
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, resolving each scan to one of six bounded decision states; and a scanner UX lab renders the five that reach a user, since an unreadable capture is a re-capture prompt rather than a trust screen. 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-adminPapers
Paper 1 — Published
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 SSRNPaper 2 — Published
Trust Residuals for Navigation QR Codes: Decision Semantics for Issuer, Destination, and Runtime Safety State (SSRN preprint, 2026) specifies the decision semantics the verifier implements — how issuer, destination, and runtime safety state compose into the one scanner state a user actually acts on.
Read on SSRNCite this work
@misc{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},
date = {2026-04-12},
doi = {10.2139/ssrn.6577478},
howpublished = {SSRN},
url = {https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6577478}
}
@misc{elmasri2026residuals,
author = {El-Masri, Hassan},
title = {Trust Residuals for Navigation QR Codes: Decision Semantics
for Issuer, Destination, and Runtime Safety State},
date = {2026-08-03},
howpublished = {SSRN},
url = {https://papers.ssrn.com/sol3/papers.cfm?abstract_id=7225699}
}Challenge this work
The papers make falsifiable claims. If you can break the model — threat-model gaps, decision semantics, adoption arguments — open a discussion. Refutations are more useful to us than praise.
Open a discussion