Incident Response
Device Code Phishing: Microsoft 365 Response Checklist
Respond to Microsoft 365 device code phishing: investigate sign-ins, revoke sessions, check mailbox persistence, and restrict risky authentication flows.
Updated 2026-10-15 · 3 min read
Investigation
Trace the authentication
Connect the reported code entry with sign-in records and subsequent account activity.
Containment
Revoke access and inspect persistence
Track session revocation, unauthorized authentication methods, and mailbox changes.
Prevention
Restrict device code flow
Validate legitimate dependencies and assign an owner to each approved exception.
Useful CyberPrism references
Microsoft: EvilTokens device code phishing
September 22, 2026 research explaining token theft and follow-on mailbox abuse.
Microsoft Entra authentication flow controls
Guidance for identifying and restricting device code authentication.
CyberPrism RIPD Framework
Connect threat findings with defensive priorities.
Threat Actor Profiles
Review actor context while keeping attribution separate from incident evidence.
How should you respond to device code phishing?
If a user entered an unsolicited device code, investigate the resulting sign-in immediately. For a compromised account, disable access, revoke sessions, and inspect authentication methods and mailbox persistence before restoring access. [Microsoft account recovery guidance](https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account).
Device code phishing tricks a user into authorizing an attacker-initiated session through a legitimate sign-in page. Microsoft's September 22, 2026 EvilTokens report documents this technique and subsequent mailbox abuse, making it a relevant review priority as of October 15, 2026. [Microsoft research](https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/).
Preserve the lure and trace the sign-in
Record the recipient, original message, message identifier, destination links, and approximate code-entry time. Ask whether the user completed authentication and what action the message claimed to require.
In Entra sign-in logs, filter Authentication protocol for device code flow. Inspect Original transfer method when reviewing later activity: a session can retain its device-code origin across token refreshes. [Microsoft log guidance](https://learn.microsoft.com/entra/identity/conditional-access/concept-authentication-flows).
Correlate the user, application, resource, timestamps, and source addresses. Keep message delivery, completed authentication, and confirmed unauthorized activity as separate findings.
Contain access and remove persistence
For confirmed compromise, follow Microsoft's recovery sequence: disable the account, revoke sign-in sessions, and review registered authentication methods, application consent, and assigned roles. Inspect mailbox forwarding and inbox rules, including hidden rules, for unauthorized changes. [Microsoft recovery checklist](https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account).
Preserve suspicious settings before removal and record each containment action with its completion time. Verify the result through subsequent activity; a submitted revocation request alone should not close the incident.
Restrict device code flow without breaking approved use
Microsoft recommends blocking device code flow wherever possible. Inventory existing use and evaluate a Conditional Access policy in report-only mode before enforcement. [Authentication flow controls](https://learn.microsoft.com/entra/identity/conditional-access/concept-authentication-flows).
Check dependencies such as Teams devices and command-line tools. For Teams devices, follow Microsoft's guidance on resource-account exceptions, Device Registration Service exclusions, and reauthentication testing; avoid broad user exclusions. [Teams device policy guidance](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-teams-devices-device-code-flow).
Give each exception a business purpose, accountable owner, and review date. Teach users to reject device codes supplied through unexpected messages, even when the destination is a genuine Microsoft page.
Close with evidence of scope and recovery
Review audit records and sent messages across the suspected compromise period to assess account use. Record unauthorized forwarding, suspicious messages, and affected services. [Microsoft investigation guidance](https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account).
Give leadership a short decision record: affected accounts, confirmed activity, containment status, remaining evidence gaps, and the owner of each follow-up. Treat missing logs as an unresolved limitation rather than proof that no data was accessed.
FAQ
Can device code phishing work without stealing a password?
Yes. The user can authenticate on a legitimate Microsoft page while approving a session initiated by an attacker. A genuine sign-in domain does not establish that the request is legitimate. [Microsoft explanation](https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/).
Does device code authentication prove an account was compromised?
No. Device code flow has legitimate uses. Correlate the sign-in with the reported lure, the user's intended activity, and subsequent account behavior before classifying the event as compromise.
Try CyberPrism
Track CVEs, threat actors, breaches, ransomware activity, and vendor exposure from a mobile-first cybersecurity app.