SURIQ
Rolling out passkeys did not close this door. For most of 2026, the fastest-growing way into corporate Microsoft 365 tenants has not touched a single password or multi-factor prompt. It phishes a token instead, and the victim's own valid, already-authenticated session is what hands that token to the attacker.
The technique is device-code phishing, and the volume is not subtle. Telemetry from Huntress and CrowdStrike, reported by Dark Reading, puts the rise at roughly 1,500% across 2026, with Huntress logging about a 1,380% jump in the first four months alone against the back half of 2025. Voice phishing, the delivery that makes the technique work, doubled over the same window. These are not two trends. They are one attack chain.
Why "we have MFA" stopped being the answer
Device-code phishing is not an adversary-in-the-middle attack. Nobody proxies your login page, nobody relays a one-time code in real time, and nobody needs your password. The flow it abuses, the OAuth 2.0 device authorization grant, was built for input-constrained devices: a smart TV or a command-line tool shows you a short code, you type that code into a normal browser where you are already signed in, and the device receives a token. The authorization happens after you authenticate, not during it.
That ordering is the whole problem. By the time the dangerous step arrives, your passkey has already fired and your multi-factor check is already satisfied, so Entra ID just wants you to confirm a code and pick your account from a menu. According to Push Security's analysis, that is why even phishing-resistant methods do not stop it: the credential was never the target, the token was. We made the same point when a retired Azure login flow let a password spray sail past MFA, and again when malware hijacked Chrome passkey logins. The pattern holds: attackers stopped fighting your authentication and started stealing what it produces.
How the flow gets turned against you
The request that starts a device-code flow is unauthenticated. Anyone, from any machine, with no prior relationship to your organization, can ask Microsoft's authorization endpoint for a device code and a matching user code. The attacker generates that code, wraps the legitimate device-login page in a lure (a fake HR salary notice, a QR code inside a PDF, a "verify your account" email), and gets an employee to enter the code. The moment they do, the attacker's waiting client receives real refresh and access tokens for that account. This is the same post-login theft we saw when a stealer grabbed the live session instead of the password, a reset does nothing once the token is out.
What those tokens reach depends entirely on the identity provider, and on the technical facts documented by Push Security and Proofpoint, Microsoft Entra ID is the highest-exposure case. Proofpoint documents criminal crews such as TA4903 moving wholesale to this technique in 2026, because on Entra ID a stolen token can be escalated through the Primary Refresh Token to single sign-on across every connected application, and a refresh token for one Microsoft app can be traded for tokens to its siblings without re-authenticating. Google Workspace fares better only because it blocks most of its own APIs from the flow.
| Identity provider | Exposure if phished | Why |
|---|---|---|
| Microsoft Entra ID | Highest | Broad scopes, reusable first-party app IDs, PRT and FOCI paths reach every connected app |
| GitHub / Salesforce | Medium | Broad scopes exist, but the attacker must run their own OAuth app |
| Google Workspace | Lower | Gmail, Calendar and most Workspace APIs are blocked from the device-code flow |
Read that table as a blast-radius chart. On Microsoft, one confirmed code can become tenant-wide API access, which is exactly why the crews concentrate there.
The phishing spike and the vishing spike are one number
The device-code flow has a hard requirement: a human has to read or enter the code. That is why the same reports showing device-code phishing up 1,500% also show voice phishing doubling. The phone call is not a separate trend competing for your attention. It is the closer. An attacker calls posing as IT, walks the target to the device-login page, and reads them the code to type in. CrowdStrike tracks two of the busier voice-phishing crews as Cordial Spider and Snarky Spider.
Scale came from productization. Push Security counts more than a dozen phishing-as-a-service kits selling this capability off the shelf, the most common of which, EvilTokens, appeared in February 2026 with ready-made Microsoft, Adobe and DocuSign landing pages. Proofpoint notes much of the tooling is "vibe coded," assembled quickly with AI help, which is why no two lures in a campaign look alike. Treat the awareness message and the technical control as one countermeasure aimed at one chain, because the attackers already do.
The awareness line that matters is narrow and testable: no legitimate IT or login process ever asks you to enter a code that a person read to you over the phone. That single rule, drilled, breaks the human half of the chain.
The detection almost no one has written
Here is the part that should change your Monday. This attack leaves nothing on the host. No malware drops, no process spawns, no file lands, so endpoint tooling sees none of it. It lives entirely in cloud identity telemetry. An organization that watches its servers and laptops but does not ingest Entra ID and Microsoft 365 sign-in logs is blind to the whole technique, the same blind spot behind Microsoft 365 accounts taken past MFA on hijacked hotel networks. Getting those logs into monitoring is the precondition for detecting any of this.
Once the logs are there, the detection is unusually cheap, because the signal is unusually clean. Most organizations almost never use the device-code flow legitimately. That rarity means you can alert on every device-code sign-in, not on a threshold or an anomaly score: near-zero baseline gives near-zero false positives. Push Security's guidance for teams that cannot block the flow points at the second tell: the IP address that authorizes the grant is usually different from the IP that then uses the token, because the victim and the attacker sit in different places. An authorization here, account activity from there, minutes apart, is the shape to hunt.
Disable the device-code flow you do not use
Blocking the flow is the strongest single control, and Microsoft now recommends it outright: for any tenant that has not used device-code sign-ins in the past 25 days, block them. In Entra ID that is a custom Conditional Access policy targeting your users, with the Authentication Flows condition set to block Device Code Flow and the grant control set to Block Access. Run it in report-only mode first for a week to surface the handful of devices that genuinely need the flow, then exempt exactly those and enforce for everyone else.
That move inverts the problem. A surface that today is open to any unauthenticated stranger becomes a short allowlist of known devices, one of the rare controls that removes a whole class of attack at almost no operational cost. One caveat is worth naming: blocking the device-code flow does not stop the related consent-based variants that abuse the ordinary authorization-code flow with a localhost redirect, so pair the policy with the identity-log detection above instead of treating it as a finish line. For the services you run, get your cloud identity logs into a monitored pipeline, because that is the only layer where this attack is visible at all.