Block device-code phishing in 2026: the Entra ID, Okta, GitHub and Google Workspace settings

Summary. Device-code phishing abuses the OAuth 2.0 device authorization grant to steal access tokens, and it defeats every form of multi-factor authentication including passkeys. Push Security counted a 37.5x rise in device-code phishing pages by 4 April 2026 and now tracks more than 25 distinct kits, up from 14-plus in its April write-up. Microsoft reported 10 to 15 entirely new campaigns every 24 hours by April 2026. Barracuda counted 7 million attacks in four weeks. The FBI issued a standalone advisory on the Kali365 kit, the first US federal public service announcement about a specific phishing-as-a-service platform. Roughly 99% of what Push detects targets Microsoft, so Entra ID is where the block matters most, and Microsoft now recommends blocking device code flow for tenants that have not used it in the past 25 days. The uncomfortable part: your identity spend does not help here. The attack happens after authentication succeeds.

Why passkeys do not stop this

Every phishing control most organisations bought in the last three years protects the authentication layer: proving who you are. Device-code phishing attacks the authorization layer: granting an application access to your account. Those are two different operations, and the device authorization grant separates them by design.

The attack is embarrassingly short. An attacker POSTs to the provider's device authorization endpoint with a client ID and requested scopes. That first request is unauthenticated on every major provider, so anyone can generate a code from any machine with no relationship to the target organisation. The server returns a device_code for polling and a user_code for the human. The attacker delivers the user_code through any channel. The victim opens the provider's own login page, types the code, picks their account from a dropdown and clicks allow. The attacker's polling loop receives an access token, a refresh token if offline_access was requested, and an ID token if openid was included.

In the common case the victim is already signed in, so no password and no MFA prompt appear at all. Luke Jennings, Vice President of R&D at Push Security, put it directly in the April 2026 analysis: "The device code authorization is effectively performed post-authentication. If you already have an active session in your browser, entering the device code and selecting your account from a drop-down menu is all that's needed. No password or MFA required."

Two consequences follow. There is no cloned login page for a URL reputation service to flag, because the victim transacts on the provider's genuine domain. And the flow is normal: Azure CLI, GitHub CLI and AWS CLI have all used device codes as a primary or fallback sign-in method, so technical users type these codes routinely. A lure asking for the same action is indistinguishable from a real IT request.

How the threat scaled in six months

Date	Event	Source
2020	Technique first documented publicly	Push Security
Aug 2024	First in-the-wild exploitation identified	Push Security
Feb 2025	Storm-2372 campaign against Microsoft device code auth	Microsoft, Volexity
Feb 2026	EvilTokens launches as the first criminal device-code phishing-as-a-service kit	Push Security
4 Apr 2026	Push records a 37.5x rise in device-code phishing pages, up from 15x at the start of March	Push Security
Apr 2026	Microsoft reports 10-15 new campaigns every 24 hours	Microsoft
Apr 2026	Barracuda counts 7 million attacks in four weeks	Barracuda
May 2026	Tycoon2FA, the leading adversary-in-the-middle kit, adds device-code phishing	Push Security
May 2026	FBI issues a public service announcement on the Kali365 platform	FBI IC3
Jul 2026	Push tracks more than 25 distinct kits	Push Security

The Scattered Lapsus$ Hunters campaign against Salesforce shows the ceiling. It paired voice phishing with a device-code payload and, as the campaign broadened into a supply chain attack, more than 1,000 organisations were compromised with over 1.5 billion records claimed stolen.

Two escalation paths make Microsoft the highest-value target. Many Microsoft first-party applications belong to the Family of Client IDs, so a refresh token obtained for one member can be exchanged for access tokens to other members without re-authentication. An attacker who phishes a token through the Microsoft Office client ID can pivot to Outlook, Teams, OneDrive, SharePoint and Azure management APIs from one session. Separately, targeting the Microsoft Authentication Broker application and chaining into a new device registration yields a Primary Refresh Token and single sign-on across everything connected to the tenant. That is the technique Storm-2372 used.

The risk is not uniform across providers

Before you write policy, understand that the four platforms in scope have genuinely different exposure.

