Device Code Phishing Explained — And the Conditional Access Policy That Blocks It

Multi-factor authentication has stopped countless account compromises, but attackers continue to look for authentication processes that users do not recognise or understand.

One increasingly important technique is device code phishing.

Instead of asking a victim to type their password into a fake sign-in page, the attacker starts a legitimate Microsoft device code authentication session and persuades the victim to approve it. The victim signs in on Microsoft’s genuine website, completes MFA and unknowingly authorises the attacker’s application or device.

The attacker may then receive valid authentication tokens without ever seeing the user’s password.

The most direct defence in Microsoft Entra ID is a Conditional Access policy that blocks device code flow for users who do not have a genuine business reason to use it. Microsoft recommends blocking device code flow wherever possible and allowing only carefully controlled exceptions. 

This guide explains how device code phishing works, why ordinary MFA may not stop it and how to configure the Conditional Access policy that blocks the attack path.

What Is Device Code Flow?

Device code flow is a legitimate authentication method designed for devices or applications that cannot provide a normal browser-based sign-in experience.

Examples may include:

• Shared meeting-room equipment
• Digital displays
• Televisions
• Command-line tools
• Input-constrained devices
• Applications running without a full browser
• Certain Microsoft Teams devices

The device displays a short code and instructs the user to open a sign-in page on another computer or phone. The user enters the code, signs in and approves access. The original device then receives an authentication token and continues operating as that user. 

A legitimate flow may look like this:

Device or application requests authentication

                    ↓

A short device code is generated

                    ↓

The user opens Microsoft’s verification page

                    ↓

The user enters the code

                    ↓

The user signs in and completes MFA

                    ↓

The original device receives an access token

This is useful when the original device has no practical way to display and complete a standard interactive sign-in.

The problem is that the code does not clearly prove that the device belongs to the user.

What Is Device Code Phishing?

Device code phishing abuses the legitimate device code flow.

The attacker begins an authentication request on a device or application under their control. Microsoft produces a short code for that session. The attacker then sends the code to the victim using a convincing pretext.

The message may claim that the user needs to:

• Join a Microsoft Teams meeting
• Verify a secure conversation
• Review a document
• Complete a compliance check
• Confirm their identity
• Access a shared application
• Sign in to a company portal

The victim opens Microsoft’s genuine device login page, enters the attacker-supplied code and signs in normally.

After the user approves the request, the authentication token is returned to the attacker’s waiting session.

Microsoft describes this attack as a threat actor initiating the device flow and supplying the resulting code through a phishing lure. When the victim enters the code, they authorise the attacker’s session without necessarily exposing their credentials. 

A Simple Device Code Phishing Example

Imagine an employee receives a Teams message from someone pretending to be a supplier:

We have added you to the project workspace. Enter code F7DK-9QPL at the Microsoft sign-in page to access the files.

The victim may then:

1. Open Microsoft’s real verification page.
2. Enter the supplied code.
3. See the genuine Microsoft sign-in screen.
4. Enter their real username and password.
5. Complete MFA.
6. Approve access.

Everything visible may appear legitimate because the victim is interacting with Microsoft’s real authentication service.

The deception lies in who started the device code request.

The attacker did.

Once the user completes the flow, Microsoft returns the resulting token to the attacker-controlled application or device. The attacker may then attempt to access the resources authorised by that token. 

Why MFA May Not Stop Device Code Phishing

MFA may work exactly as configured during the attack.

The victim enters the correct password and completes a genuine MFA challenge. The identity platform therefore sees a successful authentication performed by the real user.

The attacker is not necessarily bypassing or guessing the MFA factor. Instead, the attacker convinces the victim to approve the attacker’s authentication transaction.

This is why device code phishing can succeed even when the organisation uses:

• Authenticator push notifications
• Number matching
• One-time passcodes
• SMS codes
• Telephone verification
• Other conventional MFA methods

