Device Code Phishing: When the Real Sign-In Page Becomes the Lure

Security insightsOctober 29, 2026

Device code phishing gets victims to complete MFA on the genuine sign-in page while the attacker collects the tokens. Here is how the technique works, why passkeys alone do not stop it, and five steps to take this week.

Abstract navy illustration of nested teal and blue shield outlines around a row of code-like blocks, with flowing lines converging on a single point outside the shield

Most phishing advice comes down to one habit: check the address bar before you sign in. Device code phishing gets around that habit. The victim signs in on the genuine identity provider page, completes MFA as usual, and still hands an attacker a working session. No lookalike domain is involved, so the Cloud Security Alliance notes that URL and certificate checks offer little protection.

The technique is no longer niche. Microsoft disclosed a state-linked campaign using it in February 2025. In 2026, phishing-as-a-service kits have packaged it for anyone to use. The CSA tracked one kit-driven campaign that reached more than 340 Microsoft 365 organisations within weeks. In September, CSO Online reported on a newer kit, GhostCode, that registers attacker devices within seconds of a successful sign-in. Fortunately, the defences are well understood and most of them can be put in place this week.

How a legitimate flow becomes a lure

The OAuth 2.0 device authorization grant, defined in RFC 8628, exists for devices that cannot easily show a browser, such as smart TVs, conference room systems and command-line tools. The device asks the identity provider for a short user code and then waits. The person opens a verification page on another device, enters the code and signs in. The waiting device then receives access and refresh tokens.

The weakness is built into the design, and the RFC says so plainly in its section on remote phishing: "It is possible for the device flow to be initiated on a device in an attacker's possession." In an attack, the attacker starts the flow and then persuades someone to enter the code. The lures are mundane: a Teams meeting invitation that presents the code as a meeting ID, a shared-document notice, or a voicemail alert. Once the victim approves, the tokens go to the attacker rather than to the victim.

Why MFA and passkeys do not close the gap

Phishing-resistant authenticators such as FIDO2 keys and passkeys stop credential replay because they are bound to the website's origin. In device code phishing, the origin is genuine. The user authenticates correctly to the real identity provider, and what they are tricked into is approving a session for a device they do not control. Microsoft still recommends phishing-resistant methods, and they remain the right baseline, but they cannot carry this risk alone. The control has to sit on the flow itself.

What the attacker gets, and why it lasts

The immediate prize is an access token and a refresh token. According to the CSA analysis, refresh tokens can remain valid for weeks and survive a password reset. Resetting the password is not containment on its own.

Recent campaigns go further and turn a stolen session into a durable foothold:

Device registration. Both Microsoft and eSentire, as reported by CSO Online, observed attackers registering their own devices in Entra ID and obtaining a Primary Refresh Token. In the GhostCode case, a device enrolled in Intune survived token revocation until someone removed it.
Mailbox and file harvesting. Microsoft saw the actor search mailboxes through Microsoft Graph for words such as "password" and "credentials", then use the account to phish colleagues.
Quiet persistence. CSA lists mail forwarding rules, delegated access and new OAuth app consents as follow-on footholds.

Five steps to take this week

Inventory who actually uses device code flow. Search your sign-in logs for device code authentications over the last 90 days. In Entra ID, the CSA points to the authenticationProtocol value deviceCode as the signal. Expect a short list: meeting room hardware, a few admin CLIs, some legacy tools.
Block it by default. Microsoft's guidance is to get as close as possible to a unilateral block. Create a Conditional Access policy on the Authentication Flows condition, run it in report-only mode first, then enforce it. Other identity providers that support the grant should be configured the same way.
Scope the exceptions tightly. Where the flow is genuinely needed, allow it only for named accounts or groups, from known locations or managed devices, and document why. Review the exception list, together with your break-glass exclusions, on a fixed schedule.
Make device registration a monitored event. Alert on new device registrations or MDM enrolments that closely follow a device code sign-in, and on several registrations from one session. Require admin approval for new OAuth app consents.
Update your containment runbook. For a suspected compromise, the steps are: revoke the user's refresh tokens and sessions, remove devices registered since the suspicious sign-in, and check forwarding rules, delegations and app consents. Only then is the password reset meaningful.

Detection and user guidance

Even with a block in place, keep watching. Useful signals include device code sign-ins from hosting providers or anonymising networks, scripted user agents polling for tokens shortly after a sign-in, and bulk Graph access to mail or files in the first minutes of a new session. Because the GhostCode activity ran its device registrations within about 78 seconds, detection should trigger automatic session revocation rather than wait for an analyst.

For users, the message is short and specific: no legitimate meeting, document or voicemail will ever ask you to type a code into a Microsoft or other sign-in page. If you did not start the sign-in on a device in front of you, do not enter the code, and report the message. RFC 8628 also asks identity providers to tell users clearly that they are authorising a device, so make sure that consent screen is not hidden by branding.

Conclusion

Device code phishing works because nothing looks wrong: the domain is real, MFA succeeds, and the tokens are valid. The fix is to treat the flow itself as a privilege. Block it by default, allow it only where you can name the device and the owner, and assume that a successful phish leaves devices and consents behind as well as tokens. For teams consolidating access decisions, a shared identity layer such as OXU Identity is one place to apply these policies consistently across connected systems. The steps above are worth doing regardless of the platform you use.