Device code phishing is outpacing access controls

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.

NHIMG editorial — based on content published by Push Security: device code phishing and the mainstream adoption of OAuth token theft

By the numbers:

• At the start of March, Push Security observed a 15x increase in device code phishing pages detected by its research team this year, and that figure has now risen to 37.5x.
• Push Security says it has identified 14+ distinct kits in circulation in the wild.
• The massive Salesforce campaign operated by Scattered Lapsus$ Hunters ultimately resulted in 1000+ organizations being compromised and over 1.5 billion stolen records claimed.

Questions worth separating out

Q: How should security teams handle device code phishing in environments that rely on CLI sign-in?

A: Security teams should restrict device code flow wherever it is not required, then inventory the developer and automation paths that still depend on it.

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 signals indicate that a device code login was abused?

A: Look for unusual login protocols, mismatched source IPs between token issuance and subsequent activity, and access from applications that the user does not normally use.

Practitioner guidance

• Restrict device code flow where it is not operationally required Block device code login for users and apps that do not need it, and run the policy in report-only mode first so legitimate CLI use can be mapped before enforcement.
• Correlate grant events with post-authentication behaviour Watch for mismatches between the authentication protocol used to mint the token and the IPs, user agents, or geographies that appear immediately after token issuance.
• Add browser-layer warnings for device login pages Use last-mile controls that warn or block when users reach device-code login pages, because those pages can be weaponised even when the authentication provider itself allows the flow.

What's in the full article

Push Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Historical progression of device code phishing from early tooling to 2026 PhaaS adoption.
• Kit-by-kit infrastructure patterns and lure themes, including EvilTokens, Tycoon2FA, and Venom.
• Detection evasion techniques used by modern campaigns, including redirects, bot protection, and popup-based code entry.
• Specific Microsoft conditional access guidance for blocking device code flow with report-only testing first.

👉 Read Push Security's analysis of device code phishing and OAuth token theft →

Device code phishing is outpacing access controls?

Explore further

View Full Forum →  |  NHI Foundation Course →