Device code phishing bypasses endpoint security entirely by operating in the cloud identity layer. We walk through the attack step-by-step, what it looks like in your logs, and the practical defences that actually work.
Everyone's talking about how identity is the new perimeter. Fair enough. But let me show you what that actually means when it hits a real business.
You're running ops at a 40-person company. Tuesday afternoon, LinkedIn message: someone wants you on their podcast about business resilience. Profile looks real, mutual connections, proper job title. Flattering. A bit random, but whatever.
Few messages back and forth. They're friendly, clearly done their homework on your background. Couple days later: "Hey, quick thing before our call - need to add you to our guest workspace. Just go to microsoft.com/devicelogin and punch in this code: BXKR-PMTL. Standard Microsoft thing, takes 30 seconds."
You click through. Real Microsoft page, padlock in the address bar, the usual login flow you've done a thousand times. Email, password, MFA on your phone. Success message. Close tab, back to work.
Three weeks later, accounts pays £48k to a supplier. Bank details changed - email came from the CFO's real mailbox. Except the CFO never sent it. By the time anyone catches on, money's gone, attacker's been in the CEO's inbox for a month, and every laptop scans clean.
Not a hypothetical. Microsoft documented this days ago. It's already hit hundreds of businesses. It's called device code phishing, and if you're running an MSP or SMB, this is the one to understand.
For a decade, the security playbook was simple: phishing email → bad link → malware → EDR catches it. Buy decent email filtering, install endpoint protection, patch stuff, train users. Job done.
That playbook's expired.
Last two years, initial access shifted hard from malware to identity. Check the threat reports from Mandiant, CrowdStrike, Microsoft - they all say the same thing. Most breaches now start with stolen creds, phished tokens, or authentication abuse. Not malware.
"The attacker doesn't need to get code running on your machine any more, because they don't need your machine at all. They need your Microsoft 365 login."
This matters because all those security investments - the antivirus, the EDR, the locked-down laptops - are guarding the wrong door. Attackers aren't coming through endpoints anymore.
Device code phishing is the clearest example of this. Here's how it works.
The easiest way to understand device code phishing is to think about signing into Netflix on a smart TV.
Typing on a TV remote sucks. So Netflix shows you a code - BXKR-PMTL - and tells you to visit netflix.com/activate on your phone. You log in there, enter the code, done. Netflix knows that TV is yours.
This isn't some Netflix hack. It's OAuth 2.0, standard authentication. Microsoft, Google, GitHub all support it. It's for devices that can't run a proper browser - TVs, IoT stuff, command-line tools, conference room screens.
Here's the problem: the "device" doesn't have to be a TV. It can be anything. Like a Python script on an attacker's laptop.
Attacker asks Microsoft for a device code. Gets back a real code and URL. Sends it to you via LinkedIn. You visit the real microsoft.com/devicelogin, sign in, enter the code. Microsoft issues tokens to the "device" that requested it. That device is the attacker's machine. They now have weeks of access as you.
See the problem? Attacker and victim never touch anything malicious. Every interaction is with real Microsoft endpoints. You think you're verifying your account or joining a workspace. You're actually authorizing a Python script on some VPS to hold your tokens.
Key Insight The attack lives in the gap between what you think you're authorizing and what you're actually authorizing. No fake website. No suspicious domain. No malicious file. Just a conversation and a real login. That's why it works.
Here's the bit that surprises people: phishing-resistant MFA doesn't stop this. Not fully anyway.
FIDO2 keys work by checking the origin of the login page. Fake Microsoft page? Key refuses. That's how it beats traditional phishing and man-in-the-middle attacks.
But with device code phishing, you're on the real Microsoft page. Origin check passes. Key cooperates. Microsoft authenticates you, you click consent, tokens go to the attacker's device. Security key worked. Microsoft worked. You did everything right. Attacker still gets in.
FIDO2 is still worth having - it stops most phishing. But if someone tells you "we've deployed security keys, we're sorted" - they're not seeing the full picture. Device code phishing needs different defences.
EDR is good kit. Malware runs? EDR catches it. Suspicious PowerShell? Flagged. Credential dumping? Noticed. If you're running Defender for Business, SentinelOne, CrowdStrike - keep paying for it.
But device code phishing doesn't trigger any of that. Here's what happens on the victim's laptop during the attack:
That's it. From the endpoint's view, user checked their email. No suspicious process, no dodgy file, no weird network connection. EDR sees normal behavior because it is normal behavior. The laptop did nothing wrong.
Everything that matters happens in the cloud, where your EDR can't see.
EDR Can See This:
EDR Status: ALL CLEAR No malicious process, no file drops, no suspicious PowerShell, no privilege escalation
EDR Cannot See This:
EDR Status: INVISIBLE Attack happens on infrastructure you don't own and can't monitor with EDR
The Reality Check This is not an EDR failure. EDR is doing exactly what it's designed to do: monitor processes and file activity on endpoints you own. The problem is that modern identity attacks operate entirely in the cloud layer, on infrastructure you'll never see. The attacker's laptop is the one running malicious code, and you'll never install your EDR agent there.
The Conceptual Shift EDR is a control that watches the devices you own. Modern identity attacks are designed to operate entirely from devices you do not own. This is not a failure of EDR. It is a boundary of what EDR can ever do, and it is the reason identity attacks have become the attacker's preferred route.
The good news is that even though your EDR is the wrong surface for catching this, there are three other surfaces that do see the attack, and all three are included in Microsoft 365 licences you probably already hold. The first is Conditional Access, which lets you stop the attack at the door by blocking the device code authentication flow entirely for users who do not need it. The second is Microsoft Entra sign-in logs, which record every authentication event in your tenant and clearly mark which protocol was used. The third is Conditional Access device compliance policies, which let you tell Microsoft "only trust sign-ins from devices that are enrolled in my management and marked as compliant." Layered together, these three controls shut this attack path down comprehensively.
If EDR is the wrong surface, the Entra sign-in log is the right one. Every authentication event in your Microsoft 365 tenant is recorded here, and device code phishing leaves a recognisable signature if you know what fields to look at.
Here is what a successful device code phish looks like in the Entra sign-in log:
User: [email protected]
Application: Microsoft Azure CLI
Authentication Protocol: deviceCode
Client App: Mobile Apps and Desktop clients
Status: Success
IP Address: 86.12.XX.XX (user's normal broadband IP)
Location: Bristol, United Kingdom
Conditional Access: Not Applied
MFA Result: Satisfied by claim in the tokenSeveral things on that line should bother you if you see it in a tenant where device code phishing was not expected.
The Authentication Protocol field showing deviceCode is the smoking gun. For the vast majority of users in a typical SMB, this value should never appear. Regular Outlook, Teams, SharePoint and browser logins all use different flows. A device code authentication is inherently unusual unless the user is a developer using a command-line tool, or an administrator running scripts against the tenant, and even then it should be rare.
The Application field is the second clue. In a genuine device code flow, the application shown is whatever "device" the attacker told Microsoft they were. Microsoft Azure CLI, Microsoft Visual Studio Code, and Microsoft Office are common choices because they have broad pre-consented permissions. Seeing a sign-in from a user who has never used the Azure CLI in their life, using the Azure CLI as the application, with a device code protocol, is the signature.
For an MSP or SMB that has never looked at these logs before, the practical starting point is simpler than full correlation: just filter the Entra sign-in log for any successful authentication where the protocol is deviceCode, and review every hit. In most small business tenants, the expected answer is zero. Anything other than zero is a conversation worth having with the user in question.
In April 2026, Microsoft Defender Security Research documented a widespread AI-enabled device code phishing campaign targeting hundreds of organizations. The attackers used automation and dynamic code generation to bypass the standard 15-minute expiration window, achieving significantly higher success rates than manual campaigns.
The post-compromise pattern was consistent: threat actors performed deep-dive reconnaissance into email communications, specifically targeting users with financial authority. They searched for wire transfer details, pending invoices, and executive correspondence. The median loss from successful BEC attacks following credential compromise is $50,000, with 95% of cases ranging between $250 and $985,000.
According to the FBI's Internet Crime Complaint Center, business email compromise scams caused over $55 billion in domestic and international losses between 2013 and 2023, with device code phishing emerging as a preferred initial access method in 2025-2026.
Source: Microsoft Security Blog - Inside an AI-enabled device code phishing campaign (https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/)
Once the attacker holds your tokens, they have days or weeks to work. In our experience, the first things they go after in an SMB tenant are predictable and devastating.
They read CEO and CFO mailboxes to learn the business: who pays whom, invoice patterns, internal language, pet names, sign-offs. This reconnaissance makes the next step land.
They search SharePoint and OneDrive for passwords. Spreadsheets called "passwords.xlsx", OneNote pages with banking portals, welcome guides with system credentials. We find this on every engagement.
They set up mailbox forwarding rules that silently copy every incoming email to an external address, or delete replies to specific senders. These rules survive password resets.
From the CFO's real mailbox, using their real writing style, on a real email thread: "Small admin thing, we've changed our bank details..." The money is gone before anyone notices.
If you are an MSP reading this, there is a harder conversation to have. Device code phishing against your clients is bad. Device code phishing against you is catastrophic.
When you manage multiple client tenants through delegated admin relationships (GDAP, or the older DAP model), a single compromised admin account at your MSP can cascade across your entire client base. One phished login, one set of tokens, and the attacker does not have access to one company. They have access to every client you manage, simultaneously, with administrative permissions.
If you are an MSP, your own identity perimeter is the most important security investment you can make. It is more important than any tool you sell to your clients, because if yours fails, theirs all fall at once.
Here is the genuinely useful part. The defences against device code phishing are not expensive, and most of them are already included in the Microsoft 365 licences you and your clients are already paying for. The hard part is not buying anything. It is knowing what to turn on.
1. Block the device code authentication flow The overwhelming majority of users never legitimately use device code authentication. In Microsoft Entra, create a Conditional Access policy targeting the "device code flow" authentication method. Turn it off broadly, add a narrow exception for specific users who genuinely need it. This single change is the highest-impact, lowest-cost thing on this list.
2. Require device compliance for sensitive access Conditional Access lets you tell Microsoft "only trust this sign-in if it is coming from a device that is enrolled in my management and marked as compliant." Turn this on for administrators, finance, and anyone with access to sensitive data. Even if a user falls for a device code phish, the attacker's unmanaged machine fails the compliance check.
3. Look at your sign-in logs This one costs nothing and almost nobody does it. Microsoft Entra keeps a detailed log of every authentication event in your tenant, and successful device code authentications are clearly marked. Filter for them directly. For most small organisations, any successful device code sign-in is suspicious until proven otherwise. Set up an alert.
4. Require phishing-resistant MFA for high-value users Push notifications and SMS codes are not enough any more. Physical security keys or Windows Hello for Business provide meaningfully stronger protection. While they don't fully stop device code phishing on their own, they raise the bar for everything else the attacker might try.
5. Shorten how long stolen tokens stay valid By default, refresh tokens can last up to 90 days. Conditional Access sign-in frequency policies let you reduce this substantially, forcing users to re-authenticate every few hours or every day. There is a user-experience cost, but it limits how long a stolen token keeps working.
6. Train your users on this specific pattern Device code phishing is one of the few attack patterns where targeted training genuinely helps, because the attack has a unique tell: someone asks you to enter a code they sent you into a Microsoft page. That sentence is worth more than an hour of generic phishing videos. If a message ever asks you to enter a code someone else provided, that is the moment to stop and pick up the phone.
7. MSPs: audit your partner admin access now Every delegated admin relationship you hold is a potential cascade path. Make sure every partner admin account uses phishing-resistant MFA, device code flow is blocked on your own tenant, and you are logging every administrative action into client tenants. This is your oxygen mask, put it on first.
| Timeframe | Actions |
|---|---|
| This Week (1-2 hrs) | Block device code flow + compliance policies + log monitoring |
| This Month (2-3 days) | FIDO2 rollout + token lifetime policies + user training |
| MSP Priority (Immediate) | Secure your own tenant before rolling out to clients |
We opened with the claim that identity is the new perimeter. The reason we say that is because the attacks that are actually working against organisations in 2026, against everyone from SMBs to global enterprises, are the ones that operate entirely above the endpoint, in the cloud identity layer that most security programmes are still learning to monitor.
Device code phishing is the clearest example, but it is not the only one. Adversary-in-the-middle phishing kits, session cookie theft, OAuth application abuse, help desk social engineering, they are all variations on the same theme. Compromise identity, bypass the endpoint entirely, operate in the cloud.
The defences exist and are mostly free. Turning them on takes knowing they matter, and that knowledge is not yet evenly distributed across the IT industry. We have walked into dozens of SMB and MSP environments over the last year where a single afternoon of configuration would have closed off attack paths that had been wide open for years. This is genuinely winnable. It is a question of attention, not budget.
In a follow-up post we will walk through the more advanced version of this attack chain: how device code phishing extends from Microsoft 365 into source code repositories, CI/CD pipelines, and cloud infrastructure. That is the version that keeps enterprise CISOs up at night, and it starts in exactly the same place. A friendly message and a legitimate-looking code.
Need Help Securing Your Identity Perimeter? At Forefront IT Security Services we help MSPs and SMBs understand, test and harden against the identity attack paths that define modern intrusions. If this post was useful, or worrying, we would like to hear from you.
One monthly plan, one front door: penetration testing, Cyber Essentials, AI security, training and advice, from £1,500 a month. No hidden costs.