A genuine sign-in page can still authorise an attacker

The address bar is not the whole story

Device-code phishing does not require a counterfeit password-entry page. An attacker initiates a device authorisation flow and persuades a person to enter the supplied code on a genuine sign-in page. The victim can then authorise a session the attacker controls, giving the attacker access and refresh tokens. [1]

The practical lesson is to check the request and the session being authorised, not only whether a website belongs to Microsoft. An unsolicited invitation to enter a code deserves scrutiny even when the destination is legitimate.

What Microsoft reported

Microsoft published its Storm-2372 investigation on 13 February 2025 and described email collection and further phishing from compromised accounts. A 14 February update described Authentication Broker client-ID use, device registration and Primary Refresh Token activity in the observed campaign. On 31 July 2026, Microsoft updated its assessment to identify Storm-2372 as an initial-access operations sub-cluster of Midnight Blizzard. That attribution is Microsoft’s assessment, not an independent finding by Vula Connect. [1]

These are dated observations, not a claim that every suspicious device-code event belongs to this actor or that a new incident is unfolding in your tenant.

Restrict the flow without breaking legitimate work

Microsoft documents a Conditional Access policy for blocking device-code flow. Its guidance recommends understanding existing use and keeping necessary use cases documented and secured. Begin with report-only evaluation and review the effect before enforcement. [2]

Do not deploy an organisation-wide block on the strength of an article alone. Check tenant capabilities, licensing, business dependencies and emergency-access arrangements with the responsible administrator. The cited documentation describes a configuration procedure; it does not establish a new October 2026 product launch.

Connect prevention to investigation

1. Inventory the dependency. Identify applications and workflows that legitimately use device-code authentication and name an owner for each exception.
2. Pilot the restriction. Review report-only results and approved exclusions before enabling enforcement.
3. Correlate evidence. Investigate suspicious sign-ins alongside unexpected device registrations and relevant mailbox activity. Confirm that the required telemetry exists in your environment.
4. Train for the authorisation trap. Ask users to reject unsolicited code-entry instructions and verify unexpected requests through an established channel.
5. Prepare containment. Include session revocation, device investigation, mailbox review and evidence preservation in the response checklist.

A password reset is not a complete response

Microsoft recommends revoking refresh tokens when this activity is suspected. Its documented revokeSignInSessions API invalidates refresh tokens and browser session cookies, but the effect can take a few minutes. It does not revoke an external user’s sessions in that user’s home tenant. Do not assume it instantly terminates every access token or application session. [1] [3]

For planned improvements, explore Managed Detection & Response or separately scoped incident investigation services. For an active incident, use your organisation’s established escalation channels; this article is not an emergency reporting service.

Explore more insights →