The number of phishing attempts targeting Microsoft 365 accounts is currently rising rapidly, and new methods are emerging continuously. In new device code phishing attacks, the user may not give their password to the criminal. Instead, they are tricked into entering a login code provided by the attacker on Microsoft's genuine sign-in page.
The outcome can be serious: the attacker may gain access to an active session and access email, Teams, OneDrive, SharePoint, or other Microsoft 365 services used by the company.
On 21 May 2026, the Finnish National Cyber Security Centre at Traficom warned about an AI-assisted device code phishing campaign and said it had also received reports of similar cases in Finland. Microsoft, for its part, has described campaigns in which the device code authentication flow is used to hijack organisational accounts.
For an SME, it is not enough to know what the attack does technically. It is essential to check whether the Microsoft 365 environment has unnecessarily permitted sign-in methods, incomplete access control policies, or unusual sign-ins that nobody is monitoring.
Device code sign-in is a login method used by Microsoft and other cloud services in situations where entering credentials directly on the device is difficult. A typical example is a meeting-room device, television, printer, or another device that displays a short code to the user.
Under normal circumstances, the sign-in process works as follows:
The feature itself is useful, but in an attack the same mechanism is abused.
The attacker starts the sign-in process on their own device and obtains a sign-in code. The user is then sent a convincing message asking them to open Microsoft's genuine sign-in page and enter that code.
The message may appear to be:
When the user enters the code and approves the sign-in, they may not actually be signing in to a new service themselves. At the same time, they may be approving the attacker's device or session.
This makes the attack difficult to detect. The user visits a genuine Microsoft page, the sign-in may appear normal, and even multi-factor authentication may be completed successfully.
For many SMEs, Microsoft 365 is effectively the digital foundation of the entire business. Email, calendars, invoice communications, contracts, documents, Teams conversations, and customer collaboration all take place within the same environment.
If an attacker gains access to even one user account, they may attempt to:
This is not merely a technical cybersecurity issue. It is a business risk.
What makes this particularly difficult is that the password may not be exposed at all. In that case, the traditional approach of “change the password and the problem is solved” is not enough. The attacker may have an active session or token that must be revoked separately.
Multi-factor authentication, or MFA, remains an important security measure. Its value should not be underestimated.
However, device code phishing demonstrates that not all MFA methods provide the same level of protection. If a user can be tricked into approving a sign-in on Microsoft's genuine page, the attack may succeed without stealing the password or breaking the MFA code.
That is why companies need to check three things:
If the answer is “we don't know”, the check should be carried out now.
The first question is simple: is device code flow actually used in your Microsoft 365 environment?
Many SMEs have no need for it when ordinary users sign in. If it is needed, the requirement often relates to specific devices or tools, such as meeting rooms, shared devices, or command-line tools.
Check the Microsoft Entra ID sign-in logs to see whether there are sign-ins where the authentication protocol is device code flow.
At a minimum, find out:
If the use cannot be linked to a genuine business need, it should not be left enabled.
Microsoft recommends blocking device code flow wherever it is not needed. If it is needed, its use should be restricted carefully to approved use cases only.
In practice, this is done using Microsoft Entra ID Conditional Access policies. A good approach is to:
This should not be done blindly, because an incorrectly configured Conditional Access policy can also block necessary sign-ins. On the other hand, leaving device code flow completely unrestricted unnecessarily increases the attack surface.
From an attacker's perspective, not all user accounts are equally valuable.
Accounts of particular interest include:
These users should have stronger sign-in protection requirements than ordinary users.
This may mean using phishing-resistant MFA, such as FIDO2 security keys or passkey-based methods.
At a minimum, make sure that critical users do not rely solely on a simple approval button, text-message codes, or other MFA methods that can be easily phished.
After a device code phishing attack, the attacker's session may appear as a sign-in that differs from the user's normal activity.
At a minimum, check whether the Microsoft 365 environment monitors:
A single anomaly does not always indicate a breach. But if anomalies are not monitored at all, a successful attack may go unnoticed for a long time.
When an attacker gains access to email, they may try to hide their tracks.
Common signs include:
For this reason, it is worth checking Exchange Online settings and email rules in addition to sign-ins.
The mailboxes of management and finance staff should be checked with a low threshold if anything unusual appears in the sign-in history.
Device code phishing often starts with a message. The message may arrive as an email, calendar invitation, document request, or appear to come from a business partner.
At a minimum, check:
It is important to understand that the attack may use Microsoft's genuine sign-in page. Therefore, the apparent legitimacy of the external link alone is not enough to assess the message.
Technical protection alone is not enough if users do not know what the attack looks like.
The guidance should be short and concrete:
Do not enter a sign-in code on Microsoft's website if you did not just initiate a sign-in on that device or in that application.
Users should also be told that the attack may arrive disguised as a genuine-looking document request, electronic signature request, calendar invitation, IT support message, or message from a business partner.
Good user guidance does not blame the user. It provides a clear course of action:
Possible signs include:
If the suspected account belongs to management, finance, or an administrator, the matter should be treated as urgent.
If a user has entered the code or suspicious activity appears in the sign-in history, act quickly.
First steps:
Changing the password alone may not be enough, because the attack may involve an active session rather than just the password. Revoking sessions and invalidating tokens are therefore essential.
| Check | Why is it important? |
|---|---|
| Is device code flow in use? | An unnecessarily permitted sign-in method increases the attack surface. |
| Is device code flow actually needed? | If there is no genuine need, it should be blocked or restricted. |
| Is Conditional Access in use? | Conditional Access helps restrict sign-ins based on the situation, user, and device. |
| Is device code flow blocked or restricted? | This directly reduces the likelihood of a device code phishing attack succeeding. |
| Are management, finance, and administrators specially protected? | Compromising these accounts often has the greatest business impact. |
| Do critical users use phishing-resistant MFA? | Not all MFA methods provide the same level of protection against phishing. |
| Are sign-ins from new countries monitored? | The attacker's session may appear as an unusual location. |
| Is impossible travel monitored? | Unrealistic changes in location may indicate account misuse. |
| Are suspicious inbox rules checked? | An attacker may use email rules to hide their tracks. |
| Are email link and phishing protections enabled? | The attack often starts with an email, document request, or calendar invitation. |
| Have users been given clear instructions? | Users need to know not to enter a code if they did not initiate the sign-in themselves. |
Device code phishing is a good example of why Microsoft 365 security is not a one-time configuration project.
Even when MFA is enabled, old exceptions, incomplete sign-in policies, or sign-in methods that are no longer needed may remain in the environment. In addition, users, roles, and devices change over time. As a result, the security level of a Microsoft 365 environment may gradually deteriorate without anyone noticing.
Vahti helps SMEs understand Microsoft 365 sign-in and user-related risks in clear language. The service highlights, for example, incomplete sign-in protections, unusual sign-ins, high-risk users, and authentication methods that do not provide sufficient protection against modern phishing attacks.
Most importantly, the information does not remain a technical log. Vahti prioritises the findings and explains what should be fixed first.
In a situation such as device code phishing, it is essential to quickly answer practical questions:
For an SME, the value comes from not having to interpret Microsoft 365 risks solely through logs, portals, and technical settings. The risks are presented in clear language and in priority order for remediation.
Device code phishing is dangerous because it exploits a genuine sign-in process. The user may be on Microsoft's real website, complete MFA normally, and still end up approving the attacker's session.
An SME does not need to solve everything at once. However, these points should be checked quickly:
“We have MFA” is no longer enough as an answer. You need to know what kind of sign-in protection is in place and whether anomalies are detected in time.
Device code phishing is an attack in which a user is tricked into entering a sign-in code provided by the attacker on Microsoft's genuine sign-in page. When the user approves the sign-in, the attacker may gain access to an active session on the user's Microsoft 365 account.
Does the attack steal the password?Not necessarily. This type of attack does not always require the password to be stolen at all. The attacker's goal is to get the user to approve a session or device through the sign-in process.
Can the attack succeed even when MFA is enabled?Yes. MFA remains an important security measure, but device code phishing can trick the user into approving the sign-in on Microsoft's genuine website. That is why sign-in methods must also be restricted, Conditional Access policies must be used, and unusual sign-ins must be monitored.
Why does the user visit Microsoft's genuine website?The credibility of the attack is based precisely on this. The user may not provide their details to a fake sign-in page. Instead, they are directed to Microsoft's genuine device login page. The problem is that the user enters the attacker's code there.
Should device code flow be blocked completely?If the company does not need device code flow, blocking it is generally sensible. If it is needed, for example for meeting-room devices or specific technical use cases, its use should be carefully restricted to approved users, devices, or situations.
Where can I see whether device code flow is used in our environment?Check the sign-in logs view in Microsoft Entra ID. Sign-ins can be filtered based on the authentication protocol, allowing you to search for device code flow events. Before enabling a blocking policy, it is a good idea to determine whether there is a genuine business reason for the use.
Which users should be protected first?Start with administrators, management, finance staff, and users with extensive access to company data. Compromising these accounts often has the greatest impact because they may be able to approve payments, read confidential information, or send convincing messages to others.
What guidance should be given to users?Give users one clear rule: do not enter a sign-in code on Microsoft's website if you did not just initiate a sign-in on that device or in that application. If a message looks suspicious, it should be reported to the person responsible for IT or cybersecurity.
What should I do if a user has already entered the code?Revoke the user's sessions, revoke refresh tokens, change the password, check MFA methods, review the sign-in history, and check email rules and forwarding settings. If the account belongs to management, finance, or an administrator, the matter should be treated as an urgent security incident.
Is changing the password enough?Not always. Because the attack may rely on an active session rather than just the password, sessions and tokens must also be revoked. In addition, check whether persistent changes have been made to the account, such as new email rules, authentication methods, or application permissions.
What is the difference between MFA and phishing-resistant MFA?Ordinary MFA may be based on a text message, phone call, or approval notification. Phishing-resistant MFA means authentication that provides better protection against phishing because the sign-in cannot be transferred to the attacker's session as easily. Examples include FIDO2 security keys and passkey-based methods.
Does this only affect large organisations?No. Microsoft 365 account phishing also affects SMEs because email, invoicing, documents, and customer collaboration often take place through M365. For an attacker, compromising even one account may be enough to start a follow-up attack.
How is Vahti related to this?Vahti helps identify Microsoft 365 sign-in and user management risks in clear language. It helps show where protection is insufficient, where unusual activity is visible, and which fixes should be prioritised first.