Device code phishing went from espionage tool to criminal commodity in six months

At the start of 2026, device code phishing was a technique you saw in attribution reports about Russian state-sponsored actors. By the end of June, it was available in 18 commercial phishing kits and detections had jumped 37 times compared to late 2025.

That transition, from espionage-grade technique to criminal commodity, happened in roughly six months. It is one of the fastest commoditizations of an advanced attack technique the identity security community has seen.

How the attack works

The OAuth 2.0 Device Authorization Grant (RFC 8628) was designed to let devices with limited input capability, televisions, printers, IoT devices, authenticate with an identity provider. The flow works like this: the device requests a user code from the authorization server, displays it on screen, and asks the user to visit a URL on a separate device to complete authentication.

Attackers adapted this flow for phishing. Instead of a device initiating the request, the attacker initiates it. They generate a device code, then send the victim a message asking them to visit the legitimate Microsoft or Google device authentication URL and enter the code. The victim does so, authenticates normally including completing their MFA challenge, and the attacker receives a long-lived access token for the account.

The attack has several properties that make it attractive. No fake login page is needed. No password is captured. The MFA challenge is completed legitimately by the actual user. The token granted is typically a refresh token with a long expiry. Conditional access policies that check for phishing-resistant authentication methods frequently do not flag device code flows, because the user technically authenticated to the real identity provider.

Midnight Blizzard, the Russian APT also known as Cozy Bear or APT29, ran device code phishing campaigns against Microsoft 365 tenants in 2024 and 2025. The technique was effective enough that it attracted the attention of the criminal ecosystem.

The commodity shift

Push Security's research, published in 2026, documented the transition. By early 2026, at least 11 commercial phishing-as-a-service kits had added device code phishing capability. By June 29, BleepingComputer confirmed the number had grown to 18 kits, with every major PhaaS vendor in the AiTM space adding device code phishing to their platform.

Two kits in particular are worth noting. Tycoon2FA, which is a category leader in criminal AiTM phishing, added device code phishing alongside its established AiTM reverse-proxy capability. VENOM is a closed-source kit offering both. This means organizations that were protecting against AiTM by monitoring for reverse-proxy login page indicators now have to contend with a second MFA bypass technique from the same vendors.

The 37x increase in detections Push Security measured in the first half of 2026 is consistent with what happens when a technique moves from state actors to commodity kits: detection frequency increases sharply while attack sophistication decreases, because more operators with lower skill levels are now running the attacks.

What does not stop it

Passwords do not protect you. The attack does not need to steal a password.

Standard TOTP MFA does not protect you. The user completes the MFA challenge legitimately during the device code flow.

Push-notification MFA does not protect you for the same reason.

Monitoring for unusual login page domains does not protect you. The user authenticates to the real Microsoft or Google login page.

What does stop it

The most direct mitigation for Microsoft 365 and Entra ID is to restrict or disable the device code grant flow entirely using a Conditional Access policy. Microsoft introduced a policy control for this: you can set a Conditional Access policy that blocks the urn:ietf:params:oauth:grant-type:device_code grant type for user accounts that do not need it, which in most organizations means everyone outside of IT and service accounts managing IoT or device enrollment.

Push Security's published guidance includes the specific policy configuration. The short version: create a Conditional Access policy targeting your users, set the grant control to block device code authentication flows, and exclude accounts that legitimately need it such as shared device accounts and service principals used for device management.

Monitoring is also available. Azure AD sign-in logs record the grant type used for each authentication event. Alert on device_code grant type for accounts that do not appear in your device management exemption list.

FIDO2 hardware keys and certificate-based authentication are phishing-resistant and not vulnerable to device code phishing, but deploying them across an entire organization takes time. The Conditional Access policy block is the near-term fix.

The broader pattern

The device code phishing commoditization follows the same arc as AiTM phishing before it, and before that, LSASS dumping and pass-the-hash. State actors develop or refine a technique. It works. Criminal actors notice. Someone builds a kit. The kit gets added to PhaaS platforms. Detection volume spikes. Defense guidance catches up.

The gap between technique development and commodity availability has been shrinking for years. Six months is fast even by current standards.

If you manage identity security for an organization using Microsoft 365 or Google Workspace, the device code grant restriction is a low-complexity, high-impact control that should be in your Conditional Access baseline.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you need help hardening your Conditional Access policies or identity security baseline.