How Device Code Phishing Turns MFA Against You
Sep 22, 2026
Nicole Walker
Cloud Security
|
Security & Compliance
|
Microsoft 365
|
Cybersecurity
|
Data Protection
|
Sourcepass MCOE
6 min read
MFA is one of the most effective security controls in Microsoft 365, but it is not designed to stop every attack.
Device code phishing can give an attacker a valid Microsoft 365 access token even when a user completes MFA, uses a passkey, or signs in from a compliant device.
The attack works because it abuses a legitimate authentication process instead of stealing a password through a fake sign-in page. An attacker generates a device code and persuades the user to enter it on a real Microsoft authentication page. When the user approves the request, the attacker receives a token that can provide access to the user's Microsoft 365 account.
Understanding how device code phishing works can help IT teams detect risky authentication activity, evaluate legitimate device code usage, and block unnecessary access through Microsoft Entra Conditional Access.
How does Device Code Phishing Bypass MFA in Microsoft 365?
In this episode of the Demystifying Microsoft podcast, Nathan Taylor explains how device code flow works, why it can succeed even when MFA is enabled, and how organizations can reduce their exposure using Microsoft Entra Conditional Access.
What is Device Code Flow in Microsoft 365?
Device code flow is an authentication method designed for devices that have limited input capabilities. Examples can include conference room systems, shared devices, digital signage, smart TVs, and command-line tools.
Instead of entering credentials directly on the device, the user receives a short code and instructions to visit a Microsoft sign-in page on another device. The user enters the code, signs in, and completes any required authentication. Microsoft then grants the original device access.
This is a legitimate OAuth 2.0 authentication flow.
How does Device Code Phishing Work?
A device code phishing attack generally follows this sequence:
- The attacker initiates a device code authentication request.
- The attacker sends the resulting code or link to the target.
- The target visits a legitimate Microsoft sign-in page.
- The target enters the code and completes authentication.
- Microsoft issues a token to the session initiated by the attacker.
- The attacker uses that token to access resources available to the compromised account.
The user may believe they are approving access for a legitimate application, device, IT process, or collaboration request. Because the authentication happens on Microsoft’s real sign-in infrastructure, there may be no fake password page for the user or a traditional phishing filter to identify.
Microsoft has documented device code phishing campaigns in which attackers used lures resembling WhatsApp, Signal, and Microsoft Teams interactions. Microsoft says the activity exploits an industry-standard authentication flow and does not depend on a vulnerability in Microsoft’s code.
Can Device Code Phishing Bypass MFA?
Device code phishing can bypass MFA because the attacker tricks the user into completing a legitimate authentication request. The attack does not technically disable or break MFA. Instead, the user completes MFA for an authentication request controlled by the attacker.
The user may successfully provide a password, approve an MFA request, or use a phishing-resistant authentication method. Those controls verify that the user completed the sign-in, but they do not necessarily verify that the user understands which device or session they are authorizing.
Because the resulting access token has passed the required authentication checks, device code phishing can succeed in environments that already enforce MFA.
What Happens After a Device Code Phishing Attack Succeeds?
After a successful device code phishing attack, an attacker can use the stolen access tokens to access the same Microsoft 365 resources available to the compromised account. Depending on the user's permissions, that may include email, files, applications, Teams conversations, and other Microsoft 365 data.
Attackers often use Microsoft Graph and related tools to access mailboxes and begin collecting data. Because they are operating with a valid access token rather than a stolen password, the activity may be harder to identify as a traditional account compromise.
This is why rapid detection and response are critical. Simply resetting a user's password may not be enough if active tokens or authenticated sessions remain in place.
What is Storm-2372 and How is it Linked to Device Code Phishing?
Storm-2372 is a threat actor designation used by Microsoft for activity associated with device code phishing.
Microsoft reported in February 2025 that the campaign had been active since August 2024. The group targeted governments, nongovernmental organizations, IT services, defense, telecommunications, healthcare, higher education, energy, and other sectors across several regions.
The broader concern is not limited to one threat actor. Device code phishing can be reused and incorporated into phishing-as-a-service operations, giving more attackers access to the same technique.
How do you Detect Device Code Flow in Microsoft Entra ID?
Microsoft Entra sign-in logs allow administrators to identify device code flow activity and determine whether it is being used within their Microsoft 365 tenant. Before blocking device code flow, organizations should review recent sign-ins to understand whether any legitimate devices, applications, or workflows rely on it.
To review device code flow activity:
- Open the Microsoft Entra admin center.
- Navigate to the user sign-in logs.
- Expand the reporting period to review recent activity.
- Add the Authentication Protocol filter.
- Select Device Code Flow.
- Review the affected users, applications, devices, locations, and sign-in results.
This review should be completed before enforcing a Conditional Access policy that blocks device code flow. Some organizations may have legitimate use cases, such as conference room systems, shared devices, or automation workflows that depend on this authentication method.
Any device code sign-in that does not have a clear business purpose should be investigated. IT teams should identify who initiated the sign-in, which application requested access, and whether the user intended to authorize the session.
Should you Block Device Code Flow in Microsoft 365?
Microsoft recommends blocking device code flow wherever possible and allowing it only where necessary. Microsoft classifies the flow as a higher-risk authentication method because it can support phishing attacks or provide corporate access from unmanaged devices.
For organizations with no legitimate use case, blocking the flow can eliminate an unnecessary authentication path. For organizations that rely on conference room devices, digital signage, or similar systems, the better approach is to identify those use cases and create tightly controlled exceptions.
The policy should not be deployed without reviewing current usage.
How do you Block Device Code Flow in Microsoft Entra?
Device code flow can be blocked using a Microsoft Entra Conditional Access policy that targets device code authentication and denies access. Organizations that do not have a legitimate business requirement for device code flow can use this control to reduce the risk of device code phishing attacks.
A policy designed to block the flow generally includes:
- Users: All users, with carefully reviewed exclusions when required
- Target resources: All resources
- Condition: Authentication flows with device code flow selected
- Grant control: Block access
- Policy state: Report-only during validation, followed by enforcement when testing is complete
Microsoft recommends configuring device code flow controls alongside other Conditional Access protections. For example, an organization that needs device code flow for Android conference room systems could allow it only for those devices from a specific network location.
Organizations should also maintain emergency access accounts and follow their established Conditional Access testing and deployment process.
What if your Organization Needs Device Code Flow?
Organizations that rely on conference room systems, kiosks, digital signage, or other specialized devices may still need device code flow. In those cases, the goal should be to limit access to only the accounts, devices, and locations that require it rather than creating broad exceptions.
Possible compensating controls include:
- Restricting sign-ins to known network locations
- Requiring a managed or compliant device when supported
- Using a dedicated account rather than an employee’s daily account
- Applying least-privilege permissions
- Monitoring every use of the excluded account
- Limiting who can access or manage its credentials
Avoid broadly excluding normal employee or administrator accounts. Those accounts are more likely to receive email, Teams messages, and other social engineering lures.
Is Blocking Device Code Flow Enough to Stop Device Code Phishing?
Blocking device code flow addresses one attack path, but organizations should still monitor identity activity for signs of token theft, suspicious sign-ins, and account compromise.
Identity threat detection and response tools can monitor sign-ins, token activity, account behavior, and other indicators that may require investigation. Attackers can access data, establish persistence, or perform reconnaissance before creating obvious signs of compromise, making continuous identity monitoring an important layer of defense.
Microsoft has also documented newer device code phishing activity that uses automation, dynamic code generation, personalized lures, malicious inbox rules, and post-compromise data collection.
How Can you Reduce the Risk of Device Code Phishing?
Organizations can reduce the risk of device code phishing by blocking unnecessary device code flow authentication, monitoring identity activity, enforcing Conditional Access policies, and investigating suspicious sign-ins. No single security control prevents every attack, which is why a layered security approach is important.
Organizations should also:
- Review device code activity in Microsoft Entra sign-in logs
- Investigate unexpected device code authentication
- Avoid broad policy exclusions
- Monitor token and session activity
- Apply least privilege to accounts requiring exceptions
- Teach users not to enter device codes they did not initiate
- Revoke active sessions when an account is suspected of compromise
The most important user-facing guidance is simple. A legitimate Microsoft sign-in page does not automatically mean the request itself is legitimate.
Device Code Phishing FAQ
How can you Protect Microsoft 365 from Device Code Phishing?
Device code phishing turns a legitimate authentication process into an access path for attackers. MFA alone cannot resolve the problem when a user is persuaded to approve the attacker’s session.
Reviewing device code activity, blocking unnecessary use, and tightly controlling exceptions can close this authentication path without disrupting legitimate devices. Sourcepass MCOE can help assess Microsoft 365 identity controls, review Conditional Access policies, and identify configuration gaps that increase token theft risk.
Subscribe to the Demystifying Microsoft podcast for guidance on Microsoft security, identity, licensing, and cloud management.
Subscribe To
Sourcepass Insights
Sourcepass Insights
Stay in the loop and never miss out on the latest updates by subscribing to our newsletter today!
