Headland: Blocking device-code phishing without breaking the old apps

The anchor

OAuth device-code phishing rose sharply through 2025, hitting hundreds of Microsoft 365 organisations (Storm-2372 among the actors) by tricking users into authorising attacker-controlled apps, no password or MFA prompt required. Microsoft's own guidance is a Conditional Access policy to block the flow. The engineering challenge is doing that without locking out legacy and headless apps.

Sources we build on

Primary

Microsoft Security Blog: defending against evolving identity attacks (May 2025)

Primary source describing the device-code technique and the Conditional Access mitigation.

Journalism

Help Net Security: device-code phishing campaigns

Independent reporting on the scale and targets of the 2025 campaigns.

Article outline

How device-code phishing bypasses MFA. The consent, not the credential, is the target.
The blocking policy. Conditional Access to disable the device-code flow where it is not needed.
The legacy-app problem. Where device code is legitimately used, and how not to break it.
Phishing-resistant methods. Why simple MFA is not enough anymore.
Rollout without lockouts. Report-only mode, exclusions, staged enforcement.

How it aligns to what we do

Security-led but framed around the real tension a practitioner faces: controls that users and old apps route around are worthless. It shows we sweat the rollout, which is where identity projects actually fail.

Points to hit

Name the technique and that it defeats classic MFA.
Give the CA policy, then spend real space on not breaking legacy apps.
Push phishing-resistant auth as the direction.
Show the safe rollout method (report-only, staged).

Control it ratifies

ISM / E8 E8 Multi-factor authentication, and its limits: adversary-in-the-middle and device-code flows defeat basic MFA, so Conditional Access and phishing-resistant methods are the real control.

← All deep dives Hardened Identity Management →