QR code security and quishing — what businesses should do

QR code security is a sticker problem more than a software problem. The phishing pattern called "quishing" — short for QR phishing — works by pasting a malicious QR over a legitimate one in a public space, so the next person who scans the menu, the parking meter, or the shipping label loads an attacker's URL instead of yours. The QR standard isn't broken. The camera app isn't broken. Your printer isn't broken. The attack surface is the physical placement of a code anyone can overwrite with another piece of vinyl. This post is the version that walks through the actual threat model, the operational moves that shrink it, and the customer-facing hygiene that doesn't condescend.

The short version, before the long one: static QR codes are the most exposed surface because the URL is encoded in the printed pixels and can't be revoked, dynamic QR codes shift trust to a redirector you can change at any time, a recognisable custom domain blocks the most common quishing tells, and modern phone cameras already do half the work by showing the resolved URL before opening it. The piece that's still on you is making sure the right things show up in that preview, and that printed codes can't be stickered over without somebody noticing.

What quishing actually is#

Quishing is QR-code phishing. An attacker prints a sticker with their own QR code on it and places that sticker over a legitimate QR somewhere the public will scan it without thinking — a parking meter, a restaurant table, a parcel locker, a poster on a tube station wall, a public-transit timetable, a charity-donation card. The new code resolves to a page that looks like the real destination but harvests credentials, payment details, or one-time passcodes instead.

Three things make quishing work as an attack:

• The substrate is unprotected. Most QR codes in public spaces are printed on paper or vinyl with no tamper evidence. Anyone with a sticker printer and ten seconds can paste over them.
• The decoded URL is invisible to the eye. A human looking at a QR code can't read the URL. Two QR codes that look identical at a glance can resolve to wildly different destinations.
• The user trusts the surface, not the link. Someone scanning a menu trusts the restaurant. Someone scanning a parking meter trusts the city. The QR's destination inherits that trust without earning it.

The FBI flagged quishing publicly in 2023 after a wave of parking-meter and EV-charger attacks across several US cities. CISA put out joint advisories with the FCC. KnowBe4's phishing-test data through 2024 showed the share of QR-based phishing in their corpus rising into double digits, up from negligible in 2022. None of this means QR is a broken format. It means QR security has joined the list of things that need an actual defence.

Why static QRs are the exposed surface#

A static QR code encodes its destination URL directly in the printed pixels. We covered the trade-off in detail in static vs dynamic QR codes. The relevant point for security is that a static QR is unrevocable. Once the URL is in the print, you can't change it, you can't redirect it, and you can't tell the camera to refuse it. If someone else stickers over your code with a different one, the old one keeps pointing where it always pointed — but everyone who scans the new sticker is gone.

There's a second weakness specific to static codes. If your static QR encodes a long branded URL — say business.example.com/q/menu-summer-2025 — the printed grid is dense and the modules are small. Quishing stickers that replace it don't have to match the brand or the size; they just have to be a QR somewhere on the same surface. A clean black-and-white square reads as "the menu QR" to a tired customer. Density isn't the giveaway most people imagine.

Three places static is still the right answer:

• Permanent fact-of-the-world payloads. A vCard QR encoding your phone number, a WiFi QR for a private home (note that hotels and cafes with rotating credentials want dynamic WiFi QR codes instead), a calendar event for a fixed-date launch. These are facts, not surfaces.
• Genuinely offline scenarios. Industrial environments without network coverage at scan time. Dynamic doesn't work where there's no signal.
• Long-life prints on cheap surfaces. A laser-etched QR on a 20-year stainless plaque should not depend on a SaaS that might not exist in five.

For everything else — anything that's a marketing or commerce surface in public — static is operational debt and a security liability at the same time. The dynamic alternative isn't a feature upgrade; it's the only configuration that lets you respond when something goes wrong.

How dynamic QR shifts the trust boundary#

A dynamic QR encodes the URL of a redirector you control. The phone reads linked.codes/q/menu (or your own custom domain), the redirector responds with a 302 to wherever the menu lives this week, and the user lands on the real page. The QR pixels never change; the destination behind them does.

That single architectural change rewires the security story. Three things become possible that static doesn't allow:

