The phishing your gateway never sees

You spent real effort hardening email. A gateway scans attachments and links, SPF, DKIM, and DMARC authenticate your senders, and training taught people to distrust the urgent message. Then the attacker simply changes channels. A text message — smishing — lands on the same phone that holds your team's MFA codes and SaaS sessions, and it arrives with none of that scrutiny: no gateway between sender and screen, no DMARC for SMS, and a small display that hides the real destination of a link.

QR-code phishing — "quishing" — is the same idea wearing a different disguise. A QR code is just an opaque link a human can't read. Printed on a fake parking notice, mailed in a letter, pasted over the legitimate code on a restaurant table or an office poster, or embedded in an email image to dodge link scanners, it routes a phone straight to a credential-harvesting page that the victim opened willingly, by pointing their camera at a square of dots.

Why the phone is the soft target

The defenses you built assume a desktop and an inbox. The attack assumes neither:

  • No gateway in the path. SMS and the camera app don't route through your email security stack, so the filtering that catches most inbox phishing simply isn't there.
  • Links are unreadable before the tap. A long URL truncates on a small screen, and a QR code is unreadable by definition. The single best defense — look at where this goes before you click — is the hardest to use on a phone.
  • The phone carries the crown jewels. It holds MFA codes and passkeys, authenticated app sessions, and corporate email — and it lives on hostile public networks by default. Compromising the phone often skips straight to the accounts.

The lures are a small, recognizable set: a fake "your MFA code / verify your login" prompt timed to ride alongside a real push, a "package held, pay the fee" delivery scam, an HR or payroll text with a link, a "your account is locked" message impersonating a tool your team actually uses.

The control that survives a small screen: phishing-resistant MFA

The most important defense is the one that doesn't depend on a tired person reading a URL correctly at 11pm. If a smishing or quishing link drops your employee onto a perfect clone of your login page, phishing-resistant MFA — passkeys or hardware security keys — refuses to authenticate, because the credential is cryptographically bound to your real domain and the fake one gets nothing. SMS one-time codes are the opposite: they're a secret the user can read aloud or type into a fake page, which makes phone-delivered codes both a smishing target and a weak second factor.

  • Move privileged and email accounts to passkeys or hardware keys, the everywhere-not-mostly standard from identity hardening. This single change makes most credential-phishing — by SMS, QR, or email — structurally unable to succeed.
  • Retire SMS as a second factor where you can. A code that can be phished off a small screen, or intercepted, is the weakest link you still rely on.

Reduce what a tapped link can reach

Assume someone will eventually scan the wrong code or tap the wrong text, and limit what that costs — the same blast-radius logic behind every other control.

  • Manage the phones that touch company data. The mobile and BYOD baseline — screen lock, OS updates, the ability to separate or wipe work data — turns a compromised phone from a catastrophe into a contained incident.
  • Apply least privilege to mobile sessions, so a phished account on a phone can reach only what that role needs, not the whole estate.
  • Watch for the post-phish signal. A successful credential capture shows up as an impossible-travel login or a new-device MFA enrollment in your log and detection pipeline — the channel was novel, but the compromise still leaves the same fingerprint.

Train for the channel, not just the inbox

Most awareness programs are built around screenshots of suspicious emails. Update the curriculum to the channels people actually get hit on: a text impersonating your MFA tool, a QR code in a context that feels official, a delivery scam. The teachable rules are simple and survive a small screen — never enter credentials on a page you reached from an unexpected text or a scanned code, and never read an MFA code aloud or type it into a site a message sent you to. A phishing simulation that includes an SMS or QR lure measures whether the lesson landed in the place it matters, and a reported smishing text is a finding and early warning that your people are being targeted.

It still maps to the audit

Frameworks don't list "smishing" or "QR phishing," but they all ask how you authenticate users, train against social engineering, and protect the devices that access company data. Phishing-resistant MFA, a managed mobile baseline, and channel-aware training are exactly the evidence those questions want, and they drop into continuous evidence collection alongside the rest of your program.

One honest caveat: a platform can track that phishing-resistant MFA is enforced, that mobile devices meet your baseline, and that channel-aware training and simulations are happening — it organizes, watches, and proves the work. It does not intercept a malicious text, scan a QR code for you, or grant or guarantee any certification; the decision not to tap, and the move to passkeys, are steps your team owns, and which obligations apply to you is a question for counsel.

Smishing and quishing win by changing the channel: they aim at the phone, where there's no gateway, links are unreadable, and the MFA codes live. So defend the channel, not the inbox. Move to passkeys so a phished login simply can't complete, manage the phones that hold company data, train people on the text and the QR code rather than yesterday's email, and treat a reported scam as the early warning it is. The attacker skipped your inbox — make sure they can't skip your locks.