MFA still provides important protection, but it cannot protect users who are socially engineered into authorising the wrong session.

The stronger defence is to prevent unnecessary device code authentication entirely.

Device Code Phishing vs. Traditional Password Phishing

Traditional phishing commonly works like this:

Victim opens fake website

        ↓

Victim enters credentials

        ↓

Attacker steals password

        ↓

Attacker attempts to sign in

Device code phishing works differently:

Attacker starts legitimate device flow

        ↓

Attacker receives a device code

        ↓

Victim is persuaded to enter the code

        ↓

Victim signs in on the genuine Microsoft website

        ↓

Attacker receives the authorised token

The genuine Microsoft sign-in page makes the attack harder for users to recognise.

There may be:

• No obvious fake password page
• No visibly incorrect Microsoft sign-in domain
• No stolen password submitted directly to the attacker
• No suspicious MFA prompt appearing independently of user activity

The request itself is the malicious part.

Why Attackers Like Device Code Phishing

Device code phishing can be attractive because it:

• Uses a legitimate Microsoft authentication workflow
• Can operate without a fake Microsoft password page
• May capture authorised tokens rather than only passwords
• Can work against accounts protected by conventional MFA
• Relies heavily on social engineering rather than malware
• May blend into normal cloud authentication traffic
• Can be delivered through email, messaging platforms or compromised accounts

Microsoft reported device code phishing campaigns using lures designed to resemble familiar messaging applications and collaboration experiences. 

What Can an Attacker Do After Successful Device Code Phishing?

The impact depends on:

• The application used in the flow
• The permissions requested
• The user’s role
• The Conditional Access policies applied
• The scope and lifetime of the token
• The resources available to the user

Possible activity may include:

• Reading email
• Accessing cloud files
• Viewing contacts
• Searching internal conversations
• Downloading company information
• Sending phishing messages
• Impersonating the victim
• Targeting finance or payroll staff
• Requesting fraudulent payments
• Establishing additional persistence

A standard user account can still provide valuable access because it may reveal internal structures, trusted contacts, current projects and previous email conversations.

The Conditional Access Policy That Blocks Device Code Flow

Microsoft Entra Conditional Access includes an Authentication flows condition that can target device code flow specifically.

The policy logic is:

IF:

A user attempts authentication using device code flow

THEN:

Block access

Microsoft’s current guidance is to block device code flow by default and create limited, documented exceptions only for genuine dependencies. 

Conditional Access Licensing Requirements

Microsoft Entra Conditional Access requires Microsoft Entra ID P1 or a licence that includes it. Microsoft states that Microsoft 365 Business Premium customers also have access to Conditional Access. Users governed by the feature must be licensed appropriately under Microsoft’s licensing terms. 

Organisations without Conditional Access may use Microsoft Entra Security Defaults, which now includes protection that blocks device code flow. Security Defaults provides a standard Microsoft-managed security configuration but does not offer the same detailed exception and targeting options as custom Conditional Access policies. 

Before Blocking Device Code Flow

Do not enable the policy blindly across a production environment.

First determine whether any legitimate systems depend on device code authentication.

Potential dependencies may include:

• Microsoft Teams room or shared-device scenarios
• Command-line utilities
• Development tools
• Legacy applications
• Shared devices
• Digital signage
• Administrative scripts
• Specialist appliances

Microsoft recommends reviewing sign-in activity for device code use before enforcing a block. The sign-in logs can be filtered using Authentication protocol = Device code flow, and administrators should also review the Original transfer method field because protocol tracking can follow sessions derived from an earlier device code authentication. 

Step 1: Review Current Device Code Usage

In the Microsoft Entra admin centre:

1. Open Entra ID.
2. Go to Monitoring & health.
3. Open Sign-in logs.
4. Add a filter for Authentication protocol.
5. Select Device code flow.
6. Review successful and failed activity.
7. Record the user, application, resource, device, location and business purpose.
8. Also inspect Original transfer method for device-code-derived sessions.

