Device Code Phishing: Detect and Block Device Flow Abuse

Device code phishing tricks a user into approving an attacker's sign-in on the genuine identity provider page, so the attacker receives valid access and refresh tokens without ever touching the user's password or MFA factor. The technique abuses the OAuth 2.0 device authorization grant (RFC 8628), which exists so that TVs, conference room systems and command-line tools can sign in on a second device. Because the victim types a short code into a real Microsoft or other IdP domain, URL checking and most MFA, including some phishing-resistant methods, do not stop it. This guide explains how the attack works, where it has been used since 2024, how to detect it in sign-in logs and how to block or tightly scope the device code flow. It is for identity engineers, Microsoft 365 and Entra administrators, and SOC analysts.

Key takeaways

The sign-in page is real. The victim authenticates on the legitimate IdP; the attacker only supplies the code, so lookalike-domain training and URL filters miss it.
The prize is a refresh token. Once approved, the attacker holds tokens that keep working after the 15-minute code expires, and in Entra can be used to register a device and obtain a Primary Refresh Token.
Most organisations can block the flow outright. Microsoft recommends blocking device code flow wherever possible using the Conditional Access Authentication flows condition, with narrow, documented exceptions.
Detection is straightforward if you look. Entra sign-in logs record the authentication protocol as Device code and keep an Original transfer method marker on refreshed sessions.
Response means revoking tokens and devices. A password reset alone is not enough: revoke sign-in sessions, remove attacker-registered devices and check for mailbox exfiltration.

How the attack works

In the legitimate flow defined by RFC 8628, a client with limited input calls a device authorization endpoint and receives a device_code (kept by the client), a short user_code, a verification_uri and an expires_in value. The user opens the verification URI on a phone or laptop, signs in and enters the user code. Meanwhile the client polls the token endpoint with grant type urn:ietf:params:oauth:grant-type:device_code, receiving authorization_pending until the user finishes, then an access token and, where requested, a refresh token.

The weakness is that the device asking for access is not the device where the user approves. RFC 8628 section 5.4 names this remote phishing risk directly: an attacker starts the flow on their own system and persuades the victim to enter the code. In Microsoft Entra the code is valid for 900 seconds (15 minutes) by default, which is why attackers build real-time pretexts.

Stage	What the attacker does (described defensively)	What the defender can see
Pretext	Builds rapport over email, Signal, WhatsApp or Teams, often impersonating an official or colleague	External messages, new contacts, meeting invites from unusual senders
Code delivery	Sends a fresh user code framed as a meeting ID, a one-time passcode or a document access check, often with a QR code	Email or chat links to device login URLs such as microsoft.com/devicelogin
Approval	Victim enters the code and completes MFA on the real IdP	Sign-in with authentication protocol Device code, sometimes from a different IP to the token redemption
Token use	Uses access and refresh tokens against Graph, mail and files	Non-interactive sign-ins from VPS, VPN or Tor addresses; scripted user agents
Persistence	Registers a device, obtains a PRT, sends internal phishing from the mailbox	Device Registration Service events, new devices, internal emails containing device login links

In ATT&CK v20 terms the delivery is T1566.002 Spearphishing Link, the outcome is T1528 Steal Application Access Token, followed by T1078.004 Valid Accounts: Cloud Accounts, T1098.005 Account Manipulation: Device Registration and T1114.002 Remote Email Collection.

Where it shows up

