Device-code phishing gets staff to sign in on the real Microsoft page and approve an attacker’s session, so passwords and MFA never come into it. Here’s how it works, the Conditional Access policy that stops it, and what to look for in your sign-in logs.<\/p>\n\n\n\n
Related guides<\/strong><\/p>\n\n\n\n Some devices can’t show a normal sign-in screen: a meeting-room console, a smart TV, a command-line tool. For these, Microsoft supports the "device code flow". The device shows a short code, you open microsoft.com\/devicelogin on your phone or laptop, type the code, sign in with your password and MFA, and the device is signed in.<\/p>\n\n\n\n Device-code phishing turns that around. The attacker starts the sign-in on their own machine, gets a genuine code from Microsoft, and sends it to the victim dressed up as something routine: an invoice, a shared document, a voicemail or a security alert. The victim goes to the real Microsoft page, enters the code and completes their usual MFA prompt. Microsoft then signs in the attacker’s session.<\/p>\n\n\n\n ASD’s description is blunt. The activity "doesn’t steal passwords or multi-factor authentication (MFA) codes", and it isn’t "a technical flaw in Microsoft systems". Once the victim approves, the attacker can "act as the victim without needing to input a password or MFA again."<\/p>\n\n\n\n That’s why the usual advice falls short. Hovering over the link shows a genuine microsoft.com address. The MFA prompt is real. Nothing about the sign-in looks wrong to the person doing it.<\/p>\n\n\n\n Device codes expire, usually after 15 minutes, so older campaigns failed when a victim was slow to open the email. That limit no longer helps much.<\/p>\n\n\n\n In April 2026 Microsoft’s threat researchers described a campaign in which the phishing page asks Microsoft for a new code at the moment the victim clicks, so the 15 minutes start then. Lures were written for specific roles, such as requests for proposal, invoices and manufacturing workflows. After a successful sign-in, Microsoft saw the attackers:<\/p>\n\n\n\n In other words, this is a route into business email compromise and invoice fraud. On 16 May 2026 ASD published its own warning on its official LinkedIn page, noting that attackers are "using automated systems and AI to request legitimate fresh codes at the exact moment a victim clicks."<\/p>\n\n\n\n Phishing-resistant MFA (passkeys, FIDO2 security keys, Windows Hello for Business, certificate-based sign-in) is built to defeat fake login pages. It binds the sign-in to the real Microsoft address, so a look-alike site can’t relay it.<\/p>\n\n\n\n Device-code phishing doesn’t use a fake site. The victim signs in on the genuine Microsoft page, so a passkey works normally, and the session it approves belongs to the attacker. Our reading of the attack flow is that the control that removes the risk is blocking the device code flow itself. Keep rolling out passkeys, because attackers mix techniques and phishing-resistant MFA shuts down most of the others, but don’t count it as your device-code defence.<\/p>\n\n\n\n You need at least the Conditional Access Administrator role for most of these steps. Conditional Access needs Microsoft Entra ID P1; Microsoft’s documentation also lists Microsoft 365 Business Premium as qualifying. Risk-based policies need Entra ID P2.<\/p>\n\n\n\n Most small and mid-sized organisations don’t, but meeting-room devices, some printers and admin tools sometimes do. Block blindly and you might take a boardroom screen offline.<\/p>\n\n\n\n In the Microsoft Entra admin center, go to Entra ID > Monitoring & health > Sign-in logs<\/strong>, add the Authentication protocol<\/strong> filter and choose Device code<\/strong>. Look back as far as your logs allow and check both interactive and non-interactive sign-ins.<\/p>\n\n\n\n Check:<\/strong> you have a list of every account and device that signed in with a device code, and a reason for each. Any user account on that list with no business reason is a red flag; see the investigation section below.<\/p>\n\n\n\n Look first for a policy called Microsoft-managed: Block device code flow<\/strong> under Entra ID > Conditional Access > Policies<\/strong> (filter the Created by<\/strong> column for Microsoft). Microsoft creates these in eligible tenants in report-only mode, emails a notice two weeks ahead, and switches them on no less than 30 days later unless you turn them off. If it’s there, review its Policy impact<\/strong> tab and turn it on.<\/p>\n\n\n\n If you’d rather build your own, Microsoft’s steps are:<\/p>\n\n\n\n If step 1 found a legitimate need, scope a narrow exception (for example, only the meeting-room accounts, from your office network) rather than leaving the flow open for everyone. Microsoft has separate guidance for Teams devices. One gotcha: if you register devices using the device code flow and your policy targets all resources, exclude the Device Registration Service<\/strong> resource (Target resources > Exclude<\/strong>).<\/p>\n\n\n\n Check:<\/strong> a test sign-in at microsoft.com\/devicelogin with a normal user account is blocked, and the sign-in log shows your policy as the reason.<\/p>\n\n\n\n Older protocols such as IMAP, POP3 and basic SMTP can’t do MFA. Microsoft says more than 99 per cent of password spray attacks use legacy authentication. There’s a Microsoft-managed policy for this too.<\/p>\n\n\n\n Check:<\/strong> filter sign-in logs by Client app<\/strong> for legacy clients over the past month. Nothing should succeed.<\/p>\n\n\n\n Create a Conditional Access policy with Grant > Require authentication strength > Phishing-resistant MFA strength<\/strong>. Start with every admin role, then extend it to staff as they register passkeys. Text-message and voice codes should be on their way out.<\/p>\n\n\n\n Check:<\/strong> in Entra ID > Authentication methods > Activity<\/strong>, the registration details show every admin has a phishing-resistant method registered, and the policy is On for them.<\/p>\n\n\n\n Sign-in risk and user risk policies can force reauthentication or block access when Microsoft’s detections flag a sign-in, including suspected token replay. The older risk policies configured inside ID Protection reached their retirement date on 1 October 2026, so these now belong in Conditional Access. Microsoft also ships managed policies for risky sign-ins and high-risk users.<\/p>\n\n\n\n Check:<\/strong> your risk policies show in the Conditional Access list (not in the old ID Protection blade), with break-glass accounts excluded.<\/p>\n\n\n\n Token protection makes Exchange Online, SharePoint Online and Teams accept only sign-in tokens bound to the registered device, so a stolen token can’t be replayed from elsewhere. It covers native desktop and mobile apps on registered devices (generally available on Windows, with Apple devices listed as preview); browser sessions to Microsoft 365 aren’t covered. Microsoft’s advice is to start with a pilot group in report-only mode and review the logs before enforcing.<\/p>\n\n\n\n Check:<\/strong> a report-only token protection policy is running for a pilot group, and you’ve reviewed which apps would fail.<\/p>\n\n\n\n Microsoft recommends anti-phishing policies and Safe Links in Defender for Office 365, and says Safe Links "can also enable high confidence Device Code phishing alerts". These won’t stop someone typing a code, but they catch more of the lures and give you an alert when one gets through.<\/p>\n\n\n\n Check:<\/strong> Safe Links and anti-phishing policies apply to all users, not just a pilot group.<\/p>\n\n\n\n ASD’s rule of thumb is the one to teach: "Avoid entering a Microsoft code to view something you weren’t expecting." Add "never approve a sign-in you didn’t start yourself" and tell staff exactly who to call when they’ve already typed one in. A fast report is worth more than a perfect click record.<\/p>\n\n\n\n Check:<\/strong> the rule is in your next awareness session, and staff know the reporting channel.<\/p>\n\n\n\n Your people are your best filter.<\/strong> Our security awareness training and phishing simulations teach staff to spot the scams that get past technology.<\/p>\n\n\n\n\n\n
TL;DR<\/h3>\n\n\n\n
\n\n
In this post<\/h3>\n\n\n\n
\n\n
What is device-code phishing?<\/h2>\n\n\n\n
\n\n\n\nWhat changed in 2026?<\/h2>\n\n\n\n
\n\n
\n\n\n\nWhy won’t passkeys alone stop it?<\/h2>\n\n\n\n
\n\n\n\nThe hardening checklist, in priority order<\/h2>\n\n\n\n
1. Find out whether anyone actually uses the device code flow<\/h3>\n\n\n\n
2. Block the device code flow with Conditional Access<\/h3>\n\n\n\n
\n\n
3. Block legacy authentication<\/h3>\n\n\n\n
4. Move admins, then everyone, to phishing-resistant MFA<\/h3>\n\n\n\n
5. Turn on risk-based policies (Entra ID P2)<\/h3>\n\n\n\n
6. Pilot token protection<\/h3>\n\n\n\n
7. Tighten email protection<\/h3>\n\n\n\n
8. Give staff one simple rule<\/h3>\n\n\n\n