CrowdStrike's 2026 Threat Hunting Report records a fifteenfold increase in monthly device code phishing attempts during the first half of 2026, alongside a doubling of vishing intrusions. eCrime groups CORDIAL SPIDER and SNARKY SPIDER used these routes to compromise SSO-integrated SaaS applications for data exfiltration.
Fifteen times, in six months. That kind of growth means the technique works, and it works because it defeats the specific defence most organisations have invested in.
What the flow is for
The OAuth 2.0 device authorization grant exists to solve a genuine problem: signing in on a device that cannot show a usable browser or accept typed input. A smart TV, a CLI tool, a games console, an IoT device.
The intended sequence:
- The device displays a short code and a URL.
- You open that URL on your phone or laptop.
- You sign in normally and enter the code.
- You approve the request, and the device receives a token.
Everything about this is legitimate. It is a published standard, implemented by every major identity provider, used daily by tools your engineers rely on.
How the attack inverts it
The attacker initiates the device flow themselves, against your organisation's tenant. The identity provider returns a genuine code. The attacker then sends that code to a victim with a plausible pretext — an IT request, a new device enrolment, a conference room system, a helpdesk call following a vishing script.
The victim:
- Visits the real
microsoft.comorgoogle.comURL - Sees the real, correctly branded sign-in page
- Signs in with their real credentials, on genuine infrastructure
- Completes their real MFA challenge
- Enters the code and approves
And the attacker's device receives a valid token.
Every element the victim was trained to check is authentic. There is no lookalike domain, no invalid certificate, no credential harvesting page. The victim did not make a mistake in the way awareness training defines a mistake — they authorised a device, which is exactly what the page asked them to do.
Why the usual controls miss
"Check the URL" fails. The URL is correct.
MFA does not stop it. The victim completes MFA legitimately. The token issued afterwards is fully authenticated and satisfies the MFA requirement.
Credential rotation does not remediate it. No credential was stolen. Resetting the password does not invalidate the issued token.
Impossible-travel detection often misses. The sign-in happened from the victim's real location on their real device. The token then gets used from the attacker's location — which is a token usage anomaly, not a sign-in anomaly, and many detections only watch the latter.
Phishing-resistant MFA does not close it either. This is the counterintuitive one. FIDO2 protects against credential relay by binding authentication to the origin. Device code phishing does not relay anything — the victim authenticates correctly to the correct origin and then approves a separate device. The security property FIDO provides is not the one being attacked.
What actually stops it
The effective controls are configuration changes in your identity tenant. None require user behaviour change, which is the point.
Disable the device code flow where it is not needed. Most organisations do not need it at all, and those that do usually need it for a narrow set of users or applications. Both Microsoft Entra ID and Google Workspace support blocking it via policy. This is the single highest-impact change available and it is a settings toggle.
Scope it with conditional access. Where the flow is required, restrict it: compliant devices only, specific network locations, specific user groups, specific applications.
Alert on device code authorisations. These events are logged. Authorisations from unexpected geographies, outside business hours, or for users who have never used the flow are high-signal and low-volume — an unusually good detection to build.
Shorten token lifetimes and enforce continuous access evaluation so a stolen token expires or is revoked on risk signals rather than persisting for weeks.
Retrain around the actual behaviour. The instruction that helps is specific: never enter a code that someone else provided you. Not "check the URL" — the URL is fine. The rule is about the provenance of the code.
The session-persistence connection
Note how this pairs with the pattern seen in the N-able N-central intrusion, where attackers established session persistence before exfiltrating data.
Both cases share a lesson worth stating on its own: modern identity attacks target sessions, not passwords. A response that resets credentials and stops there leaves the adversary's access fully intact. Session revocation has to be a standard step in every identity incident runbook, and for most organisations it currently is not.
How Safeguard helps
Identity and session posture alongside application security. Safeguard treats identity configuration — device code flow settings, conditional access scope, token lifetimes, session revocation capability — as part of the attack surface it evaluates, rather than as a separate domain that only the IAM team sees.
SaaS and integration inventory. The objective in these campaigns is SSO-integrated SaaS applications. Safeguard's TPRM module tracks which third-party applications hold which scopes against your identity provider, so the blast radius of a compromised session is a known quantity before an incident rather than after one.
Lion for the machine-identity equivalent. The same standing-authorisation problem exists for agents and automation, at greater scale and with less oversight. Lion enforces just-in-time secret brokering, capability scoping, egress allowlists, and signed audit trails so machine identities hold no durable standing access — the same principle these tenant settings apply to human sessions.
Eagle for scoping a token compromise. When a session is known to have been abused, the question is what it reached during its lifetime. Eagle reconstructs that from activity records, which is what makes a proportionate response possible.
Open your identity tenant and check whether the device code flow is enabled. For most organisations it is on by default, unused, and unmonitored — three properties that together describe the ideal attack path.
Sources: CrowdStrike 2026 Threat Hunting Report · Help Net Security · CrowdStrike Threat Hunting Report resource page
