.svg){kind=small}
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
What is Device Code Flow Authentication in Microsoft 365?
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:
- Teams Rooms devices running embedded operating systems without a full browser
- Teams phones running Android with limited on screen input
- Conference room PCs built as hands free touchscreens rather than full workstations
- Embedded devices that need user level authentication without exposing credentials on a constrained interface
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.
How does a Device Code Flow Phishing Attack Work in Microsoft 365?
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.
Where to Find Device Code Flow Sign-Ins in Microsoft 365
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.
- Open the Entra admin center and navigate to Users, then Sign in logs
- Change the date range to the maximum one month window available in the interface
- Add a filter for authentication protocol and select device code flow
- Review the results for the accounts, devices, and locations using the method
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.
How do Conditional Access Policies Block Device Code 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.
- Clear naming that identifies the policy purpose and creation year for future auditability
- All users in the assignment scope, with the administrator building the policy excluded
- A break glass account exclusion to prevent tenant lockout scenarios
- All resources selected under target resources to cover every cloud app
- Device code flow selected under the authentication flows condition
- Block access as the grant control
Should the Policy be Deployed in Report Only Mode First?
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.
What Detection Tools Flag Device Code Flow Attacks?
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:
- Unusual IP address or a sudden change in source location
- Unfamiliar region that does not match the user's normal sign-in pattern
- New inbox rules created shortly after authentication
- Suspicious mail forwarding to external addresses
- Anomalous OAuth activity flagged by third party SOC platforms monitoring Microsoft 365 sign in data
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.
Close the Device Code Flow Gap in your Microsoft 365 Tenant
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.