Investigate device code activity when:

• The organisation has no known device code requirement.
• A normal office user appears in the results.
• The sign-in originates from an unfamiliar location.
• The application is unexpected.
• The activity happens outside normal working patterns.
• No system owner can explain the dependency.

Microsoft’s security operations guidance advises investigating successful device code activity when the organisation does not expect this authentication method to be used. 

Step 2: Identify Legitimate Exceptions

Every exception weakens the default block, so it should have:

• A named business owner
• A documented purpose
• A defined user or resource account
• A review date
• Monitoring
• The narrowest practical scope

Avoid excluding:

• Entire departments
• All administrators
• All IT staff
• Every Teams user
• Large groups “just in case”

Microsoft’s Teams guidance recommends persistent exceptions for the specific resource accounts that require device code flow, rather than broad exclusions. 

Where possible, replace device code dependencies with safer options such as:

• Browser-based authentication
• Brokered authentication
• Managed identities
• Workload identity federation
• Modern supported applications

Microsoft specifically recommends managed identities or workload identity federation for automation instead of user-based device code authentication where practical. 

Step 3: Protect Emergency Access Accounts

Conditional Access policies can lock out administrators when configured incorrectly.

Microsoft recommends maintaining emergency access, or “break-glass,” accounts and excluding them from Conditional Access policies to preserve a recovery path after policy misconfiguration. These accounts should be tightly controlled and used only for genuine emergencies. 

Before creating the policy:

• Confirm emergency accounts exist.
• Confirm their credentials are securely stored.
• Test that authorised staff can access them.
• Monitor any use of those accounts.
• Exclude them from the new policy.
• Never use them for normal administration.

Step 4: Create the Conditional Access Policy

Microsoft’s current interface may change slightly, but the policy should follow this structure:

Policy name

CA - Block Device Code Flow

Users

Include:

All users

Exclude:

• Emergency access accounts
• Explicitly approved exception groups

Target resources

Select:

All resources

The objective is to stop device code authentication from being used to access cloud resources unless an approved exception applies.

Conditions

Open:

Authentication flows

Set Configure to:

Yes

Select:

Device code flow

Access controls

Under Grant, select:

Block access

Policy state

Begin with:

Report-only

Microsoft’s documented policy configuration uses the Authentication flows condition to target device code flow and applies a Block access grant control. 

Step 5: Use Report-Only Mode First

Report-only mode evaluates the policy without actively blocking users.

This allows administrators to see:

• Which sign-ins would have been blocked
• Which users are affected
• Which applications depend on the flow
• Whether exclusions work
• Whether legitimate devices may lose access

Microsoft recommends using report-only analysis to validate Conditional Access changes progressively and reduce the risk of unintended disruption. 

Leave the policy in report-only mode long enough to capture normal business activity, including:

• Daily user sign-ins
• Weekly processes
• Monthly administration
• Device reauthentication
• Scheduled maintenance
• Teams device use

The appropriate review period depends on the organisation’s environment.

Step 6: Review Report-Only Results

Return to the Microsoft Entra sign-in logs and review the Conditional Access details for affected sign-ins.

Check whether the policy result shows:

• Report-only: failure
• Report-only: interrupted
• Not applied
• Excluded
• Success

For every sign-in that would have been blocked, determine:

• Is it legitimate?
• Does it involve a known device?
• Does the user genuinely require device code flow?
• Can the application use another authentication method?
• Should the user be added to a tightly controlled exception group?
• Does the sign-in indicate possible phishing?

Do not convert the policy to enforced mode until the unexpected legitimate dependencies have been resolved.

Step 7: Enable the Policy

After the report-only results have been reviewed:

1. Open the policy.
2. Confirm the included users.
3. Confirm emergency account exclusions.
4. Confirm authorised exception groups.
5. Confirm all intended resources are targeted.
6. Confirm Device code flow is selected.
7. Confirm Block access is selected.
8. Change the policy state from Report-only to On.
9. Save the policy.
10. Monitor sign-in failures closely.

