A QR code is just an image that says “point your phone here.” That’s the whole attack. It renders as a picture, so email content filters that read text and links have nothing to scan, and the victim finishes the job on a personal phone that your Conditional Access policies never see. Quishing works because it launders a malicious URL through a channel your controls don’t cover, and then hands the click to the least-protected device in the building.
Teams closes one door on that. Under Microsoft 365 Roadmap item 570439, images that contain a QR code and arrive from an external sender get obscured by default. The user sees a blurred placeholder and a prompt to reveal it. Nothing is deleted, nothing is quarantined — the image just refuses to render cleanly until someone deliberately chooses to see it. That deliberate pause is the entire point. Quishing relies on reflex; this inserts a half-second of friction where the reflex used to be.
Now the part everyone will get wrong: external. In Teams that word isn’t one boundary, it’s three, and they don’t behave the same. External access (federation) lets people in another Microsoft 365 tenant — or via Teams’ consumer/SIP interop — chat with your users without ever being an object in your directory. Guest access is the opposite: the external person is invited in, gets a guest account in your Entra tenant, and shows up in the team roster. And then there’s the plain case of a stranger’s tenant messaging yours through open federation. The roadmap describes obscuring images from “external senders” without spelling out which of these boundaries it counts, so don’t take my map as the territory. The sensible reading — and the one worth planning for — is that anyone who isn’t a licensed member of your own tenant is external here: a guest is external even though they hold an account in your directory, and a federated user is external even though they never will. Confirm the exact behavior against your own tenant once it lands rather than assuming all three fire identically.
Whatever the precise scope, here’s the honest limit. This does nothing about a compromised internal account posting a code, and it does nothing about the guest you invited last quarter who has since been phished. It’s one control on one vector. Treat it as raising the cost of the easy attack, not closing the category.
I turned it on and watched for a week. The users, frankly, barely reacted — a blurred image with a “show” affordance is a pattern people already understand from every other app. The helpdesk noticed first, because the tickets that came in weren’t “I’m being attacked,” they were “why is this picture broken.” That’s your real change-management task: not the security briefing, the mundane one. Tell the service desk what a legitimately blurred QR code looks like before the first confused vendor-invoice ticket lands, or they’ll spend a morning chasing a rendering bug that isn’t one.
For where you verify it: this is controlled through Teams admin center policies (admin.teams.microsoft.com), alongside the external-access and messaging settings you already manage. The roadmap doesn’t hand you an exact policy name or a navigation path — those details tend to surface in the Teams admin documentation as the feature actually ships, so check there before you go hunting for a toggle that may not carry the name you expect. Roadmap 570439 includes the deployment timeline, updated as rollout progresses. What the roadmap does make clear is the enforcement model — this is default-on, applied automatically, not something you opt into. So the more useful admin exercise is to confirm your federation posture is deliberate rather than inherited. If external access is wide open because nobody ever narrowed it, this feature is patching a symptom of a scoping decision you never actually made.
The blur buys you a moment of hesitation from your users. Whether that moment lands on a code from a partner you meant to trust or a stranger you never chose to — that part is still on you.