On 16 May 2026, the Australian Signals Directorate (ASD) issued an advisory about a phishing campaign targeting Microsoft 365 users across Australia. It does not steal passwords. It does not intercept multi-factor authentication codes. And it uses real Microsoft login pages, not fake ones.
It is called device code phishing, and it is one of the most convincing attack techniques security teams are seeing right now.
This article explains what device code phishing is, how it works step by step, why traditional defences struggle to stop it, and what Sydney businesses should do to protect their Microsoft 365 environments.
What Is Device Code Phishing?
Device code phishing exploits a legitimate Microsoft sign-in feature called the device code flow. This flow was designed for situations where a device cannot easily display a keyboard or browser, such as smart TVs, printers, or IoT devices. Microsoft generates a short alphanumeric code (usually 9 characters) and a link. The user visits the link on their phone or computer, enters the code, and signs in. The original device then receives an authentication token.
In a device code phishing attack, the attacker is the one who starts this process. They generate a real Microsoft code and link, then send it to a victim disguised as a document request, Teams notification, or security alert. When the victim enters the code and completes their normal sign-in (password plus MFA), they are not signing themselves in. They are approving access for the attacker’s device.
The result is that the attacker gets a fully authenticated session, with a valid access token, without ever knowing the victim’s password.
How the Attack Works – Step by Step
Understanding the mechanics is the key to spotting it. Here is how a typical device code phishing attack unfolds:
1. The attacker initiates a device code request. The threat actor starts the Microsoft device sign-in flow, pretending to be a legitimate device. Microsoft generates a short code and a URL. Both are real, both hosted on Microsoft infrastructure.
2. The victim receives a convincing message. The attacker sends the code and link to the target via email, SMS, or a collaboration platform. The message might look like a SharePoint document request, a Teams file share, or a Microsoft security alert. Everything points to a genuine Microsoft domain.
3. The victim signs in on a real Microsoft page. The victim clicks the link, enters the code, and completes their usual sign-in with password and MFA. Nothing looks suspicious – because nothing is suspicious. The page is authentic.
4. The attacker’s session is authenticated. Because it was the attacker who initiated the device code request, Microsoft’s system associates the completed sign-in with the attacker’s pending session. The attacker now holds a valid token and can access the victim’s account as if they were the victim.
5. The attacker operates freely. With an authenticated session, the attacker can read emails, access SharePoint files, send messages, and move laterally through the organisation without triggering any password-based alerts.
Why This Attack Is Getting More Dangerous
The ASD advisory highlighted a worrying evolution in how attackers are now using automation and AI to make device code phishing far more reliable.
Previously, device codes expired after 15 minutes. If a victim was slow to act, the attack failed. But threat actors are now deploying automated systems that generate a fresh code at the exact moment a victim clicks a link. This real-time code generation dramatically increases the success rate.
This is not a theoretical risk. Microsoft has documented entire campaigns built around this technique, with attackers using AI to craft convincing lures and automate the code-generation pipeline at scale.
Why Traditional Defences Struggle
Device code phishing is difficult to detect and block for several reasons:
- No fake domains to flag. The login page is a real Microsoft URL. Email filters and link scanners see a legitimate domain.
- No stolen credentials to detect. The attacker never obtains the victim’s password or MFA token. There is no credential-theft event to trigger alerts.
- Blends with normal traffic. The authentication looks like a standard enterprise cloud sign-in from a new device.
- Bypasses phishing-resistant MFA. Even hardware security keys and authenticator apps cannot prevent this attack, because the user is the one willingly completing the sign-in.
As the ASD noted, this activity “intentionally blends in with legitimate enterprise cloud traffic,” making it a challenge for conventional security monitoring.
How to Protect Your Business
The ASD and Microsoft both recommend a combination of policy-based controls and user awareness. Here is what matters most for Australian businesses running Microsoft 365.
Enforce Conditional Access Policies
Conditional Access is Microsoft’s policy engine for identity-based security. It evaluates every sign-in attempt against rules you define. For defending against device code phishing, these policies are critical:
- Token protection (token binding) Binds authentication tokens to specific devices, so a token stolen or obtained through device code phishing cannot be used on a different machine.
- Compliant device requirements Require that sign-ins come from devices enrolled in Intune and marked as compliant. Attackers’ devices will not meet this requirement.
- Location and risk-based controls Block or challenge sign-ins from unusual locations or those flagged as high risk by Microsoft Entra ID Protection.
- Restrict device code flow If your organisation does not use the device code flow for legitimate purposes, you can disable it entirely through Microsoft Entra ID settings.
Train Your Team to Recognise the Pattern
Technical controls are essential, but the human element remains the front line. The ASD advisory emphasises one golden rule.
Never enter a Microsoft code to view something you were not expecting.
Specifically, train staff to:
- Be cautious of unexpected messages asking them to sign in or enter a code
- Never approve a sign-in they did not personally initiate
- Question urgent requests involving documents, invoices, or security alerts
- Verify unexpected requests through a separate channel (phone call, in-person check)
Implement Anti-Phishing Policies
Microsoft Defender for Office 365 includes anti-phishing policies that can detect and block phishing messages before they reach inboxes. Ensure these are configured with:
- Impersonation protection for executives and high-value targets
- Mailflow rules that flag messages containing device code patterns
- Advanced delivery configurations for security operations teams
Review Sign-In Logs Regularly
Monitor Microsoft Entra sign-in logs for:
- Authentication via the device code flow (client credential type)
- Sign-ins from unexpected locations or devices
- Multiple failed device code attempts, which may indicate an attacker probing
Why Sydney Businesses Should Pay Attention
Australian businesses are prime targets for cloud-focused phishing campaigns. The ASD’s annual cyber threat report consistently identifies phishing as the number one initial access method used by cyber actors against Australian organisations.
Microsoft 365 is the backbone of most Sydney businesses’ daily operations, covering email, file storage, collaboration, and often telephony. A compromised Microsoft 365 account gives an attacker access to all of it.
If your business handles client data, financial records, or intellectual property (and most do), a single compromised account can lead to a data breach, regulatory exposure under the Privacy Act, and reputational damage that takes years to repair.
For Sydney firms subject to compliance frameworks like the Essential Eight or SMB1001, device code phishing is exactly the type of identity-based attack that these frameworks aim to address through MFA enforcement and access controls.
What to Do Right Now
If you are an IT decision-maker at a Sydney business, here is a practical checklist:
- Check if device code flow is enabled in your Microsoft Entra ID tenant. If your organisation does not need it, disable it.
- Review your Conditional Access policies. At minimum, ensure compliant device requirements and token protection are in place.
- Brief your team. Share the ASD’s advice that staff should never enter a Microsoft code to view something they were not expecting.
- Enable sign-in log monitoring for device code authentication events.
- Update your security awareness training to include device code phishing scenarios.
Frequently Asked Questions
Can MFA stop device code phishing?
No. Device code phishing bypasses MFA because the victim completes their own MFA challenge. The attacker never sees the MFA code – they receive the resulting session token instead. This is why policy-based controls like Conditional Access are essential alongside MFA.
How is device code phishing different from regular phishing?
Regular phishing steals credentials by directing victims to fake login pages. Device code phishing uses real Microsoft login pages and does not steal passwords at all. Instead, it tricks the user into authorising the attacker’s device. The victim completes a legitimate sign-in on a legitimate site. The victim grants access to the wrong session.
Is my business at risk if we use Google Workspace instead of Microsoft 365?
The device code flow is a feature of Microsoft’s identity platform. If your organisation does not use Microsoft 365 or Microsoft Entra ID, this specific attack does not apply. However, similar token-theft techniques exist across cloud platforms, so the principle of policy-based identity controls remains relevant.
How do I disable device code flow in Microsoft 365?
In the Microsoft Entra admin centre, navigate to App registrations > Authentication settings, or use Microsoft Graph API to set the `deviceCode` property to disabled for applications that do not require it. Your IT provider can configure this across your tenant.
What should I do if an employee entered a device code from an unexpected message?
Act immediately. Sign the user out of all sessions in the Microsoft Entra admin centre, revoke their refresh tokens, reset their password as a precaution, and review the sign-in logs for any activity from the attacker’s session. If data access is confirmed, follow your incident response plan.
The Bottom Line
Device code phishing represents a shift in how attackers target businesses. They are no longer trying to steal your password. They are tricking you into handing them a valid session.
The ASD’s advisory makes clear that this threat is active, targeting Australian organisations, and getting more sophisticated with AI-driven automation. If your business runs on Microsoft 365, your cyber security and identity policies need to account for this threat.
Need help reviewing your Microsoft 365 security posture? Milnsbridge has been protecting Sydney businesses since 2002. Get in touch with our team for a security assessment tailored to your environment.
Sources | Australian Signals Directorate, “Device Code Phishing: A Growing Threat to Microsoft 365 Users,” 16 May 2026. Microsoft Security Blog, “Inside an AI-enabled Device Code Phishing Campaign”.
About the Author
Adrian Weir
Adrian Weir is the Managing Director and founder of Milnsbridge Managed IT Services, with over 30 years of global IT experience spanning Telstra, Citibank, Unilever, and hundreds of Sydney SMBs. A Microsoft Partner since 2002, Adrian leads a team of IT specialists delivering responsive, business-focused managed IT support across Greater Sydney.
Meet the Milnsbridge Team