Platform	Device-code exposure	Native block available	Practical action
Microsoft Entra ID	Highest: unrestricted scopes, reusable first-party client IDs, FOCI and PRT escalation	Yes, Conditional Access authentication flows condition	Report-only, then block with narrow exceptions
GitHub	Moderate: broad scopes including full repository access, but attacker needs their own OAuth app and the victim sees a consent screen	Partial: per-app enablement plus org OAuth app restrictions	Restrict which OAuth apps can reach org data
Okta	Depends entirely on your app registrations: device authorization is an opt-in grant type per app	Per-app grant type, no single tenant switch	Audit every app integration, remove the grant where unused
Google Workspace	Lowest: Google limits which scopes the device code flow can request, so Gmail, Calendar and most Workspace APIs are unavailable through it	Not needed for the flow itself; app access control covers third-party OAuth apps	Set third-party app access control, then monitor
Salesforce, AWS and other OAuth apps	Varies by implementation	Usually none	Log-based detection and response

Google's scope restriction is the quiet lesson here. The most effective control against this attack class was a design decision made years ago, not a policy toggle added afterwards.

Setting 1: Entra ID Conditional Access, in report-only first

Microsoft exposes device code flow as a Conditional Access condition. The Entra documentation, last revised 24 March 2026, is unambiguous: "Device code flow is a high-risk authentication method that can be part of a phishing attack or used to access corporate resources on unmanaged devices. Allow device code flow only where necessary. Microsoft recommends blocking device code flow wherever possible."

The build order matters more than the policy itself.

Find out who actually uses it

Open the Entra sign-in logs and filter by Authentication protocol for device code events. That single filter usually collapses the problem: most tenants find a handful of conference-room devices and one or two build agents. Microsoft's managed-policy guidance is to block device code flow for tenants that have not used it in the past 25 days, which is a reasonable threshold to borrow.

Create the policy

In the Entra admin centre, go to Entra ID > Conditional Access > Policies > New policy. Under Conditions, select Authentication flows and pick Device code flow. Under Access controls > Grant, choose Block access. Set Enable policy to Report-only and leave it there long enough to cover a full billing or release cycle.

Watch out for protocol tracking

This is the detail that causes unplanned outages. Entra applies protocol tracking to any session that used device code flow, and that state survives subsequent token refreshes. The documented example is worth reading twice: if you allow device code flow for SharePoint only, sign in to SharePoint with a device code, then try to reach Exchange in the same session using any flow at all, you are blocked, because the session carries the tracked state. Users hitting this see error code AADSTS530036, and the sign-in log gains an Original transfer method property showing the tracked state.

Exempt device registration if you use it

If any workflow registers devices using device code flow, exclude the Device Registration Service before you enforce a policy that targets all resources. Microsoft began enforcing authentication flow policies on that resource in early September 2024. Exclude it in the UI under Target Resources > Exclude > Select excluded cloud apps > Device Registration Service, or by client ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 via API.

Then flip it on

Move Enable policy from Report-only to On. Keep the exceptions narrow, named and documented, and re-review them quarterly. Teams already rebuilding Conditional Access will find the sequencing familiar from the Entra ID risk policy migration to Conditional Access.

Setting 2: Okta, where the control is per application

Okta has no tenant-wide device-code switch, because in Okta the device authorization grant is opt-in per application. It is enabled when someone creates an OIDC native application and ticks Device Authorization in the grant types. That makes the work an inventory job rather than a policy job.

Go to Applications > Applications in the Admin Console and review each OIDC app integration. For every app where Device Authorization is selected, ask whether an input-constrained device genuinely needs it. Remove the grant type where the answer is no. Record the ones you keep, with an owner, so the list does not silently grow.

The advantage of the per-app model is precision: you can leave the grant on a single kiosk application and remove it everywhere else without any tenant-wide blast radius. The disadvantage is that nobody notices when a new app ships with the box ticked, so this belongs in an app-registration review, not a one-off cleanup.

Setting 3: GitHub, where device code is the default CLI login

GitHub is the awkward case, because device code is how developers authenticate the CLI and Git Credential Manager. Blocking it outright is not realistic in most engineering organisations.

Two controls do help. First, GitHub requires app owners to explicitly opt in: the OAuth device authorization flow must be enabled per app on its settings page, and the device flow endpoints return HTTP 400 for apps that have not enabled it. GitHub introduced that requirement in March 2022 specifically to reduce the likelihood of apps being used in phishing attacks. That does not stop an attacker registering their own app and enabling it, but it does mean a dormant internal app cannot be quietly abused.

Second, use OAuth app access restrictions at the organisation level to control which third-party OAuth apps can reach your repositories and other resources. New organisations have these restrictions enabled by default, and owners can disable them, so verify the current state rather than assuming. The victim in a GitHub-targeted device-code attack does see an explicit consent screen for the attacker's app, which is one more chance for the control and the human to catch it.

