Most phishing training teaches one lesson: check the URL before you type your password. Device code phishing wins precisely because the victim never types a password on a fake site. There is no lookalike login page to spot, and multi-factor authentication does not help. That is why it has quietly become one of the defining attack techniques of 2026.
Push Security reports that device code phishing detections rose roughly 15x in early March 2026 and now sit around 37x for the year. What was a niche technique tied to Russian state-linked campaigns at the start of the year has been commoditized by at least a dozen ready-made kits — EvilTokens, VENOM, SHAREFILE, PAPRIKA and others — sold and operated through Telegram.
How it works
Device code authentication exists for a good reason: it lets you sign in on devices with no keyboard — a smart TV, a CLI tool, a conference-room display. You visit a URL on your phone, type in a short code shown on the device, approve, and the device is logged in.
Attackers hijack exactly that flow:
- The attacker starts a real device-code login against a legitimate service (Microsoft 365, for example) and receives a genuine code from the real provider.
- They send you that code, wrapped in a plausible pretext — "Enter this code to join the Teams meeting", "verify your account to continue".
- You go to the real Microsoft page (the URL is genuine — nothing looks wrong) and enter the code.
- You approve with your password, your MFA, even your passkey — all correctly.
- The approval authorizes the attacker's device. They now hold a valid session token for your account.
Every security control worked as designed. You authenticated successfully to the real provider. You just authenticated the attacker's device instead of your own.
Why it beats your current defences
- The URL is real. "Check the link" advice fails — the domain genuinely belongs to Microsoft or Google.
- MFA and passkeys don't help. They protect the login step. Device code phishing attacks the authorization step, after the login, so strong authentication is bypassed rather than broken.
- It captures tokens, not passwords. Rotating the password afterwards doesn't necessarily kill the attacker's session. As we covered in our piece on AI agents and non-human identities, token-based access is the layer most organizations barely monitor.
What to do
- Restrict device code flow. In Microsoft Entra ID, use Conditional Access to block or tightly scope device code authentication where your users don't legitimately need it. This is the single highest-impact control.
- Teach the specific pretext, not just "don't click links." Staff should be suspicious of any message asking them to enter a code on a login page they didn't initiate themselves. If you didn't start the sign-in, don't approve it.
- Monitor for token abuse. Watch for sign-ins from new devices or unusual locations immediately after a legitimate authentication, and be ready to revoke sessions — not just reset passwords — during incident response.
- Shorten session lifetimes for sensitive applications so a stolen token has a smaller window.
- Test your people with the real technique. Generic "click the link" simulations won't prepare anyone for this. A phishing simulation that includes device code and other MFA-bypass scenarios shows you who is actually vulnerable to what attackers are actually doing.
The bigger point
Device code phishing is a preview of where attackers are heading: away from breaking your controls and toward abusing legitimate mechanisms so that everything looks correct. Passwords, MFA and passkeys are still worth having — but they are no longer the whole story. The defence is a mix of configuration (lock down the flows you don't need), monitoring (watch the token layer) and people (train the specific behaviour).
If your awareness programme still stops at "check the URL," it is training your staff for last year's attacks. We can help you close that gap through realistic phishing simulation and human risk and awareness programmes built around what is actually landing in inboxes in 2026.
This article is general information based on public research by Push Security and Sekoia, as reported by BleepingComputer. It is not a substitute for advice specific to your environment.