Device code phishing is breaking standard access controls

At a glance

What this is: This is Push Security's analysis of how device code phishing has evolved into a mainstream OAuth token theft technique and why it now bypasses standard access controls at scale.

Why it matters: It matters because IAM, NHI, and developer-access programmes must treat device-code-enabled login paths as a live token issuance risk, not just a phishing variant.

By the numbers:

• 15x increase in device code phishing pages detected, 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.

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

Context

Device code phishing is an OAuth abuse pattern, not a password theft problem. The attacker steers a user into approving a device authorization request for an attacker-controlled application, which then receives access tokens with the target account's authority. That makes the primary governance gap about token issuance, consent handling, and login-flow trust, not just phishing awareness.

The problem now spans both workforce and developer access because device code flows are common in CLI sign-in and in applications such as Microsoft, Google, Salesforce, GitHub, and AWS. For IAM teams, that means authentication policy, conditional access, logging, and browser-layer detection need to be evaluated together rather than as separate controls. The article's starting position is increasingly typical in modern SaaS and developer-heavy environments.

Key questions

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. Where it must remain, monitor grant events and post-authentication behaviour closely, because the abuse often happens after a legitimate login completes. Browser-layer warnings add a useful last-mile control.

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. The security problem is delegated token issuance to the wrong client, not weak primary authentication. Detection has to look at protocol use and downstream session activity.

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. Those signals are more useful than trying to detect the lure alone, because the malicious page may look normal and the authentication flow may still succeed.

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.

Technical breakdown

How device code phishing turns login consent into token theft

The OAuth 2.0 Device Authorization Grant was created for constrained devices that cannot easily enter credentials. The user is shown a short code on one device and completes authentication on another, which is then exchanged for tokens. In phishing, the attacker substitutes an attacker-controlled client for the legitimate device, so the victim authorises token issuance without realising they are binding the session to an adversary. The important technical point is that the protocol can be used correctly and still be abused if the human is steered into approving the wrong client.

Practical implication: treat device-code-enabled authentication as a token issuance surface and constrain where it can be used.

Why device code flow bypasses passwords, MFA, and passkeys

Device code phishing does not need to steal a password because the user performs the sign-in inside the legitimate identity provider flow. MFA and passkeys can be satisfied during that flow, which makes the resulting tokens appear legitimate to downstream applications. The issue is not credential cracking but delegated authorisation. Once the token is minted, the attacker inherits whatever access the account and application scope allow, which is why conventional login-factor controls do not reliably stop this technique.

Practical implication: inspect token-grant pathways and post-authentication behaviour, not just primary authentication events.

Why mainstream adoption changed the detection problem

Push Security describes a shift from isolated tooling to PhaaS-style kits such as EvilTokens, Tycoon2FA, and Venom. That matters because kit reuse standardises lures, infrastructure, and evasion patterns, including multiple redirects, bot protection, and popup-based code entry. As the ecosystem matures, defenders see less one-off noise and more repeatable infrastructure, which raises the value of browser telemetry, suspicious login protocol detection, and rapid containment of device-code-capable sessions.

Practical implication: build detections around campaign patterns and login telemetry, not single infrastructure indicators.

Threat narrative

Attacker objective: The attacker wants to mint valid access tokens that bypass passwords and MFA, then use them to take over accounts and move into the connected SaaS or cloud environment.

1. Entry occurs when a user is lured into a fake sign-in page that requests a device code for an attacker-controlled application.
2. Credential access happens when the victim completes the legitimate login flow and the attacker receives access tokens or related session artefacts.
3. Impact follows when the stolen tokens are used to access SaaS accounts, developer platforms, or cloud services under the victim's identity.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Device-code-enabled access has become a mainstream NHI-adjacent control issue because the token, not the password, is the real asset. Once tokens are the target, visibility into grant events, protocol choice, and downstream usage becomes more important than endpoint-only prevention. This aligns with OWASP Non-Human Identity Top 10 and NIST CSF-style detect and respond thinking for modern identity programmes.

Phishing-as-a-service has turned device code abuse into a repeatable identity attack pattern. The shift from bespoke lures to shared kits means defenders should expect faster iteration, easier operator reuse, and more consistent evasion. The practical conclusion is that login-flow hardening now has to be treated as a standing control domain, not a one-off exception workflow.

Device code phishing creates identity blast radius beyond the initial account compromise. A single token grant can unlock SaaS data, developer tooling, and cloud-connected workflows that were never directly phished. That is why identity governance has to examine where a granted token can travel after issuance, not just whether the user clicked the right prompt.

From our research:

• 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.
• For a broader NHI baseline, see Ultimate Guide to NHIs , Key Challenges and Risks, which connects visibility gaps to sprawl, over-privilege, and unmanaged credentials.

What this signals

Device-code abuse is a warning that identity teams must treat login protocols as policy surfaces. The control question is no longer only whether a factor is strong enough. It is whether the path that issues the token is appropriate for the business context, especially when developer tooling and SaaS access share the same grant mechanism.

Identity blast radius is now shaped by where a token can travel after issuance. In practice, that means governance teams need to connect authentication telemetry, SaaS authorisation scopes, and browser-layer signals before the compromise becomes a cross-platform incident. The same issue is visible in broader OAuth and token theft patterns across modern identity estates.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, device-code abuse sits inside a broader trust problem. Teams that only monitor passwords and MFA are missing the layer where modern token theft actually happens.

For practitioners

• 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. Keep narrow exceptions for developer populations that truly depend on it.
• 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. That pattern is often more reliable than generic phishing indicators.
• 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.
• Review SaaS and CLI sign-in paths together Map every application and developer workflow that uses device code sign-in, then decide whether the business value outweighs the token-theft risk. Include Microsoft, GitHub, AWS, Salesforce, and any internal tools that rely on the same pattern.

Key takeaways

• Device code phishing succeeds by abusing legitimate token issuance, which means the exposed control plane is the OAuth flow itself rather than the user's password.
• Push Security's data shows the technique is no longer niche, with a 37.5x rise in detected pages and 14-plus kits in circulation.
• Practitioners should pair protocol restrictions with behavioural detection, because blocking one login path is not enough when tokens can still be minted through other consent-driven flows.

Key terms

• Device Code Phishing: A phishing technique that abuses the OAuth 2.0 device flow to trick a user into authorising an attacker-controlled client. The result is a valid access token, so the attacker bypasses password theft and often sidesteps MFA entirely.
• Device Authorization Grant: An OAuth 2.0 flow designed for devices that cannot enter credentials easily, such as consoles or CLI tools. The user authenticates on a separate device using a short code, which makes the flow convenient but also easy to impersonate if the client identity is not carefully controlled.
• Token Issuance Surface: The parts of an identity system where access tokens, refresh tokens, or equivalent session artefacts are minted and delegated. In practice, this is where protocol choice, consent handling, and client trust determine whether an attacker can turn a legitimate login into unauthorised access.
• Identity Blast Radius: The amount of downstream access and business impact that can follow from a single identity event, such as a token grant or account takeover. For modern SaaS and developer environments, the blast radius often extends far beyond the initial app and into cloud, tooling, and data workflows.

Deepen your knowledge

Device code phishing and OAuth token abuse are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is hardening developer access or SaaS login flows, it is a practical place to build that baseline.

This post draws on content published by Push Security: device code phishing and the mainstream adoption of OAuth token theft. Read the original.