Device Code phishing: the login page is real. The request isn’t.

Why it bypasses traditional controls

• The page is login.microsoft.com, so URL reputation and look-alike detection see nothing wrong.
• No password is typed into a fake form, so credential-phishing controls don’t fire.
• MFA is completed by the victim, so the attacker receives a valid token.

After the EvilTokens phishing kit went on sale in February 2026, researchers measured 37 times more device-code phishing pages than before, and a single campaign compromised more than 340 Microsoft 365 organisations.

How ByteMantle protects users

1. Microsoft device login pages (including v2.0 endpoints and microsoft.com/devicelogin) trigger an immediate warning before the code is entered.
2. The lure is traced: if the page was opened from a suspicious site, a blob document or a new-domain chain, that origin is recorded and scored.
3. “Proceed once” lets a user who genuinely started the sign-in continue for five minutes — without turning the protection off.
4. Google, GitHub, AWS IAM Identity Center and Okta device pages are recorded for visibility and escalated to a warning when reached from a suspicious chain, so legitimate CLI and TV sign-ins stay quiet.

How the user got there

Device Code lures arrive by e-mail, chat and shared documents. The incident shows where the user came from — web mail, another site, a search — and every redirect on the way to the device login page, so you can find and remove the lure, not only the page.

Pair it with Conditional Access

If nobody in your organisation needs the device code flow, block it in Microsoft Entra Conditional Access (Authentication flows → Device code flow) and keep ByteMantle as the browser-side safety net and early-warning signal for everyone else.

Read the guideDevice code phishing in Microsoft 365: how it works, how to stop it