The most dangerous Microsoft 365 attack right now is the one that does not look like an attack.
No failed logins. No MFA bypass alerts. No impossible travel flags. Just a user who authenticated correctly, tapped their FIDO2 key, and unknowingly handed a threat actor a fully trusted access token. Device code flow phishing has already hit over 300 Microsoft 365 organizations across five countries, and the identity controls most IT teams rely on did not catch it.
Device code flow is a legitimate Microsoft 365 authentication method built for devices that cannot run a full browser, such as Teams Rooms, Teams phones, conference room PCs, and embedded Android devices. The same workflow that makes shared devices usable also gives attackers a clean path to capture access tokens from users who pass every identity check in the tenant.
IT teams responsible for Microsoft 365 security, conditional access, and identity governance need a clear view of how the attack works, how to audit device code flow usage, and how to block it without breaking the shared devices that depend on it
Device code flow is an OAuth authentication method designed for devices with limited input capabilities. The device displays a short code and a Microsoft sign-in URL, the user opens that URL on a separate device with a full browser, enters the code, and completes authentication using their normal credentials and MFA. Once approved, the original device receives a token and operates as the signed in user.
The workflow exists for good reason. Common use cases are:
The challenge is that Microsoft 365 enables device code flow by default for every user in the tenant, not just the devices that need it. That default state is what turns a useful authentication method into a tenant wide attack surface.
In this episode of the Demystifying Microsoft podcast, Nathan Taylor breaks down how device code flow phishing works, walks through the Entra admin center to audit device code authentication events, and builds a conditional access policy live to block the flow across an entire tenant. The episode also covers how to scope exclusions for legitimate shared devices and how report only mode can validate the policy before enforcement.
A threat actor initiates a device code flow request against Microsoft 365 and receives a valid six digit code tied to a real authentication session. The attacker then sends that code to a target user through a phishing message that mimics a legitimate prompt, often referencing a Teams device, a conference room, or an internal IT request. The user opens the Microsoft sign in URL, enters the code, and authenticates with their own credentials, MFA prompt, and even a FIDO2 key or passkey.
Microsoft validates the authentication because it is real. Every control fires correctly. The token that comes back, however, is delivered to the attacker's session rather than the user's device. The attacker now holds an access token that passed every identity check in the tenant.
Before blocking device code flow, IT teams need to know which accounts and devices are actively using it. The Entra admin center sign in logs surface every device code authentication event in the tenant when filtered correctly.
The audit workflow looks like this.
Most environments will see device code flow tied to Teams Rooms, Teams phones, or specific conference room hardware. Auditing first prevents an enforcement policy from breaking shared devices that legitimately depend on the flow.
Conditional access is the enforcement layer for identity in Microsoft 365. A policy scoped to all users, all resources, and the device code flow authentication flow under conditions, with a grant control set to block access, shuts down the attack vector tenant wide.
A well built conditional access policy for device code flow typically includes the following elements.
Report only mode runs the policy logic against live sign-ins without enforcing the block. For organizations that have not audited device code flow usage or that operate large fleets of Teams Rooms and shared devices, a week in report only mode confirms that no legitimate authentication is being blocked. Once the report is clean, the policy can be switched to enforcement.
Microsoft Defender for Office 365 and Entra ID P2 treat device code flow as a higher risk authentication event and apply risk based signals to surface suspicious sessions.
Common signals include the following:
Prevention through conditional access is still the cleaner control, but advanced detection adds depth for the accounts and scenarios that must allow device code flow.
Device code flow phishing is one of the cleanest ways an attacker can sidestep a mature identity program in Microsoft 365. Auditing usage, deploying a scoped conditional access policy, and layering detection through Defender for Office 365 and Entra ID P2 closes the gap without disrupting the shared devices that depend on the flow.
Sourcepass Center of Excellence for Microsoft helps IT teams audit device code flow exposure, build conditional access policies that hold up under attack, and harden Microsoft 365 tenants against token theft and OAuth abuse. Want a conditional access review to close the device code flow gap in your tenant? Contact our team to walk through your tenant configuration and identify where device code flow exposure exists today.
Subscribe to the Demystifying Microsoft podcast for new episodes on Microsoft 365 security, identity, licensing, and the architectural decisions IT teams are making every week.