Revocation. If you discover that someone has stickered over a printed QR with a malicious one, you can't recall the malicious sticker — but you can still pull every legitimate scan of your code into a holding page that warns the customer and explains what happened. A static code can't even do that.

Live destination control. The real destination — the menu, the form, the booking page — can change at any time. Attackers who clone your destination at one URL don't have a fresh forever-target; you can move yours.

Anomaly visibility. Every scan generates a log line on your redirector. A spike in scans from a city you don't operate in, or a thousand scans in twenty minutes from one coffee shop, is a signal. You can't see that on a static QR because there's no server in the loop.

The piece many people miss: a dynamic QR's redirector is itself a target. If the attacker compromises the redirector control panel, the printed pixels still point home — but home now points wherever they want. The hardening that matters is on the redirector account: strong unique passwords, two-factor on the dashboard, and an audit log on changes to redirect destinations. Treat the redirector with the same hygiene you treat the rest of your operational accounts.

Why a custom domain is part of the security story#

Branded short-link domains do double duty. We covered the marketing case in branded short links — why your domain beats bit.ly. The security case is different: a recognisable redirector domain is the simplest signal a user has that the QR they just scanned is the QR you intended.

Modern iOS and Android camera apps preview the resolved URL before opening it. A user scanning a parking meter QR that resolves to cityname-parking.gov/pay reads that domain in the preview and trusts it. A user scanning a stickered-over QR that resolves to bit.ly/3xY9kQ or parking-portal-pay.click should hesitate. Most won't, because the format of generic shorteners has been normalised by twenty years of marketing — but the ones who do are users you didn't lose.

If your printed QR points at a generic shortener, you've handed up that signal. The sticker-overlay attacker can use the same generic shortener and the user can't tell the difference. If your printed QR points at your-brand.com/q/..., the attacker has to spoof your domain to match — which is a whole different class of attack with its own defences (HTTPS, registrar lock, DNSSEC, certificate-transparency monitoring) that rarely all line up for an opportunistic quishing campaign.

What modern phone cameras already do for you#

iOS and Android both moved camera-app QR handling toward "show the URL, ask before opening" several releases ago. iOS surfaces the resolved domain as a notification banner with a tap-to-open prompt. Android does the same in the camera app and Google Lens, including a warning indicator if the URL matches Safe Browsing's known-bad list. WeChat, Alipay, and most Chinese super-app cameras have similar interstitials.

Three implications for your QR security posture:

The phone is on your side. You don't need to ship a custom scanner app. The native camera will show the URL clearly enough that a quishing victim has at least one chance to bail before they hand over anything sensitive.

What the customer reads matters more than what the QR encodes. This is the case for short, recognisable redirector URLs. A 90-character UTM-decorated URL gets truncated in the preview banner; the user sees the start and an ellipsis. A 22-character branded short link displays in full.

Safe Browsing and equivalent block lists do real work. Google's Safe Browsing flags compromised destinations within hours of a report. Apple uses similar lists. Your job is to make sure your real destinations are clean (HTTPS, valid certificate, no malware) so they don't accidentally land on a block list. The bigger win is reporting attacker URLs the moment you spot them so the next victim's phone refuses the page.

The piece you can't outsource: tell customers to read what the camera shows before tapping. Most won't on instinct. The ones who do are the ones who don't end up in your support inbox after a quishing event.

A QR security audit you can score yourself#

Run through the eight items below for a typical printed QR you ship — a menu, a parking meter, a packaging insert, whatever's most visible to your customers. Tick the ones you're confident about. The widget scores in real time and saves to your browser so you can come back to it.

A score of six or higher is where most legitimate businesses ship from. The two that small teams skip most often are the audit log on destination changes and weekly anomaly review of scan data — both are operational rather than technical, which is exactly why they get deferred.

Operational hygiene that closes the gap#

Five practices that move you from theory to a printed-QR fleet that's actually defended:

Tamper-evident placement. Public-facing QRs go under a laminate, behind glass, or on a substrate that can't be cleanly stickered over. The point isn't that the laminate is unbreakable — it's that an attacker covering it leaves a visible disturbance. Staff doing a closing-shift walk-through can spot it.