Given that developer tooling is the legitimate use case here, the pragmatic answer for engineering organisations is monitoring plus a narrow allowlist, not a block. Search authentication logs for a mismatch between the IP that completed the authorization grant and the IP performing subsequent API activity. That pattern is one of the few reliable, provider-agnostic signals.

Setting 4: Google Workspace, already mostly closed

Google limits which scopes the device code flow can request, and Gmail, Calendar and most Workspace APIs are not available through it. That structural limit is why Push assesses Google Workspace as a significantly lower-risk target. There is no equivalent emergency here.

The control that still matters is third-party app access. In the Admin console go to Security > Access and data control > API controls, then Manage Third-Party App Access. Unconfigured third-party apps are blocked by default, and a user request for a blocked app lands in a review list where you can allow, dismiss or explicitly block it. Apps can be marked trusted, meaning access to all OAuth scopes including restricted services, or limited to unrestricted services only. Configure known apps preemptively by OAuth app name or client ID rather than waiting for the request queue.

Setting 5: detection, because blocking is never complete

Even a clean Entra block leaves gaps, and the honest version of this advice says so.

Related techniques produce identical outcomes without touching the device code flow. ConsentFix, which Push detected in late 2025, exploits the authorization code flow with localhost redirects, yields the same access tokens with the same capabilities, and is not affected by device-code Conditional Access policies. Blocking one grant type moves attackers to the next one.

So instrument the following, in this order:

1. Authentication logs from every OAuth-capable app, beyond your primary identity provider. If you cannot see GitHub, Salesforce and AWS authorization events in one place, you cannot detect this at all.
2. IP mismatch between grant and activity. The authorization is approved from the victim's network; the token is used from the attacker's. That split is the single highest-value query.
3. New device registrations following an authorization event, which is the PRT escalation signature.
4. First-party client IDs appearing in unusual sequences, particularly the Microsoft Authentication Broker.
5. Report-only Conditional Access hits as an ongoing feed rather than a pre-deployment exercise.

Detection has to sit where the attack does. Email gateways and network proxies see nothing useful, because the victim's decisive click happens on the provider's legitimate URL.

A two-week rollout plan

Week	Entra ID	Okta	GitHub	Google Workspace
1	Filter sign-in logs for device code usage	List every OIDC app with the Device Authorization grant	Confirm OAuth app access restrictions are enabled	Review third-party app access control state
1	Create the policy in report-only	Identify owners for each app	Inventory apps with device flow enabled	Configure known apps by client ID
2	Exempt Device Registration Service if required	Remove the grant where unused	Build the IP-mismatch detection query	Set unconfigured apps to blocked
2	Move policy to On with named exceptions	Add the grant to app-registration review	Brief developers on what a real CLI login looks like	Monitor the app request queue

Two weeks is realistic because none of these steps require procurement. The slow part is not configuration, it is finding the three teams whose tooling breaks when you enforce.

India-specific considerations

For Indian organisations a stolen access token that reaches mailboxes or customer records is a personal data breach under the Digital Personal Data Protection Act 2023, and the DPDP Rules were notified in November 2025 with full compliance required from May 2027. Two practical implications.

First, breach notification depends on knowing what the token touched. If your OAuth authorization logs are not retained alongside application access logs, reconstructing scope after an incident is guesswork, and guesswork is a poor basis for a regulatory notification. Fix log retention before you fix policy.

Second, Indian teams often run heavier developer tooling footprints relative to headcount, particularly in global capability centres and product engineering firms, which raises the legitimate device-code usage rate and makes a blanket block harder. Plan for exceptions rather than pretending they will not exist. The wider sequencing sits in our DPDP Act engineering playbook for Indian startups, and the identity groundwork overlaps with CIAM and passkey implementation.

What this says about the next attack

The pattern is worth naming, because it will repeat. Defenders spent five years hardening authentication: MFA, then phishing-resistant MFA, then passkeys. Attackers responded by moving one layer over, to authorization, where almost nobody had built controls. Device-code phishing and ConsentFix are the same strategic move executed against two different grant types.

That suggests where to look next: consent flows, device registration and token exchange are all authorization mechanisms with weaker instrumentation than login. The teams that come through this well will be the ones who treat "which application holds a token for this user, with what scopes, since when" as a first-class question, the same way they already treat "who logged in". The same reasoning underpins how we approach prompt-injection guardrails for AI agents and software supply chain security: the control has to sit where the privilege is granted, not one layer upstream.

