Notifications
Clear all
Topic starter
19/08/2026 3:34 pm
TL;DR: Device code phishing abuses a legitimate Microsoft authentication flow to bypass passwords and MFA, then leaves attackers with persistent account access unless sessions are revoked, according to Expel. The incident shows that tighter configuration, not just stronger credentials, is now the decisive control for Microsoft authentication governance.
NHIMG editorial — based on content published by Expel: device code phishing and persistent account access through Microsoft authentication
Questions worth separating out
Q: How should security teams reduce device code phishing risk in Microsoft 365 environments?
A: Security teams should limit device-code authentication to approved use cases, pair it with compliant-device requirements, and add sign-in detections for unusual polling, consent, and post-login mailbox activity.
Q: Why do device code phishing attacks bypass many standard phishing controls?
A: They use the real Microsoft login page, so there is no fake domain, no malicious payload, and no obvious infrastructure to block.
Q: What breaks when organisations rely on password resets after a phishing compromise?
A: A password reset changes the credential, but it does not necessarily terminate live sessions or invalidate refresh tokens already issued to the attacker.
Practitioner guidance
- Disable device code authentication by default Remove device code flow wherever it is not strictly required, and document the few business processes that genuinely need it.
- Approve only narrow device-code exceptions Limit device code use to specific approved devices and named scenarios, then review those exceptions on a fixed schedule.
- Revoke sessions after compromise events When an account is suspected or confirmed compromised, invalidate active sessions and refresh tokens immediately after the password reset.
What's in the full article
Expel's full analysis covers the operational detail this post intentionally leaves for the source:
- Examples of how device code phishing is executed against Microsoft authentication flows
- SOC observations from a recent token replay campaign and the response actions that mattered most
- Microsoft conditional access guidance for blocking or tightly scoping device code authentication
- Practical exception handling patterns for environments that cannot disable device code flow entirely
👉 Read Expel's analysis of device code phishing and persistent Microsoft account access →
Device code phishing: are your Microsoft auth controls keeping up?
Explore further
19/08/2026 4:16 pm
Device code phishing is really a session-governance failure, not a password problem. The attacker succeeds because a legitimate authentication flow can be socially engineered into issuing a valid session token. That shifts the control question from password strength to whether the organisation can contain and revoke authenticated access once the flow is abused. For IAM teams, the practical conclusion is that authentication pathways need threat modelling, not just usability review.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when device code authentication is left broadly enabled?
A: IAM and security owners are accountable for the policy decision, while incident response teams are accountable for session containment once abuse is detected. Frameworks such as NIST CSF and NIST SP 800-63 both support this split between access governance and operational response.
👉 Read our full editorial: Device code phishing exposes the limits of password and MFA defenses
