Microsoft blocked device code flow, probably not in your tenant

Two Microsoft documentation pages disagree with each other in a way that is easy to miss and expensive to get wrong.

The first says that since July 1, 2026, every new Microsoft Entra tenant blocks device code flow as part of security defaults [1]. The second lists the policies Microsoft offers you when you upgrade from security defaults to Conditional Access, and there are four of them: block legacy authentication, and three flavours of require MFA [2]. Blocking device code flow is not on that list.

The same page that tells organisations with P1 or P2 licences that security defaults are “probably not right for you” is the page whose upgrade path quietly drops one of the protections you had [1]. If you followed Microsoft’s own advice and moved to Conditional Access, you may have turned this off without ever deciding to.

The core issue

Device code flow exists for a sensible reason. Some things that need to sign in cannot show you a browser or take a password: a conference room display, a printer, a streaming box. So Microsoft lets that device show a short code, and you go to a normal browser on your phone or laptop, enter the code, and authenticate there. The device gets tokens. Nobody types a password into a television.

The abuse is obvious once stated. Nothing ties the code to the device that asked for it. An attacker requests a code from Microsoft, sends it to a victim with a plausible reason to enter it, and collects the tokens that the victim’s genuine sign-in produces.

Microsoft’s own description is blunter than most vendor writing: device code flow is rarely used by customers, and frequently used by attackers [2].

Read the second half of that sentence next to the first. The feature is close to dead weight in most tenants and it is load-bearing for the people attacking them.

Why this matters

The victim does everything right. They are on login.microsoftonline.com. The certificate is valid. The MFA prompt is real and they answer it honestly. No credential is captured, because none is needed. Awareness training that teaches people to check the domain has nothing to catch here, because the domain is correct.

Your logs will show a clean sign-in, since that is what happened. There is no failed authentication, no impossible travel at the moment of compromise, no password spray pattern. A successful interactive sign-in with satisfied MFA is the most boring row in the table.

There is no CVE. I searched NVD for this on August 31, 2026 and got nothing back, which is the correct result rather than a gap in the search. This is a protocol feature working as specified. No CVSS score, no KEV entry, no patch Tuesday, no due date. Every process that waits for a CVE before it moves will wait forever on this one, and this blog has spent the last fortnight on the limits of severity-driven prioritisation, so it is worth naming the case where the input does not exist at all.

The access outlasts the phish by months. One vendor analysis of a platform built around this flow describes refresh tokens being exchanged on a schedule to hold mailbox access for up to ninety days per compromised account [3]. The phishing email is a Tuesday. The consequence is a quarter.

Technical breakdown

The sequence below follows the platform Abnormal AI documented in April 2026 [3]. The parts worth your attention are the middle, where the attacker stops doing anything illegitimate, and the end, where a single email buys a season.

Three things in that chain deserve more than one line.

The mail passes authentication because it is authentic. It comes from a real mailbox that someone else already lost. SPF, DKIM and DMARC are answering a question about domain control, and they answer it correctly. The received wisdom that authenticated mail is safer mail is true on average and useless here.

The middle of the chain is not an attack. From the moment the code is displayed to the moment tokens are issued, every action is a supported use of a documented feature. There is no exploit, no injection, no malformed request. This is why detection is hard and why the control has to sit at the policy layer rather than the analytics layer. You cannot write a rule that distinguishes a device code sign-in an attacker wanted from one a conference room wanted, because at the protocol level there is no difference. You can decide that your organisation does not do device code sign-ins at all, which is a different and much easier question to answer.

The tokens are the product. The whole sequence exists to obtain them, and they are what persists. Revoking a password does nothing to a live refresh token, which is the detail that turns a contained incident into a recurring one when the response team resets credentials and stops there.

What defenders should do Monday morning

Immediate, within 24 hours. Open Conditional Access and look for a policy named Block device code flow. You are checking three things and all of them matter: whether it exists, whether it is On rather than Report-only, and whether someone excluded a group from it. Microsoft-managed policies arrive in report-only and switch on by themselves no sooner than thirty days later, and an administrator can set them to Off at any point [2]. If the policy is absent, create one that blocks device code flow for all users and all resources.

Then check whether security defaults are enabled in your tenant, because that answers the same question a different way. If you are on P1 or P2 and following Microsoft’s guidance, security defaults are almost certainly off [1], and the block came with them.

Near term, this week. Put the policy in report-only if it is not already, and read the sign-in logs for device code authentications before you enforce. This turns the question of what breaks from a guess into a list. Expect Teams Rooms hardware and similar shared devices to appear; Microsoft publishes guidance for scoping those exceptions while keeping the block for everyone else [2].

Enable Continuous Access Evaluation if it is not on, so that revocation is close to immediate rather than waiting for a token to expire [3]. Then write down what your incident response actually does about tokens. If your account compromise runbook says reset the password and re-register MFA, and does not say revoke sessions and refresh tokens, it is a runbook for a different decade.

Structural, this quarter. Treat authentication flows as configuration you own rather than defaults you inherit. Device code flow is the one being abused today; the general lesson is that a tenant accumulates enabled capabilities nobody chose and nobody reviews. Schedule a review of which authentication flows your organisation permits and why, and make the answer to “why is this on” something other than that it was on when you got here.

Add one item to your migration checklist while you are at it. When a platform offers an upgrade path, compare what you had against what the path gives you, because Microsoft’s own upgrade list is four policies and the thing you are reading about is not one of them [2].

Checklist

• A Conditional Access policy blocking device code flow exists in the tenant
• That policy is On, not Report-only
• Group exclusions on it are reviewed and each one is justified in writing
• Sign-in logs have been checked for existing device code authentications
• Exceptions are scoped to named shared devices, not to whole user groups
• Continuous Access Evaluation is enabled
• The account compromise runbook revokes sessions and refresh tokens, not only passwords
• Security defaults status is known and deliberate rather than inherited
• The set of permitted authentication flows has an owner and a review date

The default you never chose

The interesting failure here is not that anyone made a bad decision. It is that the decision was never presented as one.

An organisation that started on security defaults had this blocked. It grew, it bought P1 or P2 licences, it followed Microsoft’s advice to move to Conditional Access for the customisation it needed, and it implemented the four policies on the upgrade list. Every step was reasonable and recommended. The device code block fell out somewhere in the middle, and nothing in the process announced that it had.

That is the pattern worth naming, and it is not specific to Microsoft. Security posture erodes most reliably at migration boundaries, because the new thing is evaluated on what it adds and almost never on what it silently stops doing. Upgrade paths are written by people who want you to move, and a complete list of what you are giving up is not what that document is for.

So the question to carry out of this is not whether you blocked device code flow. It is what else came off during the last platform migration you signed off on, and whether anyone wrote it down.