Topic starter
22/06/2026 10:18 am
TL;DR: Device code phishing abuses the OAuth device code flow so victims authenticate on Microsoft’s real login page while attackers receive valid access tokens, according to Silverfort, and the tactic has moved from STORM-2372 tradecraft to the EvilTokens PhaaS kit in under a year. Conventional login protections assume credential capture or fake infrastructure; this pattern turns legitimate sign-in into token theft and leaves little for perimeter tools to inspect.
Editorial analysis by NHI Mgmt Group, based on content published by Silverfort: “Device code attacks in Azure: From exploitation to detection”.
Key questions
Q: What breaks when device code flow is left enabled for the broad workforce?
A: The organisation creates an unnecessary path for attackers to turn user approval into access tokens without capturing passwords.
Q: Why do passwords, MFA, and passkeys fail to stop device code phishing?
A: They fail because the user completes a legitimate sign-in inside the identity provider, so the attacker receives a valid token rather than stealing the factor itself.
Q: What are the signs that device code phishing is happening in Entra ID?
A: Look for successful device code sign-ins tied to first-party clients, unusual geographies or ASNs, and non-interactive token activity that does not match the user’s normal behaviour.
Practitioner guidance
- Block device code flow for users without a documented need Use Conditional Access to disable the device code grant for the broad workforce and reserve it only for approved CLI, headless, or constrained-device scenarios.
- Alert on device code sign-ins and non-interactive token use Correlate successful device code sign-ins with anomalous geographies, rare clients, and non-interactive refresh activity that indicates token theft after the user approves the flow.
- Extend incident response to token revocation and session review When device code phishing is suspected, revoke access, disable the account if warranted, and inspect OAuth app consents, active sessions, and any new device registrations.
Bottom line: Device code phishing works because a real Microsoft sign-in can still hand valid tokens to the wrong machine, which makes it a protocol abuse problem rather than a fake-login problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
22/06/2026 11:08 am
Device code phishing exposes a protocol trust gap, not a password problem. The attack succeeds because the identity system treats code approval as sufficient proof of intent, even though the polling client is never bound to the person who entered the code. That means many existing controls are aimed at the wrong failure mode. Practitioners should stop framing this as ordinary phishing and treat it as token issuance abuse.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: Should organisations block device code authentication or keep it for exceptions?
A: Most organisations should block it by default and allow it only for documented headless or constrained-device use cases. If an exception is needed, scope it tightly by user group, device class, and location, then pair it with monitoring so the exception does not become a standing attack surface.
👉 Read our full editorial: Device code phishing is exposing gaps in Microsoft Entra ID controls