The Australian Signals Directorate issued a formal warning on 20 May 2026 about a type of cyberattack targeting Australian Microsoft 365 users — and it is not a standard phishing campaign. Device code phishing attacks are active in Australia right now, and they are designed to bypass Multi-Factor Authentication entirely. If your organisation uses Microsoft 365 and has not reviewed your Conditional Access policies recently, this warning is for you.

This is not a drill, and the usual advice does not apply here. You cannot spot this attack by looking for a suspicious email. Your password will not be stolen. Your MFA prompt will not be triggered in the usual way. The attacker simply walks in through a door that most organisations have left unlocked — the device code authentication flow.

Here is what you need to know.

What Is Device Code Phishing?

The Short Version

Device code phishing is an attack that tricks a user into handing over full access to their Microsoft 365 account without ever revealing their password. The attacker uses a legitimate Microsoft authentication feature to do it.

How the Attack Works, Step by Step

Microsoft’s device code flow exists for a real purpose. It is designed for devices that cannot easily accept input, like smart TVs, printers, or shared terminals. Instead of logging in directly, the device shows the user a code and directs them to microsoft.com/devicelogin. The user enters the code on a separate device, authenticates, and the original device gains access to their account.

The attack works by hijacking this flow:

1. The attacker initiates a device code request. They visit a legitimate Microsoft page and generate a valid device code tied to their own session.
2. They send the code to the target. This typically arrives via email, Teams message, LinkedIn, or even a phone call. The message is designed to look urgent and legitimate — an IT alert, a licence expiry notice, a security verification request.
3. The target is directed to a real Microsoft page. This is where the attack becomes especially difficult to detect. The URL is genuine. The page is genuine. Microsoft’s branding is everywhere.
4. The target enters the code. Because the page looks completely authentic and the request appears reasonable, many users comply. They authenticate using their own credentials and complete any MFA prompts as normal.
5. The attacker now has full access. The moment the target authenticates, the token is handed to the attacker’s session. They gain persistent access to the Microsoft 365 account, including email, SharePoint, Teams, OneDrive, and any connected applications.
6. The token persists. Access tokens can remain valid for extended periods. Unless the organisation has short token lifetimes configured, the attacker may retain access for hours, days, or longer.

Why This Is Different From Standard Phishing

Traditional phishing tries to steal a password through a fake login page. Security teams train users to spot fake URLs and suspicious login screens. That training is useful, but it does not apply here. The page the victim visits is real. The URL is a genuine Microsoft domain. No credential harvesting takes place.

Device code phishing is a token theft attack. The attacker never sees the user’s password. They receive an OAuth access token, which is functionally equivalent to being logged in.

Why MFA Does Not Stop This Attack

This is the part that catches most organisations off guard. Multi-Factor Authentication is one of the most effective security controls available, and for most phishing attacks, it works well. Device code phishing is an exception, and it is important to understand why.

When a user is tricked into entering the device code on the legitimate Microsoft page, they will still be prompted to complete their usual MFA challenge. They enter their authenticator app code, approve the push notification, or use a hardware key. From their perspective, everything looks normal.

The problem is that the MFA confirmation authenticates the token that the attacker generated. The user has successfully proved their identity to Microsoft. Microsoft issues the access token. And because the attacker initiated the device code flow, the access token goes to them.

MFA prevents attackers from logging in with a stolen password. It does not prevent this attack, because no password was stolen. The user authenticated themselves, willingly and correctly, without realising they were authorising a session for someone else.

This is why the ASD’s warning is significant. Organisations that have deployed MFA across their Microsoft 365 environment may believe they are protected. Against device code phishing, that assumption is incorrect without additional controls in place.

Who Is Being Targeted in Australia?

The ASD’s Assessment

The ASD confirmed on 20 May 2026 that active device code phishing campaigns are targeting Australian Microsoft 365 users. The warning was issued in response to observed attack activity, not as a theoretical precaution.

The Primary Targets

Australian professional services firms are at elevated risk. Law firms, accounting practices, financial advisers, and consulting businesses rely heavily on Microsoft 365 for daily operations. Their email systems contain sensitive client data, financial records, and privileged communications — all of which are accessible through a compromised M365 account.

Other high-value targets include:

• Small to mid-sized businesses with limited in-house IT security capability
• Organisations with remote or hybrid workforces, where device-based authentication flows are more common
• Businesses with third-party vendor relationships, where an attacker who compromises one account can pivot to others
• Any organisation using Microsoft Teams for external communication, where socially engineered messages can arrive from compromised third-party accounts

The attack does not require the organisation to be large or prominent. Device code phishing is highly scalable, and AI is accelerating attackers’ ability to generate convincing social engineering content at volume.

The Role of AI in These Campaigns

Attackers are using AI tools to generate personalised, contextually appropriate messages that accompany the device code. Instead of a generic “your account needs verification” message, AI-generated content can reference the recipient’s name, role, organisation, and even specific tools they use. This makes the social engineering component significantly more convincing and harder to dismiss.

What the ASD Is Recommending