Roll out in stages when possible.

A staged deployment might begin with:

• IT test users
• A pilot department
• Most users
• High-risk users
• The remaining organisation

Teams Devices Need Special Planning

Some Microsoft Teams devices legitimately depend on device code flow for initial provisioning and certain reauthentication events.

Microsoft’s recommended pattern is:

• Block device code flow by default.
• Maintain a security group containing approved Teams device resource accounts.
• Exclude only that group from the block.
• Exclude the Device Registration Service resource where required for registration.
• Monitor continuing device code usage.
• Avoid broad user exclusions. 

Personal Teams device scenarios are more difficult because excluding an ordinary user may allow that person to use device code flow in unrelated situations. Microsoft advises documenting and monitoring any such exception carefully. 

Example Policy Summary

Does Phishing-Resistant MFA Stop Device Code Phishing?

Phishing-resistant MFA remains extremely valuable, but the cleanest control for this specific risk is to block device code flow when it is not needed.

Methods such as passkeys and FIDO2 security keys prevent many conventional credential-phishing and adversary-in-the-middle attacks because their cryptographic authentication is bound to the intended service. Microsoft describes passkeys as a significant security improvement over phishable MFA methods. 

However, organisations should avoid assuming that stronger MFA alone makes every authentication flow safe.

A layered strategy should include:

• Blocking risky flows
• Phishing-resistant authentication
• Managed devices
• Conditional Access
• Token and session monitoring
• Endpoint protection
• Rapid token revocation
• User education

User Training for Device Code Phishing

Employees should understand one very simple rule:

Never enter a device code that somebody else sends you unless you deliberately initiated the sign-in on a known business device.

Users should stop and report the request when:

• A colleague sends a device code unexpectedly.
• A meeting invitation asks them to enter a code.
• A supplier asks them to authorise an application.
• A message claims the code is needed to view a document.
• Someone pressures them to complete the process quickly.
• The code appears during an activity that normally requires only a link.
• They cannot clearly identify the device requesting access.

Users should also read the approval information carefully and confirm that:

• The displayed application is expected.
• The sign-in request matches their own activity.
• The requested permissions make sense.
• The user initiated the device sign-in themselves.

Device Codes Should Be Treated Like Approval Requests

A device code is not merely a harmless reference number.

Entering it may authorise a device or application to act under the user’s identity.

Employees should treat device codes in the same way they treat:

• MFA approval prompts
• Password-reset requests
• Application-consent requests
• Security-key registrations
• New authentication methods

When the user did not initiate the request, they should not approve it.

Detecting Device Code Phishing

Potential indicators include:

• Unexpected successful device code sign-ins
• Device code authentication by ordinary office users
• Activity from unusual IP addresses or countries
• A new application appearing in sign-in logs
• Token access after a suspicious email or Teams message
• Mailbox access shortly after device code authentication
• New inbox or forwarding rules
• Unusual file downloads
• Sign-ins outside normal working hours
• Device code use where no approved dependency exists

Use Entra sign-in logs to correlate:

• User
• Time
• IP address
• Location
• Application
• Resource
• Authentication protocol
• Conditional Access result
• Original transfer method
• Device information

What to Do After Suspected Device Code Phishing

Treat successful device code phishing as an account compromise.

Revoke Sessions and Tokens

Use Microsoft Entra controls to revoke the user’s active sessions and refresh tokens.

Changing the password alone may not immediately terminate every existing authorised session.

Reset the Password

Reset the affected user’s password after containing the account and examining the endpoint.

Review Authentication Methods

Check for newly added:

• Authenticator registrations
• Telephone numbers
• Passkeys
• Security keys
• Temporary access methods

Review Sign-In Logs

Identify:

• When device code authentication occurred
• Which application was used
• Which resources were accessed
• The source IP address
• Whether further sign-ins followed
• Whether Conditional Access applied

