Device code phishing: the real Microsoft page, the wrong person signed in.

What the attack looks like

You receive a message by e-mail, Teams, WhatsApp or LinkedIn: a shared document, a meeting invitation, a voicemail, an “account verification”. It contains a short code, such as KX7P-R2QM, and a link to microsoft.com/devicelogin. Sometimes a lure page shows the code next to a button that opens the real Microsoft page in a new tab.

You enter the code, choose your account, approve MFA. Microsoft then says you are signed in to an application on another device. That device belongs to the attacker, who now holds access and refresh tokens for your account: e-mail, OneDrive, Teams, often for weeks.

Why it works so well

• The address is real. Training says “check the address”; here it is microsoft.com.
• MFA is completed by the victim. The attacker never needs to break it.
• No password is typed into a fake form, so credential-phishing tools have nothing to catch.
• Kits make it easy. After the EvilTokens kit went on sale in February 2026, researchers counted many times more device-code phishing pages, and single campaigns reached hundreds of organisations.

How to protect your organisation

1. Block the device code flow in Microsoft Entra Conditional Access (Authentication flows → Device code flow) for everyone who does not need it. Keep an exception group for the few devices and tools that do.
2. Review sign-ins with the authentication protocol “device code” in the Entra sign-in logs, and revoke the sessions of any account that used it unexpectedly.
3. Tell people the rule: only enter a device code that you got from a device you are setting up, right now.
4. Warn at the moment it matters, in the browser, when the code page opens after a link from a message or another site.

What to do if you entered a code

1. Tell IT immediately, with the time and the message you received.
2. IT revokes the user’s sessions and refresh tokens in Entra (“Revoke sessions”) and checks the sign-in logs and mailbox rules (attackers often add forwarding rules).
3. Change the password and review the registered MFA methods.

How ByteMantle helps

• An immediate warning on Microsoft’s device login pages (including microsoft.com/devicelogin and the v2.0 endpoints), before the code is entered: “Someone may be trying to sign in to your Microsoft account”.
• “I started this sign-in — continue once”. People who really are setting up a device continue for five minutes, without turning protection off.
• Other providers stay quiet unless it looks wrong. Google, GitHub, AWS and Okta device pages are recorded, and become a warning when reached from a suspicious chain.
• The lure is traced. The console shows where the user came from and every redirect, so you can remove the message or block the lure site, not only warn about the Microsoft page.

More on Device Code phishing protection.

Questions people ask

Is microsoft.com/devicelogin a scam?

No, it is Microsoft’s real page for signing in devices such as TVs and command-line tools. It becomes dangerous only when someone else gives you the code to enter.

Does MFA protect against device code phishing?

No. You complete the MFA prompt yourself, and the attacker’s device receives the resulting tokens. Blocking the flow and phishing-resistant policies help; MFA alone does not.

How do I block the device code flow in Microsoft 365?

In Microsoft Entra, create a Conditional Access policy with the condition Authentication flows → Device code flow and the control Block, and exclude only the accounts or devices that need it.

Does the attack work against Google or other providers?

Google, GitHub, AWS and others have similar device sign-in flows and can be abused the same way, though Microsoft 365 is by far the most targeted.