Device Code Phishing: How Attackers Bypassed MFA on Microsoft 365 (A Real Case and How to Stop It)

Device code phishing attack on Microsoft 365 explained: how MFA was bypassed

The sign-in looked perfect. The user signed in from their own company laptop, with certificate-based authentication and MFA, on the genuine Microsoft sign-in page. Yet a few minutes later, a computer on the other side of Europe was registered in our Microsoft Entra ID as a trusted device, holding a token that would keep working even after the user's password was reset.

This is the story of a device code phishing attack I investigated, why MFA didn't stop it, and the exact steps every Microsoft 365 admin should take to block it. (The organization, user and device names are left out on purpose.)

It started with an ordinary-looking email

The user received an email saying a document had been shared with them. Instead of a link to a file, it said:

"Enter this code at microsoft.com/devicelogin to view the document: ABCD-1234"

Nothing about it looked dangerous. The link pointed to a real Microsoft website, not a fake login page, so link scanners and the user's own instincts saw nothing wrong. The user opened the page on their work laptop, typed the code and clicked through the prompts.

Microsoft even asked one extra question: "Are you trying to sign in to Microsoft Authentication Broker?" The user clicked Continue. That one click handed the attacker the keys.

What is the device code flow?

Device code sign-in is a legitimate Microsoft feature for devices that can't easily show a sign-in page, such as smart TVs, printers, conference-room systems and command-line tools. The device shows a short code, you enter it on your phone or laptop at microsoft.com/devicelogin, and the device gets signed in.

The weakness is simple: whoever requested the code receives the tokens. If an attacker generates the code and convinces you to enter it, you sign in their device.

How the attack worked, step by step

Attacker requests a codeFrom their own machine, the attacker starts a Microsoft device code sign-in and gets a short code. Their machine keeps polling Microsoft until someone completes it.

Code sent by emailThe attacker sends the code in a phishing email that points to the genuine microsoft.com/devicelogin page.

User signs in normallyOn their own laptop, the user enters the code. Certificate-based authentication and MFA succeed as usual, and the user confirms the Microsoft Authentication Broker prompt.

Token goes to the attackerMicrosoft issues the tokens to the device that requested the code: the attacker's machine on a hosting-provider IP in Europe.

MFA "satisfied by claim"The token already carries the successful MFA claim, so the attacker never has to pass MFA themselves.

Attacker registers a deviceUsing that token, the attacker joins their own computer to Entra ID and obtains a Primary Refresh Token (PRT) for long-term access.

Why MFA didn't stop it

This is the part that surprises most people. MFA did work. The real user passed every check on their real laptop. But in the device code flow, the token that proves "this person passed MFA" is delivered to the device that asked for the code, not the device where the user signed in.

In the Entra sign-in log, the attacker's sign-in looked like this:

Status: Success
Authentication requirement: "MFA requirement satisfied by claim in the token"
Error code before success: 50199 (the "are you trying to sign in to..." confirmation prompt)
Client app: Microsoft Authentication Broker
IP address: a data-center IP in another country

The Microsoft Authentication Broker detail matters. Microsoft Threat Intelligence documented the same technique in the Storm-2372 campaign: using the Broker's client ID lets the attacker request a token for the device registration service, register a device they control, and then obtain a Primary Refresh Token. A PRT is what your own Windows laptop uses for seamless single sign-on, and it can keep working even after the user's password is reset.

How we detected it

The clues were all in the logs. If you manage Microsoft 365, check for these:

Sign-ins using the device code flow. In the Entra admin center, open Sign-in logs and filter by authentication protocol for device code. Most users never need it, so any hit deserves a look.
Error 50199 followed by a success within a few minutes, especially for the Microsoft Authentication Broker app.
"MFA requirement satisfied by claim in the token" from an unfamiliar IP address or country.
New device registrations in the Audit logs (service: Device Registration Service) shortly after a suspicious sign-in, often with a device name that doesn't follow your naming standard.
Mailbox activity afterwards: new inbox rules, mail searches for words like "password" or "invoice", or internal phishing sent from the account.

What to do if it happens to you

Revoke all sessions for the user: in Entra ID, open the user and select Revoke sessions, or run Revoke-MgUserSignInSession -UserId user@domain.com in Microsoft Graph PowerShell.
Disable and delete the attacker's device in Entra ID > Devices. This is the step people forget, and it's what kills the PRT.
Reset the password and review the user's MFA methods; remove anything the user didn't add.
Check the mailbox for forwarding rules, inbox rules and sent items, and review OAuth app consents.
Search for other victims: the same email usually goes to several people.

How to prevent device code phishing

1. Block the device code flow with Conditional Access

Microsoft recommends getting as close as possible to a complete block. In the Microsoft Entra admin center:

Go to Entra ID > Conditional Access > Policies > New policy.
Include All users and exclude your emergency (break-glass) accounts.
Target All resources.
Under Conditions > Authentication flows, select Device code flow.
Under Grant, choose Block access.
Start in Report-only mode to find legitimate uses (for example, meeting-room devices), allow only those, then switch the policy On.

See Microsoft's guide: Block authentication flows with Conditional Access.

2. Lock down device registration

Restrict who can register or join devices in Entra ID > Devices > Device settings.
Create a Conditional Access policy for the Register or join devices user action that requires MFA from a trusted location or compliant device.
Alert on new device registrations that don't match your naming convention.

3. Make tokens harder to misuse

Require compliant or hybrid-joined devices for access to sensitive apps.
Use sign-in risk policies and Continuous Access Evaluation so risky sessions are cut off quickly.
Move users to phishing-resistant MFA such as passkeys or FIDO2 security keys.

4. Teach users one simple rule

Never enter a code that someone else sent you. A genuine device code sign-in only starts from a device you are setting up, right in front of you, such as your TV or printer. If an email, chat or caller gives you a code for microsoft.com/devicelogin, it's an attack.

Key takeaways

The user signed in on the genuine Microsoft page, and MFA succeeded as normal.
Microsoft issued the token to the device that requested the code: the attacker's machine.
The sign-in log showed "MFA requirement satisfied by claim in the token" after error 50199.
The attacker registered their own device and got a Primary Refresh Token that survives a password reset.
Blocking the device code flow, restricting device registration and revoking sessions plus deleting rogue devices shuts this attack down.

FAQ

Is microsoft.com/devicelogin a fake website?

No, it's a genuine Microsoft page. That's exactly why this attack works: the danger is the code, not the website.

Does changing the password stop the attacker?

Not on its own. You must also revoke the user's sessions and delete any device the attacker registered, because a Primary Refresh Token can keep working after a password reset.

Will blocking device code flow break anything?

Possibly a few things, such as some meeting-room devices, older command-line tools or shared devices. That's why Microsoft recommends starting in report-only mode and allowing only documented exceptions.

Want more security guides? Read about signs your phone is hacked and finding your BitLocker recovery key.

Sources: Microsoft Threat Intelligence, "Storm-2372 conducts device code phishing campaign" (February 2025, updated); Microsoft Learn, "Block authentication flows with Conditional Access policy".