FAQ

Does passkey enforcement stop device-code phishing?

No. The device authorization grant runs after authentication has already succeeded, so it is unaffected by how strongly the user proved their identity. Push Security states the attack cannot be prevented with authentication controls, including phishing-resistant methods such as passkeys. The defence is authorization-layer policy, not stronger login.

What exactly do I click in Entra to block it?

In the Entra admin centre go to Entra ID, Conditional Access, Policies, then New policy. Under Conditions choose Authentication flows and select Device code flow. Under Access controls, Grant, select Block access. Set the policy to Report-only first, confirm impact in the sign-in logs, then switch it On.

Why did users get blocked from apps we did not target?

Entra applies protocol tracking to sessions that used device code flow, and that state persists through token refreshes. A session that used a device code for one allowed resource can be blocked when reaching a different resource by any flow. Affected users see error code AADSTS530036 in the sign-in logs.

How do I find legitimate device-code usage before enforcing?

Filter the Entra sign-in logs using the Authentication protocol filter for device code events, and run the Conditional Access policy in report-only mode across a full release cycle. Microsoft's managed-policy guidance suggests blocking for tenants with no device code usage in the past 25 days, which is a usable threshold.

Is Google Workspace exposed to this attack?

Much less so. Google restricts which scopes the device code flow can request, so Gmail, Calendar and most Workspace APIs are unavailable through that mechanism. Push Security assesses Google Workspace as a significantly lower-risk target. Third-party OAuth app access control in the Admin console remains the relevant setting.

Can we block device code flow on GitHub?

Not cleanly, because device code is the default sign-in method for the GitHub CLI. GitHub requires app owners to enable the device flow per app, and the endpoints return HTTP 400 for apps that have not, but an attacker can enable it on their own app. Organisation-level OAuth app access restrictions plus log monitoring are the practical controls.

Does blocking device code flow end the problem?

No. ConsentFix, detected by Push researchers in late 2025, uses the authorization code flow with localhost redirects to obtain the same tokens with the same capabilities, and device-code-specific Conditional Access policies do not affect it. Treat the block as one control inside authorization-layer monitoring rather than a complete fix.

What is the single best detection signal?

A mismatch between the IP address that approved the authorization grant and the IP address performing subsequent account activity. The victim approves from their own network while the attacker uses the token from theirs. Push recommends searching authentication logs for unusual login protocols and exactly this kind of address split.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, with CMMI Level 5, MSME and ISO 27001:2022 certification and partnerships including Microsoft, Google and AWS. Our senior engineering teams run identity hardening programmes end to end: sign-in log analysis to find real device-code usage, Conditional Access rollouts staged through report-only, Okta app-registration audits, and detection queries wired into your existing logging stack. We design identity and data-handling architectures aligned with DPDP Act 2023 requirements. If device-code phishing is on your risk register without an owner, contact us and we will start with the log review.

References

1. Analyzing the rise in device code phishing attacks in 2026 — Luke Jennings, Push Security, 4 April 2026, updated 25 June 2026.
2. 6 Reasons Why Device Code Phishing is the Fastest-Growing Threat of 2026 — The Hacker News, 31 July 2026.
3. Conditional Access: Authentication flows — Microsoft Entra documentation, revised 24 March 2026.
4. Block authentication flows with Conditional Access policy — Microsoft Learn.
5. Storm-2372 conducts device code phishing campaign — Microsoft Threat Intelligence, 13 February 2025.
6. AI-enabled device code phishing campaign — Microsoft Security, April 2026.
7. Threat Spotlight: device code phishing — Barracuda, 23 April 2026.
8. Public service announcement on the Kali365 phishing platform — FBI Internet Crime Complaint Center, May 2026.
9. RFC 8628: OAuth 2.0 Device Authorization Grant (IETF).
10. Enable OAuth Device Authentication Flow for Apps — GitHub Changelog, 16 March 2022.
11. About OAuth app access restrictions — GitHub Docs.
12. Configure Device Authorization Grant Flow (Okta Developer documentation).
13. Control which third-party and internal apps access Google Workspace data — Google Workspace Admin knowledge base.
14. Restrict third-party API access with app access control — Google Workspace Updates.
15. DPDP Act enforcement dates and compliance timeline — ConsentOS.

Last updated: 4 August 2026.