Anyone who has set up a new TV knows the feeling. You open Netflix or Disney+, and there’s an on-screen keyboard, and you’re trying to enter an email address and a 16-character password using a directional pad and an OK button. Right arrow, right arrow, down, select. Wrong character. Back. Now do the password, which has a symbol in it, which lives on some other keyboard screen you have to hunt for. Ten minutes later you have four apps left to go.

So the streaming services fixed it. Now the TV shows you a short code and a URL, you pull out your phone, type in the code, log in normally with your fingerprint or your password manager, and the TV lights up. No remote-control typing at all.

That’s the OAuth 2.0 device authorization grant, usually called device code flow. It’s a genuinely good piece of design, and attackers have figured out that it works just as well on your email.

Why the flow exists

Device code flow was built for one specific problem: a device that needs to authenticate but has no reasonable way to accept typed input, or no browser at all. Smart TVs, streaming sticks, conference room displays, IoT hardware, printers, command-line tools on a headless server.

The mechanics are simple:

1. The input-limited device asks the identity provider (Microsoft, Google, whoever) to start a login and gets back a short code.
2. The device shows you that code and a URL, like microsoft.com/devicelogin or google.com/device.
3. You go to that URL on a device with a real keyboard, enter the code, and sign in normally: password, MFA, security key, all of it.
4. The identity provider hands the original device an access token, and the TV logs in.

The important part, and the part attackers care about, is step 4. Two separate devices are involved, and the one that receives the token is not the one where you typed your password. That separation is the whole point of the design. It is also the whole vulnerability.

The same convenience, pointed at your inbox

Here’s the attack. Instead of a smart TV, the attacker’s own machine starts a device code login against your Microsoft 365 or Google Workspace tenant. The identity provider issues a code. The attacker now has roughly fifteen minutes of validity on that code, and one job: get an employee to enter it.

So they send a message. It looks like IT:

“We’re migrating everyone to the new Teams environment today. Please go to microsoft.com/devicelogin and enter code D9KTXP4M to keep your access.”

Or it’s a meeting invite, or a request to “verify your account,” or a message from a compromised partner mailbox that has real history behind it. The employee goes to the URL, which is the actual Microsoft URL, sees the actual Microsoft sign-in page, enters their actual credentials and MFA, and lands on a genuine Microsoft success page.

Everything they see is real. And the token goes to the attacker.

Why your good MFA doesn’t save you here

This is the part worth sitting with, because it inverts advice that’s otherwise correct.

Phishing-resistant MFA works by binding the authentication to the origin of the site you’re logging into. A FIDO2 key or passkey simply won’t complete the exchange with micros0ft-login.com, no matter how convincing the page looks, because the cryptography is tied to the real domain. That defeats adversary-in-the-middle phishing kits completely.

Device code phishing doesn’t use a fake domain. There’s nothing to proxy and nothing to spoof. The victim authenticates against the real identity provider, on their own trusted device, with their real security key, and the flow succeeds exactly as designed. The security key does its job perfectly. It just authorizes a device that belongs to someone else.

What the attacker receives is not a password. It’s a token pair: an access token and, more painfully, a refresh token. The refresh token is the durable one: it lets them mint new access tokens for as long as it stays valid, without ever touching the login page again. Resetting the victim’s password does not invalidate it. That’s why device code compromises so often look like an account that was “cleaned up” weeks ago and is still quietly sending mail.

We traced a recent incident response investigation back to exactly this. No credential harvesting page, no lookalike domain, no malware. The sign-in that started it was a legitimate, fully MFA-satisfied authentication in the tenant’s own logs. The only thing that distinguished it was the authentication protocol.

Blocking it in Microsoft 365

Microsoft gives you a clean answer here, and most organizations should take it.

