Skip to content
Articles
Phishing

How to stop device code phishing in Microsoft 365

Attackers send a code and a real Microsoft link, and the user signs the attacker in, MFA and all. How device code phishing works, how to block it with Conditional Access, and why Browser Rules blocks it too.

14 October 2026 · Browser Rules · 6 min read

Most phishing tries to get a user’s password onto a fake page. Device code phishing doesn’t. The user signs in on Microsoft’s real page, completes MFA as normal, and in doing so signs the attacker in.

It has moved from targeted espionage to everyday crime. Microsoft reported a Russia-aligned group using it against governments and businesses from August 2024 (Microsoft). In February 2026 a phishing kit, EvilTokens, made it available to anyone. Within weeks it had compromised more than 340 Microsoft 365 organisations, including construction firms, charities, estate agents, law firms and local councils (Cloud Security Alliance).

How a device code attack works

Microsoft 365 has a sign-in method for devices without a keyboard, such as TVs, Teams Rooms devices and command-line tools. The device shows a short code, and you enter it on another device, at microsoft.com/devicelogin. Attackers turn that around:

  1. The attacker starts a sign-in on their own computer, and Microsoft gives them a code.
  2. They send the code to the user with a reason: a Teams meeting invite, a document to unlock, an invoice, an IT check.
  3. The user opens microsoft.com/devicelogin, Microsoft’s real page, and enters the code.
  4. The user signs in as usual, MFA included.
  5. Microsoft gives the attacker’s computer access to the user’s account: email, files and Teams.

That access can last for weeks, and changing the user’s password doesn’t end it (Cloud Security Alliance). Codes used to expire within 15 minutes, which limited attacks. Newer kits create the code at the moment the user clicks the link, so it’s always fresh (Microsoft).

Why it gets past other defences

  • The page is Microsoft’s own. Checking the address, which is what training teaches, shows a genuine Microsoft website.
  • MFA doesn’t help. The user completes it themselves, for the attacker.
  • No password is stolen, so password checks and leaked password alerts see nothing.
  • The message carries nothing harmful. Often it’s just some text, a code and a Microsoft link, which email filters let through.

The strongest control: block it with Conditional Access

Conditional Access can block device code sign-in for your whole Microsoft 365 tenant. It stops the sign-in at Microsoft, so it works on every device, browser and app, including a phone. Microsoft recommends getting “as close as possible to a unilateral block on device code flow” (Microsoft).

  1. In the Microsoft Entra admin center, open Entra ID, Conditional Access, Policies, and choose New policy.
  2. Under Users, include All users, and exclude your emergency access accounts, often called break-glass accounts. If a policy goes wrong, they’re how an admin still gets in.
  3. Under Target resources, include All resources.
  4. Under Conditions, Authentication flows, choose Device code flow.
  5. Under Grant, choose Block access.
  6. Set the policy to Report-only, check what it would have blocked, then turn it On.

Microsoft is also adding a ready-made policy, “Block device code flow”, to eligible tenants. It starts in report-only mode, and Microsoft turns it on no sooner than 30 days later unless you opt out (Microsoft). Look for it in your Conditional Access policies, created by Microsoft.

Some things legitimately need device code sign-in, such as Teams Rooms devices and some admin tools. Exclude those accounts only, and follow Microsoft’s guidance for Teams devices.

The catch: the licence

Conditional Access needs Microsoft 365 Business Premium, or Microsoft Entra ID P1 or P2. Many small businesses use Business Basic or Business Standard, which don’t include it. Security defaults, Microsoft’s free baseline, require MFA but don’t block device code sign-in.

Why Browser Rules blocks it too

Conditional Access is the better control. Browser Rules blocks device code sign-in as well, for the cases it can’t reach:

  • No Conditional Access. Organisations without Business Premium have no way to block it in Microsoft 365. The browser is the next place to stop it.
  • Personal Microsoft accounts. They have no Conditional Access at all. Browser Rules covers their device code page too.
  • A gap in a policy. A Conditional Access policy left in report-only mode, or with broad exclusions, lets attacks through. Browser Rules is a second layer.
  • Seeing it happen. Each attempt appears in the audit log, with the user and the time, so you know who was targeted.
  • The lesson at the right moment. The user sees your message on the page the attacker sent them to.

How it works

  • On by default. The default policy “Block Microsoft device code sign-in” covers Microsoft’s device code pages, for work and personal accounts, on every Microsoft sign-in website. The short links, such as microsoft.com/devicelogin, lead there and are blocked too.
  • Only those pages. Signing in to Microsoft 365 as usual isn’t affected.
  • Blocked before the page loads. Unusual forms of the address are blocked as the page loads.
  • Exceptions for IT. Add “Allow Microsoft device code sign-in for a group” from the Rule Library, and choose your IT group.
  • Or a warning instead. “Warn before Microsoft device code sign-in” asks users to continue only if they started the sign-in themselves.
  • No codes recorded. The audit log records the website and page, never a code.
  • Kept up to date. Browser Rules maintains the list of Microsoft’s device code pages, and changes reach enrolled browsers within minutes.

What Browser Rules doesn’t cover

  • Other devices and browsers. An attacker can ask the user to enter the code on their phone or a personal laptop. Conditional Access covers those; Browser Rules covers Chrome and Edge where it’s installed. That’s why Conditional Access comes first.
  • Other services’ device code pages, such as Google’s or GitHub’s.
  • Other sign-in tricks, such as fake sign-in pages that collect passwords.

A short checklist

  1. Check your Conditional Access policies for Microsoft’s “Block device code flow”, or create your own. Start in report-only mode.
  2. Exclude your break-glass accounts, and only the accounts that need device code sign-in, such as Teams Rooms devices.
  3. Search your Entra sign-in logs for device code sign-ins you don’t expect (filter Authentication protocol by Device code flow).
  4. Without Business Premium, keep Browser Rules’ default policy on, and consider upgrading.
  5. Tell staff: Microsoft never needs you to enter a code someone else sent you.

Getting started

Install Browser Rules from the Chrome Web Store, or deploy it with your device management tool. The default policies, device code sign-in included, protect users straight away. Browser Rules is free for up to 50 users.

See Default policies and Website policies.

Sources