Blog · Deliverability
Device-Code Phishing: How Attackers Bypass MFA and Passkeys
Device-Code Phishing: How Attackers Bypass MFA and Passkeys
Device-code phishing is an attack technique that steals session tokens by making the victim complete a legitimate login on a different device or browser. MFA and passkeys do not stop it. The attacker simply waits for the token to be issued and grabs it.
This article explains exactly how the attack works, why your current MFA setup probably does not block it, and what controls actually help.
What Is the OAuth Device Code Flow?
The OAuth 2.0 device authorization grant, defined in RFC 8628, exists to solve a real problem: how do you log into a device that has no browser or a limited input method?
The classic example is a smart TV, a printer, or a CLI tool. You see a short code and a URL on the device, visit that URL on your phone or laptop, enter the code, and authenticate. The device polls the authorization server in the background and receives a token once you complete the login.
Microsoft uses this flow for Teams on smart TVs, the Azure CLI, and dozens of other input-constrained applications. So does Google. So do many third-party tools that need to authenticate against Microsoft Graph or Google Workspace.
The flow looks like this:
This is a legitimate, standards-based flow. The problem arises when an attacker inserts themselves into step 3.
How Attackers Use Device Code Flow in Phishing Attacks
The attacker's version of this flow is identical up to step 2. The victim receives a phishing email containing a device code and a URL. The victim visits the URL on their own device, sees a genuine Microsoft login page, and enters the code.
At this point, the victim is typing into the actual Microsoft login portal. Everything looks correct. The URL is real. The certificate is valid. MFA is triggered and the victim approves the push notification or enters their TOTP code.
While the victim is doing this on their phone or laptop, the attacker is polling the same authorization endpoint with the same device code. The moment the victim completes the login, the attacker receives the token. The attacker now has a valid session for the application, and the victim has no idea it happened.
The attack works because the victim did everything correctly. They logged into a real Microsoft page, entered a real code, and completed their MFA challenge. The authentication was genuine. The token is genuine. There is nothing for most security tools to flag.
A real example surfaced in January 2024, when Microsoft published guidance on device-code phishing campaigns targeting Entra ID tenants. The attack was specifically abusing the device code flow to obtain tokens for cloud applications, and the victims were completing full Microsoft MFA challenges before the attacker captured the resulting session.
Why MFA Does Not Stop Device-Code Phishing
This is the part that surprises people. MFA was supposed to stop phishing. Passkeys were supposed to end phishing. Neither of these controls blocks device-code phishing, and the reason is fundamental to how the attack works.
The victim is not being tricked into revealing their password or approving a fake MFA prompt. The victim is voluntarily completing a legitimate login page. The attacker is simply standing next to them in the network, waiting for the same credential to arrive at the authorization server.
With TOTP or push MFA, the victim enters their one-time code or approves the push notification on their own device. The attacker does not see this code. But it does not matter: the code or approval has already unlocked the token for whoever polls the endpoint next. The attacker and the victim are both waiting for the same authorization. The first one to poll after the authentication completes wins the token.
With passkeys, the situation is slightly different but the outcome is the same. Passkeys bind authentication to a specific device and require a local gesture (biometric or PIN). However, if a passkey is enrolled on the victim's device and the victim completes the passkey challenge as part of the device code login, the resulting token is still issued to whoever polls for it. The passkey protected the authentication ceremony, but the token delivery mechanism is where the attacker intercepts.
The root problem is that the OAuth device code flow was designed for scenarios where the user and the application are on different devices. That design assumption means the token is issued to whoever polls, regardless of who completed the authentication on the browser page.
How to Detect and Prevent Device-Code Phishing
Device-code phishing is not unstoppable. Several controls significantly reduce the risk.
Block Device Code Flow via Conditional Access
In Microsoft Entra ID, you can create a Conditional Access policy that blocks the device code flow for most users. Microsoft recommends targeting the "Register domain" resource application and blocking device code authentication for all users except those who explicitly need it for legitimate input-constrained devices.
For most organizations, disabling device code flow entirely is the right call. IT departments can enumerate legitimate uses before disabling the flow. Users who genuinely need device code authentication for CLI tools or kiosk devices can be added to an exception group.
Restrict Application Registrations
Device-code phishing campaigns need an application to authenticate against. Most real-world attacks target app registrations that were created by the attacker or by a compromised low-privilege user. Restrict who can create app registrations. Require admin consent for new app registrations. Audit existing registrations quarterly.
Monitor for Suspicious Token Issuance Patterns
Device code tokens are short-lived but immediately usable. Security teams should look for patterns like multiple tokens being issued to the same device code in a short window, or device code tokens being redeemed from IP addresses that do not match the user's normal range. In Entra ID, these show up as "Device code" sign-in events with unusual characteristics.
Train Users to Recognize Unsolicited Code Requests
Legitimate Microsoft login pages do not ask you to visit a URL and enter a code because someone sent you an email. If a user receives an unsolicited message asking them to visit a Microsoft login page and enter a code, that is a phishing indicator regardless of what the page looks like. This is true regardless of whether the page is actually Microsoft.
How DMARC Helps Against Phishing Emails That Deliver Device-Code Links
Device-code phishing campaigns arrive by email. The victim needs to receive the code and the URL somehow, and for most mass phishing operations, that means email. This is where DMARC adds a layer of protection that is independent of MFA or passkey adoption.
DMARC verifies that the From address of an email aligns with the sending domain's SPF or DKIM authentication. A Microsoft-themed phishing email that arrives with a spoofed From address will fail DMARC if the sending domain has a strong DMARC policy. Organizations that publish DMARC with policy p=reject tell receiving mail servers to discard emails where the From domain does not align with authenticated sending infrastructure.
This matters for device-code phishing because the phishing email often spoofs well-known brands. A victim who receives a "Microsoft security alert" email with a device code link is significantly less likely to encounter it if the sending domain has a strong DMARC policy blocking unauthenticated email.
Security teams can use DMARC monitoring to track when domains that look similar to Microsoft or other major brands are sending unauthenticated email. DMARCFlow generates alerts when Microsoft-themed domains fail DMARC checks, giving security teams early warning of phishing campaigns using their brand in spoofed From addresses, before those emails reach user inboxes.
Frequently Asked Questions
Can device-code phishing be blocked entirely?
Not without disabling the device code flow for all users. Conditional Access policies can block the flow for most users while preserving it for legitimate use cases. The practical goal is to make the attack much harder and to detect it when it happens.
Do FIDO2 passkeys stop device-code phishing?
No. Passkeys protect the authentication ceremony but not the token delivery. If a victim uses a passkey to log into the device code page, the attacker still captures the resulting session token by polling the authorization endpoint.
Is device-code phishing specific to Microsoft?
No. Any OAuth provider that implements RFC 8628 is theoretically vulnerable. The device code flow is an IETF standard used across many platforms. Microsoft Entra ID is the most commonly targeted in publicly documented attacks because of its enterprise user base, but Google Workspace and other OAuth providers use the same flow and face the same class of attacks.
How do I know if my organization has been targeted by device-code phishing?
Look for Entra ID sign-in logs showing device code authentication from unexpected IP addresses or user agents. Multiple device code authentications for the same user code from different IPs within a short window is a strong indicator of this attack technique.
---
Author: Editorial Team
Publish-Date: 2026-07-25
Source brief: 2026-07-25__device-code-phishing-bypassing-mfa-passkeys-brief.md
Refinement: R2 (2 rounds total)