Device Code Phishing: A Real Microsoft Login Can Be a Trap
A real Microsoft login address does not make an unsolicited device-code request safe. If someone else started the sign-in and supplied the code, completing it can authorize their session rather than a device you intended to connect.
By SafeOrScamCheck · Published · Sources checked
This guide is free to read. Checker use follows the existing paid-check options; official-source links below are free.
Warning signs to check
A code you did not request
The code arrives in a message rather than from a sign-in you initiated.
A document used as bait
The sender says authorization is needed to reveal an invoice or shared file.
A real domain masks the context
The address is genuine, but the device or session being authorized is not yours.
Why this guide is relevant
Microsoft's September 22, 2026 EvilTokens analysis describes more than 12,000 compromised inboxes across over 10,000 organizations worldwide since the platform emerged in February. The FBI's May 21 Kali365 alert independently explains abuse of the legitimate device-code flow.
See the official sources and their dates.
Illustrative example: a document-sharing email tells you to enter a supplied code on a real Microsoft verification page to read a file you were not expecting.
Verify before you act
Already clicked, paid or shared information?
If you entered the code, promptly ask your provider or IT team to revoke unauthorized sessions and tokens and review devices, permissions and mailbox rules. A password change alone may not remove every established access path.
Read the scam recovery checklist and official reporting options.
What a checker cannot establish
A URL checker may correctly recognize Microsoft's genuine domain and still miss this attack. The origin of the code and the authorization context are essential.
Primary official sources
Microsoft Security: EvilTokens device-code phishing
Source date:
FBI IC3: Kali365 access-token phishing
Source date:
The guide's publication date is separate from each source's date. Source organizations do not endorse or sponsor SafeOrScamCheck.
Frequently asked questions
Is device-code phishing identical to OAuth consent phishing?
No. Device-code abuse authorizes an attacker-initiated session; application-consent phishing instead tricks users into granting an app permissions. Both can involve tokens.
Does MFA guarantee this request is safe?
No. The problem can be a valid authorization granted to the wrong session, not a failure to check your password.
Should I assume every device code is malicious?
No. Legitimate devices use this flow. The key question is whether you initiated and recognize the request.
Related guides
Warning signals are not proof of fraud, and an absence of signals is not a guarantee of safety. Verify identities, payment instructions and important claims independently. Never submit passwords, authentication codes, card numbers or sensitive identity information to a checker.