Review Mailbox Activity

Check:

• Inbox rules
• External forwarding
• Sent items
• Deleted items
• Drafts
• Financial conversations
• Further phishing messages

Review Application Consent

Investigate unfamiliar applications and permissions granted to the account.

Investigate the Original Message

Find and remove the phishing message from other users’ mailboxes or collaboration platforms.

Notify Relevant Parties

Contact anyone who received messages from the compromised account through a trusted channel.

Preserve Evidence

Retain:

• Sign-in events
• Message headers
• Audit logs
• Application-consent events
• IP addresses
• Timestamps
• Endpoint alerts

Common Conditional Access Mistakes

Turning the Policy On Immediately

Use report-only mode before enforcement.

Forgetting Emergency Accounts

A policy mistake may lock out every administrator.

Excluding All IT Users

This creates a broad route attackers may exploit.

Targeting Only Microsoft 365

Device code tokens may be used with other cloud resources, so Microsoft recommends broad resource targeting unless a carefully tested design requires otherwise.

Ignoring Teams Device Dependencies

Some Teams devices require planned exceptions.

Keeping Permanent Undocumented Exceptions

Every exception needs an owner, reason and review date.

Reviewing Only Authentication Protocol

Also inspect Original transfer method, because Microsoft’s protocol tracking can identify sessions originating from device code flow even when a later event presents differently. 

Assuming MFA Solves the Problem

The victim may complete genuine MFA while authorising the attacker’s device.

Failing to Monitor After Deployment

New applications or devices may introduce a device code dependency later.

Device Code Security Checklist

Before deployment:

• Confirm Conditional Access licensing.
• Inventory device code usage.
• Identify legitimate dependencies.
• Confirm emergency access accounts.
• Create tightly scoped exception groups.
• Document business owners.
• Plan user communication.

Policy configuration:

• Include all users.
• Exclude emergency access accounts.
• Exclude only approved dependency groups.
• Target all required resources.
• Select Authentication flows.
• Select Device code flow.
• Choose Block access.
• Start in report-only mode.

Before enforcement:

• Review sign-in logs.
• Investigate unexpected activity.
• Test Teams and shared devices.
• Test command-line and administrative tools.
• Confirm the recovery procedure.
• Obtain business approval.

After enforcement:

• Monitor blocked sign-ins.
• Review exception groups regularly.
• Investigate successful device code use.
• Train users about unsolicited codes.
• Review the policy after technology changes.
• Revoke access when exceptions are no longer needed.

Final Thoughts

Device code phishing succeeds because it turns a legitimate authentication feature into a social-engineering tool.

The attacker does not always need to steal the password or defeat MFA. Instead, they initiate a device authentication request and persuade the victim to complete it on their behalf.

The user may sign in through Microsoft’s genuine website, complete real MFA and still authorise the attacker’s session.

For organisations that do not require device code flow, the most effective response is straightforward: block it with Conditional Access.

Create a policy targeting the Device code flow authentication flow, apply Block access, begin in report-only mode and investigate every legitimate dependency before enforcement. Keep exceptions narrow, documented and monitored.

Device code flow is useful in specific technical situations. It should not remain available to an entire workforce merely because nobody has reviewed it.

Security improves when risky authentication routes are disabled by default and opened only where there is a genuine, controlled business requirement.

Worried About Device Code Phishing?

Hamilton Group can help assess your Microsoft Entra ID and Microsoft 365 authentication controls.

Our experts can help you:

• Audit device code flow usage
• Configure Conditional Access safely
• Create and test report-only policies
• Protect emergency access accounts
• Plan Teams device exceptions
• Deploy phishing-resistant MFA
• Review suspicious sign-ins
• Strengthen administrator accounts
• Block legacy and risky authentication routes
• Build identity-compromise response procedures
• Improve Microsoft 365 monitoring and security

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to discuss stronger Microsoft 365 identity protection.