The MFA bypass that uses a real login page: Device-code phishing

Device-code phishing sends users to a legitimate sign-in page and tricks them into authorizing an attacker. Learn about the attack and how to reduce risk.

Key takeaways

• Device-code phishing uses a legitimate sign-in page to trick users into authorizing a session initiated by an attacker.
• Checking the URL and completing MFA do not establish that the underlying request is legitimate.
• Defenses should connect email, identity, and post-authentication signals to detect and contain account compromise.
• Organizations should block unnecessary device-code authentication, restrict required use, and teach users to verify what they are authorizing.

Most employees know the rule: Before entering your credentials, check the URL.

This time around an employee receives an email about a shared file, an RFP, an invoice, or a voicemail. The message seems familiar enough, so they follow the instructions and receive a short verification code before they are directed to a legitimate device-login page.

The domain is real, the sign-in experience looks right, and the employee may even complete multifactor authentication exactly as they have been taught. Everything appears secure, but the employee is authorizing the wrong session.

A legitimate sign-in with a malicious beginning

The device-code authentication flow serves a legitimate purpose. It allows someone to sign in on a device with a limited interface, such as when an app displays a verification code that you enter in a browser on your laptop or phone to complete sign-in.

Device-code phishing turns that process against the user.

Instead of the employee’s device initiating the authentication request, the attacker starts the process and sends the resulting code to the employee. When the employee enters that code and completes authentication, they are not signing themselves in. They are authorizing the attacker’s session.

The attacker can then receive valid access and refresh tokens without collecting the employee’s password directly. Those tokens may provide access to email, cloud storage, and other services available to the compromised account for as long as the tokens remain valid.

To the employee, the experience can feel routine, especially if they are already signed in. To the authentication system, the employee has successfully approved the request.

That is what makes device-code phishing so deceptive: The final sign-in page is legitimate, but the request that led the employee there is not.

Why familiar phishing remedies may not be enough

Traditional phishing often depends on sending the user to a convincing imitation of a trusted sign-in page. Device-code phishing removes that obvious warning sign.

The employee may:

• Visit a legitimate domain
• Enter the verification code as instructed
• Complete MFA correctly
• Never provide a password to an attacker-controlled form
• See the normal authentication system approve the request

The problem is ultimately in what they are authorizing and who initiated the request.

That distinction is easy to miss, particularly when the attack begins with an ordinary business story. A request to review a document, listen to a voicemail, respond to an RFP, or approve an invoice gives the employee a reason to expect an authentication step. The legitimate page then reinforces the impression that the request is safe.

From targeted technique to scalable campaign

Device-code phishing isn’t just a clever proof of concept. Attackers are already using it in real-world campaigns, and the technique is getting more sophisticated.

Microsoft disclosed a campaign in February 2025 that used device-code phishing to capture authentication tokens and gain access to compromised accounts. By early 2026, attackers were combining the technique with automation, generative AI-written lures, and dynamically generated device codes.

That last piece matters. Device codes expire quickly, which once gave attackers a narrow window to convince someone to act. Newer attacks can generate the code when the victim reaches the final stage of the attack, giving them a fresh code right when they need it.

Ultimately, attackers are automating away some of the friction that once made this technique harder to scale.

The email is where the attack begins

The email gives the employee a believable reason to follow the process. It creates the urgency, supplies the business context, and moves the employee through a chain of links or attachments until they reach the real sign-in page.

Some campaigns use direct URLs. Others use PDF or HTML attachments and a series of redirects through legitimate or high-reputation cloud services. The goal is to make the journey feel credible while making it harder for defenses to evaluate the full attack chain.

That means looking only at the final destination is not enough. A legitimate authentication page can still be the last step in a malicious journey.

But the attack may not end there. Once an attacker gains access, they may use the compromised account to explore connected applications, access sensitive information, impersonate the user, or move further across the environment.

That makes the initial email only the first signal in a broader attack chain. Security teams also need visibility into what happens after authentication: how the account is used, which applications and data are accessed, whether new persistence mechanisms appear, and whether the attacker attempts to move laterally. Connecting signals across email, identity, cloud applications, and endpoint activity helps defenders understand the full scope of the attack and respond before a single compromised account becomes a wider incident.

Defenders need to understand the complete context:

• Who sent the original message?
• Why is the employee being asked to authenticate?
• What links and redirects brought them to the sign-in page?
• Which application or device are they being asked to authorize?
• Does the resulting activity match the employee’s normal behavior?
• What resources, applications, or data did the account access after authentication?
• Did the account create persistence, such as new inbox rules, application permissions, or device registrations?

Protecting the organization requires visibility across the complete attack chain, from the email that initiates the interaction to the authentication event, subsequent account activity, and the response needed to contain it.

How organizations can reduce the risk

Stopping device-code phishing requires controls across email, identity, and post-authentication activity. Organizations should consider the following protections:

• Block device-code authentication where it is not needed. If the organization does not have a legitimate business requirement for the flow, removing it reduces the attack surface.
• Restrict its use when it is required. Apply conditional access policies to control when and how device-code authentication can be used.
• Use phishing-resistant authentication. FIDO2 security keys and passkeys can provide stronger protection against phishing and credential theft.
• Teach users to verify the request, not just the website. Employees should confirm the application and initiating device before entering a code.
• Monitor authentication and post-compromise signals. Watch for unusual device-code sign-ins, suspicious token activity, unexpected device registrations, Microsoft Graph access, and new inbox rules.
• Respond quickly to suspected compromise. Revoke refresh tokens and take appropriate containment steps when malicious activity is detected.
• Analyze the entire email journey. Evaluate the sender, business context, attachments, redirect chain, authentication request, and activity that follows, rather than judging the final domain alone.

A real login page does not always mean a legitimate request

Device-code phishing works because it uses familiar security signals against the employee.

The website can be real. MFA can work correctly. The authentication system can approve the request. Yet the attacker can still walk away with access because the employee authorized a session the attacker initiated.

The takeaway here is that security teams cannot evaluate trust based only on the page where the user signs in. They must also understand who initiated the session, what the user is authorizing, and whether the request makes sense in its full business context.

As phishing techniques evolve, security teams must protect and understand the complete attack chain: the email that establishes trust, the authentication event that grants access, the account activity that follows, and any attempt to move further across the environment. Connecting those signals helps defenders detect account takeover sooner, understand its scope, and coordinate a faster response.