The Microsoft sign-in method you should probably turn off
Device code flow was built for smart TVs and meeting room screens. It is now a reliable way to take over an account without ever seeing the password.
On 22 September Microsoft's Digital Crimes Unit took down EvilTokens, a phishing service sold on Telegram that ran exactly the attack described below. Microsoft says it compromised more than 12,000 Microsoft 365 mailboxes at over 10,000 organizations since February. Fifty websites were seized and two men were arrested in London.
What its customers did after getting in is the part worth knowing. The kit included a chatbot that read the stolen mailbox, worked out who approves payments, and drafted the fraud email. Device code phishing is now often the first step of invoice fraud, which we cover in The invoice that came from your supplier's real mailbox. The takedown removes one service. The technique still works anywhere device code flow is left open.
Ask most people what phishing looks like and they will describe a fake login page. You type your password into something that resembles Microsoft, somebody catches it, and multi-factor authentication is the thing that saves you. That description has been out of date for a while.
Device code phishing does not need your password at all. It does not need to fake anything either, which is what makes it awkward to train people out of. Every screen the victim sees is a real Microsoft page on a real Microsoft domain, and the multi-factor prompt is a genuine prompt for a genuine sign-in. It is simply not their sign-in.
What the feature is actually for
Some devices cannot reasonably show a login form. A meeting room display, a streaming stick, a PowerShell session on a machine with no browser. Microsoft's answer is device code flow: the device shows a short code, you go to a Microsoft page on your phone, type the code in, approve, and the device ends up signed in as you.
It is a sensible design with one assumption baked into it. Whoever approves the code is assumed to be the same person who asked for it. There is no way for Microsoft to verify that, because the two halves of the transaction happen on different machines and the whole point is that they are not linked.
The attacker starts a device code request against Microsoft and receives a code, valid for about fifteen minutes.
They get the target to that code, usually through a link that looks like a document, a scheduling page or an IT notice. The page does the entering for them, or asks them to.
An authenticator prompt appears. In context it reads as the step required to open whatever they were promised, so it gets approved.
Microsoft issues a token to the attacker's session. They keep it alive with refreshes and read mail and files through Graph. No password change, no forwarding rule, nothing the user can see.
Password resets do nothing against this. The password was never involved, and a refresh token issued before the reset keeps working afterwards. Revoking sessions is the step that ends it, which is not most people's first instinct.
Why the usual advice fails here
Check the URL before you sign in. Good advice, and useless here, because the URL is microsoft.com. Look for the padlock. Also fine, also useless. Make sure MFA is on. It was on. The attacker wanted it on, because the approval is what completes the theft.
The one rule that does hold is about timing rather than appearance: an authenticator prompt should arrive because you typed your own password a second earlier. If one turns up after you clicked a link, something else asked for it.
Turning it off
Conditional Access can block device code flow outright, under authentication flows. If you have Entra ID P1, which comes with Business Premium, you already have the license for it.
Before you switch it on, spend ten minutes in the sign-in logs filtering for device code as the authentication protocol. In most offices the result is zero, or a handful of entries from one engineer running PowerShell on a jump box. Occasionally you find a Teams Room device or an old scanner depending on it, in which case exclude that identity and block everyone else. What you want to avoid is discovering the dependency at nine on a Monday.
Two other settings are worth pairing with it. Requiring a compliant, managed device turns an attacker's unmanaged session from an alert into a refusal, which is a much better outcome. And if nobody is reading Entra ID Protection risk alerts, this is one of the few attacks that produces no user-visible symptom at all, so the alert is the only signal you get.
Worth noting that Microsoft is retiring the risk policy interface in Entra ID Protection on 1 October 2026. Those controls move to Conditional Access and they do not migrate themselves.
One sentence for your staff
Only approve a sign-in prompt you started yourself. If one appears and you were not signing in, decline it and tell IT, and nobody will mind that you asked.
If you want us to check whether device code flow is open in your tenant, it takes about fifteen minutes and we will tell you either way.