Storm-2372 (Microsoft Threat Intelligence): active since August 2024 and assessed by Microsoft as a suspected nation-state actor aligned with Russian interests. Targets included government, NGOs, IT services, defence, telecommunications, health, higher education and energy across Europe, North America, Africa and the Middle East. Lures were fake Teams meeting invitations where the device code posed as the meeting ID. Microsoft reported that within 24 hours of its first publication the actor switched to the Microsoft Authentication Broker client ID, used the refresh token to register an actor-controlled device in Entra ID and obtained a Primary Refresh Token.
Volexity reporting (February 2025): three clusters, UTA0304, UTA0307 and CozyLarch (which Volexity assesses overlaps with APT29), impersonated officials from the US Department of State, the Ukrainian Ministry of Defence and the European Parliament. Volexity notes that the 15-minute validity pushed attackers into live conversations, and one landing page generated fresh codes automatically.
Financially motivated campaigns (Proofpoint, December 2025): Proofpoint describes device code phishing becoming widespread from September 2025, including a financially motivated actor, TA2723, from October 2025, using shared-document lures, QR codes and codes framed as one-time passcodes. It also reports publicly available kits that automate the flow.
Beyond Microsoft: any IdP or SaaS provider that implements RFC 8628 for CLIs, smart TVs or developer tools offers the same pattern. Review which of your providers enable device authorization and whether it can be restricted.

The technique sits alongside other MFA bypasses; see the AiTM Phishing Guide for reverse-proxy phishing and the MFA Fatigue and Bypass Guide for push abuse. The Top 10 Phishing Techniques compares them.

Impact

Account takeover without credentials: the attacker never learns the password, so password resets and credential monitoring do not reveal or end the compromise.
MFA is satisfied, not bypassed: the victim completes the second factor themselves. Phishing-resistant methods protect the origin of the sign-in page, which here is genuine, so the token issuance looks normal.
Durable access: refresh tokens outlive the code, and a registered device with a PRT gives a further foothold that survives the original token's revocation unless the device is removed.
Data theft at speed: Microsoft observed Storm-2372 searching mailboxes through Graph for terms such as username, password, admin, credentials and secret, then exfiltrating matches. Volexity saw rapid OneDrive downloads with scripted user agents.
Internal spread: compromised mailboxes send further device code lures to colleagues, which arrive from a trusted internal sender.

Detection

Signal	Where to find it	Notes
Authentication protocol = Device code	Entra sign-in logs (interactive and non-interactive), field `authenticationProtocol` value `deviceCode`	Baseline legitimate users first; most users never use it
Original transfer method = Device code flow	Sign-in log Activity details, field `originalTransferMethod`	Flags later refreshes of a session that started with a device code
Clicks to device login URLs	Email and web proxy logs: microsoft.com/devicelogin, aka.ms/devicelogin, login.microsoftonline.com/common/oauth2/deviceauth	Microsoft's hunting query correlates clicks with risky sign-ins within minutes
Error 50199 followed by success	Sign-in logs, same session within about 5 minutes	Microsoft describes this pause-and-resume pattern as consistent with entering a phished code
New device registration	Audit logs and CloudAppEvents for the Device Registration Service	High priority if it follows a device code sign-in
Risk detections	Entra ID Protection: anonymizedIPAddress, investigationsThreatIntelligence	Feed into sign-in risk policies
Graph mail access	MailItemsAccessed audit, Graph activity logs	Keyword searches and bulk reads soon after a device code sign-in

Metrics that show it is working

Device code sign-ins per week, split into approved exceptions and everything else (target: zero outside exceptions).
Number of users and resources in the device code exception group, reviewed quarterly.
Time from a device code alert to session revocation and device removal.
Percentage of tenants or IdPs where device authorization is blocked or restricted.
Reported phishing messages containing device login URLs, as a measure of awareness.

Prevention and hardening

Block the flow with Conditional Access (Microsoft Entra)

Audit first: filter sign-in logs for the Device code authentication protocol over at least 30 days to find genuine users, such as Teams Rooms devices, digital signage or command-line tools.
Create the policy: in Entra ID, Conditional Access, Policies, New policy. Include All users; exclude break-glass accounts and an exception group. Target All resources.
Set the condition: Conditions, Authentication Flows, Configure Yes, select Device code flow.
Grant: Block access. Set Enable policy to Report-only and review the results.
Enforce: switch to On once report-only shows only expected hits.
Scope exceptions tightly: where device code is needed, allow it only for the named group, device platform and IP-based named location, as Microsoft's own example of Android conference room devices in a specific location shows.
Consider authentication transfer: the same condition can block moving a session from a PC to a phone by QR code for groups that should not use mobile access.