Entra ID Conditional Access includes a block authentication flows policy that turns device code flow off at the tenant level. Microsoft’s own guidance is unusually blunt about this. The docs call device code flow “a high-risk authentication method that can be part of a phishing attack or used to access corporate resources on unmanaged devices,” and say plainly: “Microsoft recommends blocking device code flow wherever possible.” The posture to aim for is block device code flow for all users, then add narrow exclusions for the systems that genuinely need it.

Before you flip it, audit. In the Entra admin center under Monitoring & health → Sign-in logs, add the Authentication protocol filter and select Device code flow. That tells you who in your tenant is completing these sign-ins today and why. Expect a small number of legitimate cases:

• Conference room and shared-display devices like Teams Rooms, Surface Hubs, and digital signage
• Command-line tooling on headless servers, where engineers use flags like az login --use-device-code because there’s no browser on the box
• Occasional line-of-business hardware with no usable input method

Those get an exclusion group, scoped as tightly as you can manage, ideally combined with a device or location condition. Exclude your break-glass accounts too, as you would from any blocking policy, and re-audit the exclusion list on a schedule so it doesn’t quietly grow. Everyone else gets blocked. For most small and mid-sized organizations, the honest audit result is that nobody legitimately needs it and the policy can go in clean.

The licensing caveat is the usual one: Conditional Access requires Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5. On Business Standard or below, this policy isn’t available to you, which is one more entry on the list of controls that quietly depend on your license tier.

Google Workspace: no single switch

Google doesn’t give you the equivalent toggle. There’s no tenant-wide setting or Context-Aware Access rule that says “block the device authorization grant,” so the mitigation is indirect: instead of blocking the flow, you control which applications are allowed to hold tokens for your users at all.

In the Admin Console, under Security → Access and data control → API controls:

• Use Manage App Access to mark third-party apps as Trusted, Limited, or Blocked.
• Under App access control settings, set unconfigured third-party apps to be restricted or blocked from sensitive Google Workspace scopes. This is the important one, because it flips the default from “any app your users approve” to “only apps you’ve vetted.”

Layer on top of that:

• Context-Aware Access (Enterprise editions, or Cloud Identity Premium) to condition access on device posture, OS, and IP.
• Devices → Mobile & endpoints → Endpoints to block specific enrolled devices from organizational data.

It’s a weaker control than Microsoft’s outright block, and it’s worth being clear-eyed about that. What it does is shrink the set of client applications an attacker can obtain a token for, which removes most of the convenient off-the-shelf options.

Teach the tell

There’s a user-facing rule here that’s unusually clean, which makes it worth putting in your security awareness material verbatim:

No legitimate IT process will ever send you a code to type into a login page. Codes flow out of the thing you’re setting up, off a TV screen or a printer display, and into your browser. If a code arrives by email, chat, or phone call and someone asks you to enter it at a Microsoft or Google URL, that’s an attack, every time, with no exceptions worth teaching.

That single sentence generalizes past device codes, too. It covers MFA fatigue, and it covers the “read me the code we just texted you” account-takeover call.

If you think this already happened

The eviction steps are the ones that deal with tokens, not passwords. A password reset alone will not remove an attacker holding a refresh token:

1. Revoke all refresh tokens and active sessions for the affected account. This is the step that actually ends their access.
2. Reset the password and re-enroll MFA methods, removing anything unfamiliar.
3. Review OAuth app grants and revoke anything you don’t recognize.
4. Audit inbox rules and forwarding, screenshotting before you delete.
5. Check the sign-in logs for other accounts that completed device code sign-ins in the same window. These campaigns rarely target one person.

Then work out the scope: what the token could reach, how long it was valid, and whether that triggers any notification obligations. That’s the work our BEC incident response service covers, and it’s the same investigation whether the entry point was a stolen session, a phished password, or a device code.

If you’d rather find out where you stand before something happens, a SaaS Security & Access Assessment covers this alongside the rest of your Conditional Access posture and license entitlements. And if you’re dealing with an active compromise right now, call us at (608) 448-6075 or email with INCIDENT in the subject line.