MFA isn’t enough: how device-code phishing hijacks Microsoft 365

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.

What is device-code phishing?

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.

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.

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."

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.

What changed in 2026?

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.

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:

• register a new device, in some cases within 10 minutes, to get a longer-lived sign-in token for persistence
• map the organisation’s structure and permissions
• create inbox rules hours later, and search mail for wire transfer details, pending invoices and executive correspondence.

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."

Why won’t passkeys alone stop it?

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.

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.

The hardening checklist, in priority order

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.

1. Find out whether anyone actually uses the device code flow

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.

In the Microsoft Entra admin center, go to Entra ID > Monitoring & health > Sign-in logs, add the Authentication protocol filter and choose Device code. Look back as far as your logs allow and check both interactive and non-interactive sign-ins.

Check: 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.

2. Block the device code flow with Conditional Access

Look first for a policy called Microsoft-managed: Block device code flow under Entra ID > Conditional Access > Policies (filter the Created by 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 tab and turn it on.

If you’d rather build your own, Microsoft’s steps are:

1. New policy. Under Users, include All users and exclude your emergency access (break-glass) accounts.
2. Under Target resources, include All resources.
3. Under Conditions > Authentication flows, set Configure to Yes and tick Device code flow.
4. Under Access controls > Grant, choose Block access.
5. Set the policy to Report-only, review the results, then switch it On.

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 resource (Target resources > Exclude).

Check: 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.

3. Block legacy authentication

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.

Check: filter sign-in logs by Client app for legacy clients over the past month. Nothing should succeed.

4. Move admins, then everyone, to phishing-resistant MFA

Create a Conditional Access policy with Grant > Require authentication strength > Phishing-resistant MFA strength. 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.

Check: in Entra ID > Authentication methods > Activity, the registration details show every admin has a phishing-resistant method registered, and the policy is On for them.

5. Turn on risk-based policies (Entra ID P2)

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.

Check: your risk policies show in the Conditional Access list (not in the old ID Protection blade), with break-glass accounts excluded.

6. Pilot token protection

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.

Check: a report-only token protection policy is running for a pilot group, and you’ve reviewed which apps would fail.

7. Tighten email protection

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.

Check: Safe Links and anti-phishing policies apply to all users, not just a pilot group.

8. Give staff one simple rule

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.

Check: the rule is in your next awareness session, and staff know the reporting channel.

How to tell if you’ve already been hit

Start with the sign-in logs filter from step 1. Then look for these signs, roughly in this order:

• Device-code sign-ins by ordinary users. Any success from an account that had no reason to use the flow, especially from an unfamiliar location or IP address. In the sign-in details, the Original transfer method field shows when a session began with a device code.
• A pause, then success. Microsoft’s hunting guidance looks for error code 50199 followed shortly by a successful sign-in for the same user, which suggests someone pausing to type in a code from a phishing email.
• New devices. Check Entra ID > Devices for devices registered recently to the affected user, particularly ones nobody recognises.
• New inbox rules. Rules that move, delete or forward mail, especially with names made only of punctuation or symbols, are a classic sign of attackers hiding replies.
• Unusual mailbox access. Searches for invoices, payments or bank details, or bulk mail access, in the audit log.
• Risky sign-ins. The Risky sign-ins and Risky users reports in Entra ID, if you’re licensed for them.

What to do if you find one

1. Revoke sessions. In Entra ID, open the user and select Revoke sessions. Microsoft notes that access tokens can stay valid for up to an hour, so consider disabling the account briefly as well.
2. Remove what the attacker added. Delete or disable devices they registered, remove inbox rules and forwarding, and review the user’s registered MFA methods.
3. Reset the password and confirm the user re-registers MFA on a device you trust.
4. Check what was accessed and sent. Look for payment-redirection emails sent from the account and warn the recipients.
5. Report it. Report it at cyber.gov.au/submit-a-report. If personal information may have been accessed, assess whether the Notifiable Data Breaches scheme applies. This is general information, not legal advice.
6. Close the door. Work through steps 2 to 8 of the checklist so the same trick doesn’t work twice.

If you want a second pair of eyes on your Conditional Access policies and sign-in logs, our Microsoft 365 security review covers this ground, and email protection deals with the lures. For the wider identity baseline, see ASD Essentials and our ASD Essentials guide for small business.

Key takeaways

• Device-code phishing uses Microsoft’s genuine sign-in page and the victim’s own MFA, so link checks and MFA don’t stop it.
• Blocking the device code flow with Conditional Access is the control that removes the risk. Check for the Microsoft-managed policy first.
• Run the block in report-only mode, carve out any real meeting-room or device needs narrowly, then turn it on.
• Keep rolling out phishing-resistant MFA, risk policies and token protection; they shut down the attacks that usually come alongside this one.
• Teach one rule: never enter a Microsoft code for something you didn’t ask for, and report it fast if you already have.

Sources

• Australian Signals Directorate (official LinkedIn page, linked from cyber.gov.au), Device code phishing: a growing threat to Microsoft 365 users (16 May 2026)
• Microsoft Security Blog, Inside an AI-enabled device code phishing campaign (6 April 2026)
• Microsoft Learn, Block authentication flows with Conditional Access policy
• Microsoft Learn, Authentication flows as a condition in Conditional Access policy
• Microsoft Learn, Microsoft-managed Conditional Access policies
• Microsoft Learn, Conditional Access authentication strengths
• Microsoft Learn, Risk-based access policies
• Microsoft Learn, Token protection in Conditional Access