The ASD’s guidance focuses on technical controls that remove the attack surface entirely, rather than relying solely on user awareness.

Key recommendations include:

• Disable device code flow for all users who do not require it. Most business users have no legitimate need to authenticate via the device code flow. Blocking it at the Conditional Access level eliminates the risk for those users.
• Implement Conditional Access policies that restrict authentication to compliant, managed devices.
• Review OAuth token lifetimes and configure short-lived tokens where possible, reducing the window of access if a token is compromised.
• Enable sign-in risk policies within Microsoft Entra ID (formerly Azure AD) to flag and respond to anomalous authentication events.
• Conduct user awareness training specifically covering device code phishing. Standard phishing recognition training does not address this attack vector.

The ASD also recommends that organisations report any suspected incidents to ReportCyber and engage with the Australian Cyber Security Centre (ACSC) for further guidance.

What IT Teams and MSPs Should Do

For internal IT teams and managed service providers supporting Australian businesses, the priority is implementing the technical controls that block this attack at the source.

Block Device Code Flow in Conditional Access

Microsoft Entra ID allows administrators to create Conditional Access policies that block the device code authentication flow. This is the single most effective technical control for this specific threat.

To block device code flow:

• Navigate to Microsoft Entra admin centre
• Open Conditional Access and create a new policy
• Under Cloud apps or actions, select All cloud apps or scope to Microsoft 365 specifically
• Under Conditions, select Authentication flows and include Device code flow
• Under Grant, select Block access
• Apply to all users, with exceptions for any devices or scenarios that legitimately require this flow

If your organisation uses devices that genuinely require device code authentication (shared terminals, kiosk devices, etc.), create a named location or device filter to exempt those specific scenarios.

Require Compliant Devices for Authentication

Zero Trust architecture assumes no device or user is inherently trusted. Conditional Access policies should require that authentication originates from a device that is enrolled in Microsoft Intune and marked as compliant. This prevents an attacker from completing the device code flow on an unmanaged device.

Block Legacy Authentication

Legacy authentication protocols do not support modern MFA and provide additional attack surface. Block legacy authentication across your Microsoft 365 environment using Conditional Access. Microsoft provides a baseline policy for this, and it should be enforced on all tenants.

Enable Continuous Access Evaluation

Continuous Access Evaluation (CAE) allows Microsoft 365 to revoke access tokens in near-real time when policy conditions change. This reduces the window of risk if a token is compromised.

Review and Shorten Token Lifetimes

Default Microsoft token lifetimes can be extended, particularly for refresh tokens. Review your token lifetime policies and configure them to balance user experience against security requirements. Shorter lifetimes mean a compromised token has a smaller window of use.

Monitor for Anomalous Sign-Ins

Set up alert rules in Microsoft Sentinel or Entra ID Protection to flag sign-ins using device code flow, particularly from unexpected locations, IP ranges, or device types. This provides detection capability alongside the preventative controls above.

If you would like help reviewing your Microsoft 365 security posture and implementing these controls, our managed cyber security services include a full review of Conditional Access policies and Zero Trust configuration.

What Employees Should Know

User awareness is not the primary defence against device code phishing, but it is still an important layer. Employees who understand this attack vector are less likely to be deceived.

Train Staff on This Specific Scenario

Standard phishing training focuses on spotting fake login pages, suspicious links, and unusual sender addresses. Device code phishing bypasses all of those indicators. Users need to understand:

• No legitimate IT process requires you to enter a code at microsoft.com/devicelogin unless you are setting up a specific device type (like a TV or kiosk).
• If you receive an urgent request to enter a code on a Microsoft page, treat it as suspicious and verify directly with your IT team before proceeding.
• Attackers will use legitimate-looking messages from email, Teams, LinkedIn, or phone. The source of the message does not guarantee legitimacy.
• Completing MFA does not make the action safe. In this attack, MFA is part of the process the attacker wants you to complete.

What a Real Device Code Request Looks Like

Legitimate device code prompts are initiated by the device itself, not by an external message. If you are prompted to visit microsoft.com/devicelogin in response to a message from another person, stop and verify with your IT team first.

Report Suspicious Requests Immediately

If an employee believes they may have entered a device code in response to a suspicious request, this should be treated as a potential account compromise. IT teams should revoke active sessions in Microsoft Entra ID and investigate immediately.

The EvilTokens Threat: What Is Now Actively Targeting Australian Organisations

Since the original publication of this warning, the device code phishing threat has accelerated significantly. The “EvilTokens” Phishing-as-a-Service (PhaaS) platform, launched in February 2026, has been implicated in compromising numerous Microsoft 365 organisations in Australia and internationally. Cybersecurity firm Proofpoint reported an “explosion” of device code phishing across the threat landscape in early 2026, with new tools emerging frequently and attack volumes continuing to climb.

What makes EvilTokens and similar platforms particularly dangerous is the automation they provide. Attackers who previously needed technical skill to execute device code phishing campaigns can now purchase access to a ready-made platform that handles the code generation, delivery, and token capture automatically. This has dramatically lowered the barrier to entry and increased the volume of campaigns targeting Australian businesses.

