OAuth Device Code Phishing:
MFA Bypass via a Legitimate Flow.

Device Authorization Flow

The OAuth 2.0 Device Authorization Grant (RFC 8628) solves a real problem: how do you authenticate a device that has no browser or limited input capability — a smart TV, a network switch, a CLI tool? The solution is out-of-band authentication: the device displays a URL and a short user code; the user visits the URL on a different device, enters the code, and authenticates. The device polls the authorization server until the user completes authentication, then receives an access token.

From a security perspective, this flow was designed for legitimate use by authenticated client applications. The security assumption is that the device code was generated by a legitimate application that the user chose to use. This assumption breaks when attackers generate device codes themselves and socially engineer users into authorizing them.

The Phishing Attack

The attack execution is straightforward. The attacker initiates a Device Authorization request to the target identity provider (Microsoft Entra ID, Google, Okta) for a well-known application client ID — Microsoft Teams, Microsoft 365, VS Code, or another client that users routinely authorize. They receive a device_code and a user_code.

The attacker sends the user code and the verification URL to the target via email, Teams message, or SMS. The social engineering pretext can be: "Your new laptop registration code is...", "Please verify your device for the security audit:", or "Your IT helpdesk session code:". The URL they send is the real identity provider's device login URL — microsoft.com/devicelogin, for example. There is no fake domain to detect.

The target visits the real URL, sees a real Microsoft login page, enters the user code, performs MFA, and sees "Access granted" or similar. They believe they have completed a legitimate device registration. In the background, the attacker's polling request receives the access token and begins using the account.

Why MFA Doesn't Help

Traditional phishing is defeated by phishing-resistant MFA (FIDO2/Passkeys) because the MFA credential is bound to the legitimate domain. When the user authenticates to a phishing site, the MFA credential refuses to work because the domain does not match.

Device code phishing bypasses this entirely because the user is authenticating to the real identity provider domain. Their phishing-resistant MFA works perfectly — it is authenticating to the correct domain. The problem is not the authentication; it is what was being authorized. The user completed authentication to grant access to the attacker's device session, not to their own legitimate session.

Observed in the Wild

Device code phishing has been attributed to multiple nation-state groups since at least 2021. The technique is particularly effective against organisations using Microsoft 365 because of the large number of legitimate Microsoft first-party applications (Teams, Azure CLI, VS Code) whose client IDs are public and can be used to initiate device flows. These well-known client IDs produce an OAuth consent page that names a familiar, trusted application — reducing the victim's suspicion further.

The attack has been adapted by criminal threat actors as a complement to traditional business email compromise. Where BEC requires a convincing email from a spoofed or compromised domain, device code phishing requires only a message with a legitimate URL and a short user code — substantially lower sophistication and infrastructure requirements.

Detection

Detection of device code phishing requires visibility into OAuth device flow events in your identity provider's audit log:

• Device code authentication from user accounts without corresponding device registration: A user completing a device code flow should produce a corresponding registered device in your device management system. Authentications without a registered device outcome are suspicious.
• Device code flows for client IDs not in your approved application list: Maintain a list of client IDs for applications you have approved for use in your organisation. Device flows for client IDs outside that list — especially for well-known Microsoft first-party clients that you have not deployed — should be reviewed.
• Subsequent access from anomalous IP addresses: After a device code phishing attack succeeds, the attacker uses the token from their infrastructure. Access to M365, SharePoint, or Exchange from an IP address that does not match the user's normal geographic location within minutes of a device code authentication event is a strong signal.
• Security Awareness Training gaps: Victims of device code phishing frequently do not know they have been compromised. Including device code phishing scenarios in security awareness training and phishing simulations is necessary for users to recognise the social engineering pretext.

Mitigations

1. Disable the Device Authorization Grant for your tenant if not needed: In Microsoft Entra ID, the Device Code Flow can be blocked using Conditional Access policies. If your organisation does not have legitimate use cases for the device flow (smart TVs, CLI tools authenticating as users), disabling it removes the attack surface entirely.
2. Block device flows from outside managed devices: If you cannot disable device code flow entirely, restrict it to requests originating from compliant, managed devices using Conditional Access device compliance policies. Attacker-initiated device flows from unmanaged infrastructure will be blocked.
3. Implement application allow-listing: Configure your tenant to only allow OAuth flows for pre-approved application registrations. Block access token issuance for unapproved client IDs, including unapproved Microsoft first-party client IDs.
4. Educate users about device code social engineering: Standard phishing training does not cover device code phishing. Add it explicitly. Users should understand that entering a code on a login page — even a real one — grants access to whoever asked them to enter it, which might not be IT helpdesk.
5. Monitor for anomalous post-authentication activity: Deploy SIEM rules that correlate device code authentications with subsequent access patterns. Rapid mailbox enumeration, bulk file download, or email forwarding rule creation following a device code authentication are post-compromise indicators.