What was announced and what the legal notice establishes
On September 22, 2026, Microsoft published a page titled “EvilTokens” in its court-document notices section. The material verified for this article confirms the title, the page’s location, and its publication date, but it is not sufficient to establish the parties’ details, the measures requested, or the procedural status. It would therefore be inappropriate to present specific allegations or a court ruling as established facts on the basis of that page. Keeping these limits explicit matters: a notice’s existence is not, by itself, a full account of the underlying matter.
CSO Online’s coverage places the case in the broader context of artificial-intelligence-related cybercrime. That journalistic framing does not, by itself, prove what role, if any, AI played in specific incidents. The sources available here do not provide an independent audit confirming its use, scope, or effect in campaigns attributed to EvilTokens. The same evidentiary caution applies to reported impact figures and the scope of any action against the platform. The verified documents provide no independent count of affected accounts and do not describe which technical resources were taken down. Microsoft’s page confirms a publication about EvilTokens in a legal notices section, but does not make it possible to reconstruct every detail. Distinguishing documented information from what could not be verified avoids turning an announcement or a media reference into a confirmed accounting.
The legitimate flow that can become a lure
Device-code authentication is a legitimate OAuth authorization flow, useful for equipment with limited interfaces, such as televisions, printers, or IoT devices. The device requests a code, and the person completes authentication in a browser on another device. Microsoft’s documentation explains that the client waits for a response from the authorization service while the user completes the process; the user code is valid for a limited time. In practical terms, the flow separates the device that needs authentication from the one the person uses to enter credentials and approve the request. The code links the two for a limited interval, and client polling lets the original device learn whether authorization has completed without needing its own sign-in interface.
This convenience is useful when a device lacks a suitable keyboard or browser, but it also makes it important for users to understand exactly which request they are approving. The documentation supports a description of the general mechanism, but the sources verified for this article are not enough to confirm that EvilTokens used it in a specific campaign or to reconstruct its technical steps. As a general risk of this type of flow, a person could be persuaded to enter a code and approve a request they did not initiate or do not recognize. A legitimate portal does not guarantee that the request being approved is legitimate. This explanation of the risk should not be confused with a verified description of EvilTokens’ tactics.
What can be said about AI
CSO Online’s headline links the EvilTokens disruption to the broader context of AI-powered cybercrime. However, the verified sources available here do not include an independent investigation confirming the use of AI capabilities in specific incidents. AI therefore cannot be presented as a proven explanation for the success of a campaign connected to EvilTokens. The distinction is between the framing of a news report and evidence about what happened in a particular incident; the former does not establish the latter.
The general risk of the flow can be understood without attributing it to any particular technology: a person may be induced to approve an authentication request they do not recognize. If that approval enables a valid session to be created, controls focused only on the password do not, by themselves, describe the entire risk. The authorization mechanism and the decision to approve the request both matter, but these general considerations do not prove how a particular service operated. AI warrants attention, yet it is not necessary to assign it a role in this case to explain the practical precaution. The available material cannot determine whether automation was involved, what tasks it might have performed, or how much it contributed. Likewise, without a verifiable source for the number of affected accounts, reproducing a count as corroborated would not be responsible. Coverage about the AI context should remain separate from conclusions that can actually be drawn from the documentation.
What a disruption does—and does not—mean
Microsoft’s page confirms a publication titled “EvilTokens,” but the information available in the verified sources does not establish the number or type of technical resources that may have been taken down. Nor does it support a claim that all related infrastructure has disappeared. The existence of a page in a court-document notices section is not enough to attribute a particular technical outcome to an operation. Even where a disruption has been announced, its practical and continuing effects require evidence beyond the announcement itself.
In general, disrupting a platform may make it harder to continue the activity attributed to it, but it does not demonstrate that every instance, operator, or copy has been identified or removed. It also does not prove that other actors cannot turn to different infrastructure or reproduce a similar technique. These are general limits on interpreting a takedown, not verified claims about the scope of a specific action against EvilTokens. Based on what could be verified, it is not appropriate to state that every related domain or service was removed, or to specify what measures were taken against each component. Disrupting an identified operation may reduce its reach; it does not, by itself, eliminate a phishing technique or prevent others from reproducing it. Separating a platform’s status from the possible continuation of similar methods helps avoid conclusions broader than the available evidence.
Defensive steps: assess before blocking
For organizations that do not need the device-code flow, Microsoft documents blocking it through a Conditional Access policy. Before applying such a policy, organizations should review whether they use the flow and which sign-ins might be affected. Microsoft’s authentication-flows documentation explains how to use that type of flow as a policy condition; it does not mean that every organization should apply an identical block. Reviewing dependencies first matters because an indiscriminate block could interrupt devices or processes that legitimately rely on the method. If exceptions are necessary, it is prudent to limit them to identified needs and revisit them when systems or their uses change.
The practical recommendation is to reduce unnecessary flows without assuming that device code has no legitimate uses, and to test a configuration before applying it broadly. This is operational guidance based on the documented control, not a claim that one policy suits every environment. For users, a useful warning sign is an unexpected request to copy a code or approve a sign-in. If you did not initiate authentication yourself and do not understand which device or application is requesting it, do not complete the process; verify the request through a known channel. A portal’s appearance alone cannot tell you who initiated the request associated with the code; context matters too. Security teams can use the case as a reason to review enabled flows and unusual sign-ins. The recommendation is not to abandon MFA, but to combine it with policies tailored to actual needs and careful attention to the context of each approval.