Device Code Flow abuse is not a new technique. Security teams have known for some time that this OAuth feature can be leveraged in phishing attacks to obtain tokens without stealing credentials. What is new is how accessible and scalable this attack has become.
In April 2026, the FBI warned about a Phishing-as-a-Service (PhaaS) platform called Kali365, which operationalizes this exact technique. It allows even low-skilled attackers to run campaigns that trick users into entering device codes on legitimate Microsoft login pages — ultimately granting attackers OAuth tokens and acess to Microsoft 365 environments without triggering traditional authentication defenses.
How Device Code Flow Works
Device code flow is an authentication method designed for scenarios where a device has limited input options or lacks a convenient browser interface (such as smart TVs, IoT devices, or command-line tools). Instead of entering credentials directly on the device, the application generates a verification code and displays it.
The user then switches to a secondary device (such as a laptop or smartphone), navigates to https://microsoft.com/devicelogin, and enters the provided code. After successfully authenticating, the identity provider securely links the session and grants the original device access to the requested resource.
Why Device Code Flow Should Be Restricted
In practice, many organizations don’t have a real or current business need for device code flow, yet leave it enabled—unnecessarily expanding their attack surface. Disabling it helps reduce exposure by removing a legacy or rarely used authentication path and reinforces modern controls.
Microsoft recommends getting as close as possible to a full block. Start by auditing existing usage, validate whether any legitimate scenarios still require it, and strictly limit access only to well-defined, secured, and documented use cases (e.g., specific legacy tools). In all other cases, device code flow should be disabled by default—and users that legitimately need device code flow should be educated about how it can be misused in phishing campaigns.
How to Restrict Device Code Flow in MS Entra ID
You can mitigate this flow by implementing Conditional Access — here’s step by step guide based on Microsoft's documentation:
Sign in to the Microsoft Entra admin centre as (at least) a Conditional Access Administrator.
Sign in to the Microsoft Entra admin centre as (at least) a Conditional Access Administrator.
Browse to Entra ID > Conditional Access > Policies.
Select New policy.
-
Under Assignments, select Users or workload identities.
- Under Include, select users you want to be in-scope for the policy (All users recommended).
- Under Exclude, select your organization’s emergency access or break-glass accounts and any other necessary users. This exclusion list should be audited regularly.
Under Target resources > Resources (formerly cloud apps) > Include, select the apps you want to be in-scope for the policy (All resources (formerly 'All cloud apps') recommended).
-
Under Conditions > Authentication Flows, set Configure to Yes.
- Select Device code flow.
- Select Done.
-
Under Access controls > Grant, select Block access.
- Select Select.
Confirm your settings and set Enable policy to Report-only.
Select Create to enable your policy.
After evaluation of the policy settings using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.
Microsoft-managed Conditional Access Policies
Device code flow may already be blocked in your tenant by default through Microsoft-managed Conditional Access policies. To check:
Go to: Entra ID > Conditional Access > Policies > Microsoft-managed
Microsoft automatically deploys these preconfigured policies based on global threat intelligence, often including controls like blocking device code flow or enforcing MFA to reduce risk. These policies are initially introduced in report-only mode and later enforced, meaning your environment might already be protected without manual configuration. It’s therefore important to review existing Conditional Access policies before implementing new ones, as device code flow could already be restricted as part of Microsoft’s secure-by-default approach.