Device Code Phishing Explained: The Attack Where the Login Page Is Real and MFA Still Fails
How attackers abuse the OAuth device authorization flow to get tokens after a victim signs in on the genuine Microsoft or Google page, why passkeys do not stop it, and the Conditional Access policy that does.
BY AISECURITYINTERVIEWS EDITORIAL · EDITORIAL TEAM · UPDATED NOVEMBER 8, 2026 · 4 MIN READ
PRACTICE THIS:Device code phishing (full answer) ·OAuth attacks
Most phishing training teaches people to check the address bar. Device code phishing makes that advice useless: the address bar shows the real Microsoft or Google sign-in page, the user's MFA works as normal, and the attacker still walks away with the account's tokens.
The legitimate flow
Smart TVs, conference-room systems and command-line tools often cannot show a full login page, so OAuth has a device authorization grant (RFC 8628). The device asks the identity provider for a short code, shows it with a URL, and waits. The user opens the URL on a phone or laptop, signs in, enters the code and approves. The device, which has been polling, receives tokens.
The attack
Attacker starts flow
gets a user code
Sends the code
meeting invite, IT request
Victim signs in
real page, real MFA
Tokens issued
to the attacker's client
The attacker does the device's part. They request a code, then send it to the victim with a story: "enter this code to join tomorrow's briefing", "IT needs you to re-verify your account". The victim goes to the genuine page, signs in, passes MFA and enters the code. The provider issues access and refresh tokens to the client the attacker is running.
Microsoft documented a state-linked campaign it calls Storm-2372 doing this in February 2025, building rapport over messaging apps before sending fake meeting invitations. An update showed the actor switching to a client that let it register a device in Entra ID and obtain a Primary Refresh Token, turning one theft into lasting access. By 2026 Proofpoint reported criminal phishing kits offering device code phishing as a service, generating the code only when the victim clicks so that the code's short lifetime no longer helps.
The same idea reached SaaS platforms: in 2025, callers posing as IT support talked Salesforce users into approving a malicious data-loading app by entering a "connection code".
Why the usual defences miss it
- Link checking: the link really is Microsoft's or Google's.
- MFA, even phishing-resistant MFA: the victim authenticates to the genuine provider, which is exactly what passkeys and security keys allow.
- Fake-site training: there is no fake site. The only reliable rule for users is: never enter a code for a device you are not holding.
What actually stops it
Block the flow where nobody needs it. In Entra ID, create a Conditional Access policy with the Authentication flows condition, select device code flow and grant Block. Exclude only the specific accounts or devices that need it, such as some meeting-room systems, after running in report-only to find them. Microsoft also rolls out a managed policy that blocks device code flow, but it starts in report-only and targets tenants that were not using the flow, so do not assume it is already on.
Google Workspace: Google's device flow allows only a short list of scopes and cannot request Gmail access; admins should still block unconfigured third-party apps and restrict high-risk scopes with API controls.
Restrict device registration so a stolen session cannot be turned into a registered device, and hunt for new registrations near risky sign-ins.
Detect: sign-in logs record when the device code protocol was used. Alert when it appears for people who do not use such devices.
Respond: revoke the user's sessions and refresh tokens, remove any device the attacker registered, review inbox rules and app consents, and look for internal phishing sent from the account. A password reset alone does not end the attacker's access.
Go deeper
The full scored answer with a what-if ladder is device code phishing. For the wider family of OAuth abuse, see OAuth attacks and consent phishing, and for integrations whose tokens are stolen from vendors, SaaS integration token breaches.
Interview questions and lessons that go deeper on this post:
FAQ
An attacker starts the OAuth device sign-in flow and persuades the victim to enter the resulting code on the identity provider's real page. The victim signs in and passes MFA, and the provider issues tokens to the attacker's waiting client.