Device code flow is a legitimate Microsoft OAuth mechanism designed for devices without keyboards or browsers — meeting room hardware, smart TVs, IoT devices. The flow generates a short code and asks the user to visit a Microsoft URL on a separate device to authorise access.

Attackers have weaponised this into a phishing technique: they initiate a device code request, then send the victim a convincing email or Teams message prompting them to enter the code at the legitimate Microsoft sign-in page. When the victim enters it, the attacker receives a fully authorised access token. No password is captured. No MFA challenge is sent to the attacker. The victim has just handed over their Microsoft 365 session.

This is particularly dangerous because the attacker ends up with a long-lived refresh token that persists until it expires or is revoked — giving ongoing access to Exchange Online, SharePoint, Teams, and connected apps without any further interaction from the victim. For most Microsoft 365 tenants, device code flow is not needed for day-to-day user activity. Blocking it closes a high-value phishing path at low operational cost.

• Phishing campaigns using device code flow trick users into authorising attacker access without entering credentials or completing an attacker-visible MFA challenge
• Attacker receives a long-lived refresh token granting access to all M365 services the user can reach
• The token persists after password resets — remediation steps that don't include session revocation leave the attacker's access intact
• Activity appears in logs as legitimate device code sign-ins, making detection harder without specific hunting queries
• No failed authentication events appear, so alert rules based on failed logins don't trigger
• Multiple users can be simultaneously targeted in a campaign, each granting access via their own device code entry

Some environments have legitimate device code flow requirements:

• Physical devices without web browsers: conference room systems, digital signage, legacy printers, or custom IoT integrations that use Microsoft Graph APIs
• Third-party enterprise applications that use device code flow as part of their authentication design
• PowerShell or CLI tooling used by administrators that relies on device code flow (though these should be migrated to certificate or client credential flows)

Exceptions should be restricted to specific service accounts or named device principals wherever possible, not applied as broad user exclusions. A report-only Conditional Access policy will identify who is currently using device code flow before you enforce the block.

• In Entra ID sign-in logs, filter by authentication detail containing "Device Code" to identify accounts currently using this flow
• Check with IT and dev teams for any scripts, automations, or third-party tools that authenticate using device code
• Review whether any meeting room or shared device accounts use device code for their M365 sign-in
• Deploy a report-only Conditional Access policy blocking the Device Code grant type and review the sign-in impact report after 5–7 days before enforcing
• Confirm whether any PowerShell scripts used by admins or automated processes rely on device code — these can be migrated to app-only authentication with certificates

1. Create a Conditional Access policy scoped to All users with the grant control set to block the Device Code authentication flow
2. Set the policy to Report-only mode first
3. After 5–7 days, review the Conditional Access insights report for sign-ins that would have been blocked
4. Identify any legitimate device code sign-ins and create named service account exclusions for those specific cases
5. Document exceptions with a named owner and review date
6. Set the policy to Enabled and monitor sign-in logs for blocked attempts
7. Confirm no legitimate workflows were disrupted and adjust exclusions if needed

Microsoft: Block legacy authentication with Conditional Access

Microsoft: Authentication flows and application scenarios

Microsoft: Conditional Access grant controls

After enforcing this control, review these related areas:

• OAuth Phishing via First-Party Microsoft Apps — device code phishing and OAuth consent phishing are closely related; enforce both controls together
• CA MFA Bypass Paths — review whether other Conditional Access gaps exist alongside device code flow exposure
• Session Hijack via Unusual IP Change — device code phishing results in token theft; the stolen token may be used from a different IP
• Apps with Risky Permissions — audit existing app consents for tokens that may have been granted via device code before the block was in place