Topic starter
25/10/2026 11:06 am
TL;DR: Device code phishing makes a legitimate MFA completion a weak signal because attackers can inherit Microsoft 365 access tokens, according to Coalition. Token revocation and tighter device-flow governance have to matter as much as login success.
Editorial analysis by NHI Mgmt Group, based on content published by Coalition: “A New Era Of Social Engineering: The Device Code Phishing Boom”.
By the numbers:
- Coalition Incident Response handled multiple business email compromise cases in June and July 2026 that stemmed from device code phishing.
Key questions
Q: Why do phishing attacks still succeed even when spam filters and MFA are in place?
A: Phishing succeeds because it targets human judgment and can bypass technical controls through deception, urgency, and credential theft.
Q: How can security teams tell whether a device code login was malicious?
A: Look for deviceCode authentication, mismatched user agents, unusual IP addresses, repeated code requests, and device registrations that do not fit normal business behaviour.
Q: What breaks when device code flow is allowed without tight governance?
A: The control that breaks is the assumption that the person completing MFA is the same person benefiting from the resulting session.
Practitioner guidance
- Restrict device code flow where it is not required Block the device flow entirely for environments that do not need it, and create explicit exceptions only for defined use cases and users.
- Review sign-in telemetry for device code anomalies Monitor interactive sign-in logs for deviceCode authentication, user-agent mismatches, unusual IPs, and repeated device registration attempts under the same account.
- Preserve audit data beyond default retention windows Ensure Unified Audit Logs and Entra sign-in logs are retained long enough to support investigations when incidents are discovered days or weeks later.
Bottom line: Device code phishing turns a legitimate MFA completion into attacker-held access, so the compromise can hide inside a normal sign-in flow.
Glossary terms: Device code phishing, Access Token, Refresh Token, Unified Audit Log
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
Device code phishing exposes an MFA completion blind spot: the authentication step can succeed while the attacker still receives the usable token. That means the control failure is not merely weak user behaviour but a governance model that treats successful sign-in as proof of safety. Practitioners should read this as a session integrity problem, not a password problem.
A few things that frame the scale:
- The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.
A question worth separating out:
Q: When should organisations block device code flow entirely?
A: Organisations should block it wherever the business does not depend on it, especially for users who do not need CLI sign-in. If the flow is still essential for specific teams, use report-only testing first, then enforce with narrow exceptions so you do not break legitimate developer access.
👉 Read our full editorial: Device code phishing makes MFA success a weak signal
This post was modified 7 days ago by NHI Mgmt Group