Rollback and side effects: Entra applies protocol tracking, so a session that started with device code stays tracked through refreshes and can be blocked later on a different resource. Blocked users see error AADSTS530036. Since September 2024 these policies also apply to the Device Registration Service when targeting All resources; it can be excluded (client ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) only if a legitimate need is proven. To roll back, return the policy to Report-only; affected devices may need a fresh sign-in. User-scoped policies do not apply to service principals, so cover those with Conditional Access for workload identities. See the Conditional Access Guide.

Supporting controls

Restrict device registration: limit who can register or join devices in Entra ID, and require MFA for registration, so a stolen token cannot easily become a PRT.
Require compliant or joined devices for access to mail and files; a token held on an attacker's system then fails policy, although Proofpoint notes such policies often carry exclusions.
Sign-in risk policies and continuous access evaluation: block or challenge risky sign-ins, and let CAE revoke access for high-risk users within minutes.
Token Protection for supported apps, so tokens must be device-bound. See the Session Hijacking and Cookie Theft Guide.
Mail and web filtering: flag or quarantine external messages that contain device login URLs, which legitimate business email rarely needs.
User guidance that matches the threat: never enter a device code you did not request on a device you are holding. Proofpoint stresses that URL-checking advice does not help because the page is genuine.
For application builders: follow RFC 8628 section 5.4 by telling users clearly that they are authorising a device, name the application and ask them to confirm the device is theirs; rate-limit user code attempts (section 5.1). See the OAuth 2.0 and OpenID Connect Guide.

Decision guidance

Situation	Recommended stance	Trade-off
No meeting room devices or CLI use found in logs	Block for all users and resources	Lowest risk; occasional helpdesk ticket for an unknown tool
Teams Rooms, signage or shared Android devices	Block everywhere except a device account group from a named location	Exception group becomes a target; review it quarterly
Developers using CLIs that default to device code	Move tools to interactive browser or broker sign-in; temporary exception with expiry	Some tooling changes; small productivity cost
Small organisation without Conditional Access licences	Check whether the IdP offers another control to disable the flow; monitor sign-in logs for Device code and train users	Detection only until a blocking control is available

Responding to a device code compromise

Revoke the user's refresh tokens and session cookies (Microsoft Graph revokeSignInSessions, permission User.RevokeSessions.All); expect a delay of a few minutes.
Find and delete devices registered around the time of the device code sign-in, and revoke their PRT by disabling the device.
Review MailItemsAccessed and file download events for the attacker session, and assess data exposure.
Search for internal emails from the account that contain device login URLs and warn recipients.
Check for new MFA methods, inbox rules and OAuth consents; see the Entra ID Applications and Consent Guide.
Close the gap: enforce the device code block, then follow the Phishing Incident Response Playbook for reporting and lessons learned.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK v20	T1566.002, T1528, T1078.004, T1098.005, T1114.002	Lure, token theft, cloud account use, device registration, mail collection
NIST SP 800-53 Rev. 5	IA-2, AC-12, SI-4	Authentication of users, termination of sessions, monitoring
NIST CSF 2.0	PR.AA-03, DE.CM-03, RS.MI-01	Authentication, monitoring personnel activity, containment
IETF	RFC 8628 section 5	Protocol-level security considerations for device authorization

Practitioner checklist

Query 30 days of sign-in logs for the Device code authentication protocol and list every genuine use.
Deploy a Conditional Access policy blocking device code flow for all users and resources in report-only, then enforce.
Limit exceptions to named device accounts, platforms and IP-based locations, with an owner and review date.
Restrict who can register devices in Entra ID and alert on registrations that follow a device code sign-in.
Alert on any sign-in with authentication protocol Device code or Original transfer method Device code flow outside the exception group.
Flag inbound email and chat containing device login URLs.
Add device code lures, including QR codes and fake meeting IDs, to awareness training.
Add token revocation, device removal and mailbox access review to the phishing response runbook.
Check every other IdP and developer platform you use for device authorization support and restrict it.

Device Code Phishing Guide: Detecting and Blocking OAuth Device Flow Abuse