Topic starter
10/06/2026 12:15 am
TL;DR: Device code phishing has moved into mainstream criminal use, with Push Security reporting a 37.5x rise in detected pages and 14-plus kits in circulation; the technique abuses OAuth 2.0 device flows to mint tokens while bypassing passwords, MFA, and passkeys. The governance gap is that protocol design still assumes users and access paths behave predictably, which is no longer true.
Editorial analysis by NHI Mgmt Group, based on content published by Push Security: “Device code phishing attacks have skyrocketed: hereâs what you need to know”.
Key questions
Q: What breaks when device code flow is not controlled in enterprise environments?
A: Device code flow creates a gap where a legitimate-looking OAuth approval can mint tokens for an attacker-controlled client.
Q: Why do OAuth attacks bypass MFA so often?
A: OAuth attacks bypass MFA because the attacker is not asking the user to log in again after the token is issued.
Q: What are the signs that device code authentication is being abused in phishing attempts?
A: Look for unexpected device logins, repeated token requests from unfamiliar clients, user codes entered outside normal onboarding paths, and access token use that does not match the expected device or workload.
Practitioner guidance
- Block device code flow where it is not operationally required Use conditional access or equivalent policy controls to block the OAuth device flow for users and tenants that do not need it, starting with report-only mode to identify legitimate usage.
- Inventory legitimate device-code usage by user group and app Map which developers, administrators, and CLI workflows still require device code sign-in, then narrow exceptions to those cases rather than leaving the flow broadly available.
- Monitor for token-grant anomalies across authorisation and post-auth activity Look for unusual login protocols, mismatched source IPs between authorisation and subsequent activity, and access events that do not align with the expected app sign-in pattern.
Bottom line: Device code phishing works because it abuses a legitimate OAuth flow to mint tokens, so standard credential controls are not enough on their own.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
11/06/2026 1:58 am
Device code phishing works because login protocols still trust the user's completion of the flow more than the origin of the request. That is the structural failure at the heart of this technique. The attacker does not need to break the authenticator; they only need the user to approve token issuance for the wrong client. Practitioners should read this as a token trust problem, not a classic phishing problem.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- That visibility gap is split into 38% with no or low visibility and 47% with only partial visibility, which is why OAuth grant review remains a weak point in many identity programmes.
A question worth separating out:
Q: When should organisations block device code flow entirely?
A: Organisations should block it wherever the business does not depend on it, especially for users who do not need CLI sign-in. If the flow is still essential for specific teams, use report-only testing first, then enforce with narrow exceptions so you do not break legitimate developer access.
👉 Read our full editorial: Device code phishing is breaking standard access controls
12/06/2026 3:32 am
Device-flow abuse exposes a protocol trust problem, not just a phishing problem: The device authorization grant assumes a predictable user-mediated login path and a trustworthy client boundary. That assumption breaks when the requester is attacker-controlled and the user approval is the only human-visible step. The implication is that identity governance has to treat protocol behaviour as part of the control surface, not as a neutral transport layer.
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 breaking standard access controls
This post was modified 1 day ago by NHI Mgmt Group