AI Is Accelerating the Social Engineering Component

Attackers are using AI tools to generate personalised, contextually appropriate messages that accompany the device code. Instead of a generic “your account needs verification” message, AI-generated content can reference the recipient’s name, role, organisation, and the specific tools they use. Proofpoint’s research found that AI-generated lures in device code phishing campaigns are significantly more convincing than manually crafted messages, with higher click-through rates as a direct result. The ASD confirmed in May 2026 that AI is playing a central role in the acceleration of these campaigns in Australia specifically.

What Microsoft Has Added for Protection

Microsoft’s Defender for Office 365 now provides specific protection against device code phishing by detecting anomalous device code authentication patterns. This capability is available to organisations with Microsoft 365 Defender licencing and should be enabled as part of your baseline security configuration. Microsoft Entra ID Protection can also be configured to flag and block high-risk sign-in events that match known device code phishing patterns. These controls work alongside, not instead of, the Conditional Access policies described in this post. If your Microsoft 365 environment is managed by an external provider, confirming these protections are active should be your immediate next step.

Essential Eight and Modern Authentication

Where Device Code Phishing Sits in the Essential Eight Framework

The Australian Signals Directorate’s Essential Eight framework provides a baseline of eight mitigation strategies for Australian businesses. Several of these are directly relevant to device code phishing.

Restrict Administrative Privileges (Maturity Level 2 and above) recommends that privileged accounts are not used for standard activities. Compromising an admin account via device code phishing provides significantly more access than compromising a standard user account.

Multi-Factor Authentication is required at Maturity Level 2 and above. While MFA alone does not stop device code phishing, it remains an essential control for the broad range of other attacks that do attempt to steal credentials.

Patch Applications and Patch Operating Systems reduce the available attack surface if an attacker who has gained initial access attempts to escalate privileges or move laterally.

Modern Authentication Is the Foundation

Organisations that have fully transitioned to modern authentication protocols (OAuth 2.0, OpenID Connect) and disabled legacy authentication have a significantly smaller attack surface. Modern authentication is a prerequisite for Conditional Access policies to function effectively.

If your Microsoft 365 environment still supports legacy authentication protocols, this is an urgent item to address. Otto IT’s managed cyber security services include an assessment of authentication configuration as part of our Microsoft 365 security review.

Zero Trust Architecture

Zero Trust is the architectural model that underpins effective defence against token-based attacks. The principle is simple: never trust, always verify. Every access request is evaluated against policy, regardless of where it originates or what credentials were used.

Implementing Zero Trust for Microsoft 365 typically involves:

• Conditional Access policies enforcing compliant device requirements
• Identity protection and risk-based sign-in policies
• Privileged Identity Management for administrative roles
• Continuous access evaluation and token revocation

These are not aspirational controls. They are available today in Microsoft Entra ID and Microsoft 365, and they can be configured and enforced with the right expertise.

Frequently Asked Questions

Is my business at risk if we use Microsoft 365?

Yes, if you have not configured Conditional Access policies that block device code flow. Microsoft 365 has the tools to block this attack, but those controls require deliberate configuration. Out-of-the-box settings may leave the device code flow enabled for all users.

Does this attack work on personal accounts?

Device code phishing can target any Microsoft account that supports the device code authentication flow. However, the ASD’s warning specifically concerns business Microsoft 365 environments, where the impact of a compromised account is significantly higher.

How would I know if we had been compromised this way?

Attackers who gain access via device code phishing often proceed quietly. They may read emails, exfiltrate data, set up forwarding rules, or use the compromised account to target others in your organisation. Signs to look for include unfamiliar sign-in locations in your Microsoft Entra audit logs, email rules you did not create, or unexpected Teams messages sent from staff accounts. If you suspect a compromise, engage your IT team immediately.

Can antivirus or endpoint detection tools stop this attack?

Standard endpoint security tools are unlikely to detect or block this specific attack, because the user is interacting with legitimate Microsoft infrastructure. The attack exploits a feature of the authentication system, not a vulnerability in endpoint software. Conditional Access policies in Microsoft Entra ID are the appropriate control.

What should we do right now?

Start with three actions. First, check whether device code flow is currently blocked in your Conditional Access policies. Second, confirm that legacy authentication is blocked across your Microsoft 365 environment. Third, brief your staff on what a device code phishing attempt looks like so they can identify and report suspicious requests. If you need support with any of these, contact the Otto IT team.

What to Do Next

Device code phishing is active in Australia. The ASD has confirmed it. The attack bypasses MFA, uses legitimate Microsoft infrastructure, and leaves little to detect without the right monitoring in place. The good news is that effective controls exist and can be implemented quickly with the right support.

Otto IT specialises in Microsoft 365 security for Australian professional services firms. Our team can review your Conditional Access configuration, block device code flow, implement Zero Trust controls, and train your staff on this specific threat.

Review your Microsoft 365 security posture with Otto IT

Book a security review today

If you have an urgent concern or believe your organisation may already be affected, contact us directly and we will respond promptly.