HTTPS only, always. The redirector and the destination both require valid certificates. If a customer scans your QR and the destination is http:// (no cert) the camera-app preview banner will say so. That's a message you don't want associated with your brand.

No login or payment forms from a printed QR. A QR can take a customer to a public landing page, a menu, an info page, a "view your order status" portal entry. It should not take them directly to a credential entry or a card-on-file payment screen. Quishing campaigns rely on the customer being primed to enter credentials by the time they land. Don't pre-warm them.

Recognisable redirector domain on every print. This is the branded short link angle expressed in security terms. Pair it with the domain-ownership posture and you've also bought yourself the option to migrate platforms later if you need to.

Anomaly review on scan analytics. Dynamic QRs leave a log line per scan. A weekly five-minute glance at the geo distribution and time-of-day curve catches the pattern when a sticker has been placed somewhere it shouldn't be. A sudden spike of scans from a country you don't operate in, or 200 scans in a thirty-minute window from one specific physical location, is your early warning.

Two real attack patterns observed in the wild#

Parking-meter quishing. The most documented pattern across US and European cities since 2022. Attackers paste a QR over the legitimate meter QR, the customer scans expecting to pay parking, lands on a payment page that looks like the city's portal, and enters card details. The card is charged repeatedly by the attacker before the customer notices. Defence: cities are moving to laminated, recessed QRs with embossed identifiers and the city domain printed visibly under the code.

Restaurant-menu quishing. Smaller-scale but harder to spot because customers don't expect anything sensitive on a menu QR. Attackers replace the table-tent QR with one that loads a fake menu page asking for "table number and card details to start a tab." Cardholders who follow through hand over the card. Defence: print the menu URL in human-readable form alongside the QR ("menu.restaurantname.com — same destination either way") so the customer has a sanity check that doesn't depend on scanning.

A third pattern worth flagging: shipping-label quishing on parcel-locker doors and self-service postal kiosks. Attackers cover the legitimate "track your parcel" QR with one that requests reauthentication of the user's parcel-carrier account. Several European postal services have run customer-education campaigns specifically about this. The defence is the same family — laminate the substrate, print the carrier domain visibly, and never link to a login page from a printed surface.

Internal controls — who can change where the QR points#

The strongest QR security loses to bad credential hygiene on the redirector account. If an attacker phishes the dashboard login of the person who manages your QR fleet, every printed code can be silently rewritten to point at the attacker's destination — without ever touching a sticker. The printed pixels haven't changed. The redirector behind them has.

Three controls that matter:

• Two-factor on the redirector account. This is the single highest-impact change for most businesses. The attacker who phishes the password still can't get in.
• Role-based access on the dashboard. Marketing should be able to update destinations; only an admin should be able to change the underlying short-link slug or the custom domain mapping.
• Audit log on destination changes. Every "destination changed" event records who, when, from where, what changed to what. Review weekly. The pattern matters more than any single entry.

These are unglamorous controls and they're exactly the ones that prevent the worst case. Treat the redirector dashboard with the same hygiene you'd treat any other operational SaaS account that holds customer-facing routing.

Customer-facing education that doesn't condescend#

A short paragraph in your FAQ, on a "scan to pay" landing page, or in a printed staff cheat-sheet, in plain language:

When you scan our QR code, your phone shows the destination URL before opening it. Our codes always go to your-brand.com. If the URL preview shows anything else, don't tap it — let us know.

That's the whole brief. Don't lecture. Don't list every threat. Most customers don't need to understand quishing as a concept; they need to know what your domain looks like and what to do if the preview shows something different. Train the staff on the same line so they can answer the rare customer who asks.

Related reading#

• Static vs dynamic QR codes — when to use which — the trade-off underneath everything in this post.
• Why every QR type should be dynamic by default — the case for dynamic vCard, WiFi, calendar, and email too.
• Branded short links — why your domain beats bit.ly — the marketing case for the same domain that does the security work here.
• Why you should own your link infrastructure — the deeper layer underneath redirector trust.
• QR code not scanning? Six fixes that solve 95% of cases — what to check when the failure isn't malicious.
• QR codes outdoors — billboards, bus stops, signage — substrate and tamper considerations for public placements.
• QR code designer in the docs — design and re-point the code from the dashboard.