In many of the environments I review, nobody thinks about device code authentication until something goes wrong. Microsoft Threat Intelligence recently described a campaign by Storm-2372 that fits this pattern well. The attackers send fake meeting invites through Teams or WhatsApp and get users to type a device code into Microsoft's login page. The attacker then picks up the access token and has a foothold in the tenant. Device code phishing isn't a hypothetical risk anymore. You can be exposed even if your end users never use device code flow, because default permissions and old integrations tend to go unnoticed. Microsoft has the full write-up on the Microsoft Security Blog. What matters for admins is how quickly you can spot this attack path and close it.
Device code phishing relies on a user entering the attacker's code
The technique always comes down to social engineering. A message arrives, often in Microsoft Teams or WhatsApp, containing a device code and a link to https://microsoft.com/devicelogin. The victim enters the code because it looks like part of a normal sign-in. What they don't know is that the attacker started an OAuth device code flow and will receive the token at the end of it. The phish usually doesn't trigger an MFA prompt, and from Entra ID's point of view it's simply a successful device code authentication. In the sign-in logs it shows up as protocol = Device code. The danger lies in the fact that the user signs in on a different device than the one the attacker controls, and attackers frequently take advantage of existing Conditional Access gaps. I go into the technical details and explain where Conditional Access blocks come in in Block device code flow: Fighting phishing with Entra ID CA.
This simple sequence diagram shows how the attack plays out:
sequenceDiagram
Attacker->>"Victim": "Fake meeting invite with device code"
Victim->>"https://microsoft.com/devicelogin": "Enter device code"
"Microsoft.com"->>"Entra ID": "Authenticate with device code"
"Entra ID"-->>"Microsoft.com": "Issue token"
"Microsoft.com"->>Attacker: "Deliver token"
Figure: Typical device code phishing flow, as used by Storm-2372.
The Entra sign-in logs reveal device code logins
I always start with visibility, which means finding out whether device code sign-ins happen in your tenant at all. Open Microsoft Entra admin center → Monitoring & health → Sign-in logs and filter on Authentication protocol = Device code. Watch for sign-ins from unusual accounts, from odd locations or at strange times. This works for catching targeted attacks as well as integrations everyone has forgotten about. Open an entry to see the app, device and session details. If you haven't hunted through sign-in logs before, Microsoft has an overview of key filters and fields. Many tenants I've worked with were surprised by what they found here, so review these logs on a regular schedule.
Conditional Access can block device code authentication
The best defense is to block device code flow across the whole tenant, unless you have a genuine use case such as Teams Rooms or kiosks. With Entra ID P1 (or higher) you'll find the setting under Conditional Access → Authentication flows → Block device code flow. Apply the policy to all users and exclude only those with a clear operational need. Not having deliberately enabled any device code apps doesn't mean you're safe. Microsoft's documentation on blocking authentication flows is clear and current.
To check with Microsoft Graph PowerShell whether such a policy already exists (Entra ID P1 required):
# PowerShell: Check for policies blocking device code flow
Get-MgConditionalAccessPolicy | Where-Object { $_.Conditions.AuthenticationFlows.DeviceCodeFlow -eq 'block' }
Practical tip: Once the policy is live, go through the sign-in logs from the past few weeks and look for device code attempts. You'll often turn up old integrations or accounts you didn't know relied on it. Modernize them or add explicit exceptions where they're needed.
Compromised accounts call for revoked sessions and user awareness
If an account has been compromised through device code phishing, move quickly. In the Microsoft Entra admin center, select the affected user and revoke all sessions. Document the incident and talk to the user directly. In most cases these attacks only come to light after the token has already been used, for example for suspicious app access or sign-ins from unexpected locations. I cover detection and response for token theft in more detail in Token theft after MFA: Defending Microsoft 365 sessions.
You should shrink your attack surface now
Device code phishing is an active threat today, not something that might happen one day. Proper Conditional Access controls, regular sign-in log reviews and user awareness cut your tenant's exposure considerably. My recommendation is to look at your Conditional Access policies today and block device code flow wherever it isn't strictly required. It doesn't take many steps to get from a fake meeting invite to a stolen token, so don't leave that door open.
