Why OAuth Device-Code Phishing Became 2026's Fastest-Growing Attack, Explained

How do you sign a smart TV or a CLI tool into your account when it has no keyboard? RFC 8628, the OAuth 2.0 Device Authorization Grant, answers by moving credential entry to a device you already trust. The screen displays a short code, you type it at a URL on your phone, and the TV gets signed in.

The whole design leans on one quiet assumption: the code reaches you over a trustworthy out-of-band channel, because it is printed on the screen of the very device asking for access. Break that one assumption and the protocol still runs perfectly. It just runs for someone else.

The flow uses two codes. The user_code is short and human-friendly, roughly 8 characters formatted like WJB-MJHT, while the long, high-entropy device_code is polled quietly by the client against the token endpoint every ~5 seconds until you approve. You only ever see the short one.

So the attacker starts the flow, receives the code, and mails it inside a fake meeting invite or e-signature notice. You approve at the genuine Microsoft page, and the token drops into the attacker's polling client. RFC 8628 §5.4 literally names "remote phishing" as a known risk, so this was anticipated by the authors, not discovered later.

What the attacker collects is not a password but tokens. The access token grants ~90 minutes of direct API reach into Exchange Online, OneDrive, SharePoint and Teams, and the refresh token is valid for 90 days and self-renews on every exchange. A single successful phish can quietly hold access for months without ever prompting you again.

It gets worse if the attacker runs the flow with the Microsoft Authentication Broker client ID. That refresh token can be exchanged for a device-registration token, enroll an attacker-controlled device in Entra ID, and yield a Primary Refresh Token, which grants SSO everywhere with no further MFA and survives a password reset. The standard first-response remediation just stops working.

Here is why the usual defenses miss it: nothing about the sign-in is fake. The victim completes a real authentication ceremony at the real microsoft.com/devicelogin, so the push approval, TOTP, or Windows Hello all succeed normally and Entra ID records a legitimate, MFA-satisfied sign-in. There is no lookalike domain to flag and no cookie to intercept.

FIDO2 and passkeys only help here through a server-side Conditional Access policy that restricts which methods can complete the device-code ceremony, because there is no origin mismatch when the real domain is used. TOTP, push approval, and SMS OTP give no protection at all, which is why Microsoft's own guidance is to block the device-code flow entirely wherever possible.

The technique itself is old. It was publicly introduced back in 2020 and had proof-of-concept tooling by 2022. Nothing about the protocol changed in 2026, so the surge is not a new exploit. What changed is packaging.

Phishing-as-a-service platforms like EvilTokens, which debuted on Telegram in February 2026, turned the whole attack into a rented product: prebuilt DocuSign and SharePoint lures, AI-written copy, anti-analysis tricks, a management console for harvested tokens, even a support team. By April 4, 2026 detection infrastructure recorded a 37.5x jump in device-code phishing pages, driven by EvilTokens plus at least 11 other distinct kits.

One campaign shows the assembly line running at scale. It hit 340+ Microsoft 365 organizations across the US, Canada, Australia, New Zealand and Germany, spanning construction, healthcare, legal, finance and government. The delivery chain is built entirely from trusted infrastructure to slip past filters.

Links rode inside legitimate Cisco, Trend Micro and Mimecast URL-rewrite systems, bounced through Cloudflare Workers, and landed on Railway.com PaaS whose clean IPs dodged Microsoft's risk scoring, with just three Railway IPs behind roughly 84% of activity. The twist tied to EvilTokens: the landing page renders the device code right on screen, cutting the last manual step out of the attacker's own workflow.