Device-code phishing
What is device-code phishing, and how do you stop it?
Device-code phishing is an attack in which someone talks you into entering a short sign-in code on Microsoft's or Google's real sign-in page. The attacker's computer requested that code, so when you sign in with your real password and MFA, that computer gets access to your email and files, usually for weeks or months. The protection that works today is to turn device-code sign-in off wherever it isn't needed.
Nothing in the attack is fake. Only the story is.
Key facts
- Device-code phishing abuses the OAuth 2.0 Device Authorization Grant, published as RFC 8628 in 2019. It is the sign-in flow TVs and command-line tools use, and Microsoft, Google, AWS, GitHub and Okta implement it.
- RFC 8628 names the attack itself, under "Remote Phishing": "It is possible for the device flow to be initiated on a device in an attacker's possession" (RFC 8628, 5.4).
- RFC 10027 (BCP 247, August 2026) calls the attack Cross-Device Consent Phishing and says "Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated."
- "Monthly device code phishing attempts jumped 15x in the past six months," according to the CrowdStrike 2026 Threat Hunting Report, August 2026 (CrowdStrike).
- The EvilTokens phishing kit launched on 16 February 2026 and reached 340 or more Microsoft 365 organizations in the United States, Canada, Australia, New Zealand and Germany by mid-March (Cloud Security Alliance).
- Microsoft calls device code flow "a high-risk authentication method" and recommends "blocking device code flow wherever possible" (Microsoft).
What is device-code phishing?
Device-code phishing turns an ordinary TV-style sign-in against you: the attacker starts the sign-in on their computer, and you finish it on the real sign-in page.
The ordinary version looks like this. You get a streaming app on a new TV. The TV shows a short code and says: go to this website on your phone and enter it. You do, and you prove you have the subscription by signing in with your usual account (the streaming service's, or Apple, Microsoft or Google). The channel starts playing. You never typed a password on the TV.
Device-code sign-in exists so that a device without a proper keyboard, such as a TV, a meeting-room screen or a command-line tool on a server, can use an account through a person who signs in on another device. The only link between the two devices is that person reading a code from one screen and typing it on the other. Device-code phishing exploits exactly that link.
How does a device-code phishing attack work?
In device-code phishing, the attacker's computer plays the part of the TV, and you play your normal part.
- The attacker starts device-code sign-in on their own computer, as if it were a TV, and asks Microsoft or Google for a code. They don't have to say whose account it is. Whoever enters the code fills that in.
- The attacker talks you into entering the code, with a believable reason: to open a shared document, to join a meeting, because IT needs you to re-verify, or to subscribe to a TV streaming service.
- You go to the real sign-in page, sign in with your real password and MFA, and enter the code.
- The page says "You're signed in, you can close this window." Nothing seems to have happened.
- Something did. The attacker's computer can now use your account, as you: it can read your email and open your files.
Entering a device code while you sign in, with your MFA, lets the app that showed the code use your account. On a TV, that app is the streaming app. In device-code phishing, it is the attacker's computer, usually presenting itself as an ordinary Microsoft app so the request looks routine. The access usually lasts weeks or months, because a credential for renewing it comes with it.
Why doesn't MFA or a passkey stop device-code phishing?
Because nothing in device-code phishing is fake. The page, the sign-in and the code are all real; only the story is false.
Phishing-resistant MFA, passkeys included, protects people from signing in to a fake site. In device-code phishing the person really is on the real Microsoft or Google site, so a passkey works exactly as designed and the attacker still gets in.
The identity provider issuing the access can't tell whether the person entering the code is letting in a TV or an attacker. It does ask the person to confirm, with a line like "Are you trying to sign in to Microsoft Office?" A person has no way to know the right answer, because the attacker's computer presents itself as an ordinary Microsoft app.
Despite its name, a device code is not tied to any device. It is a random code, and whichever computer requested it receives the access. The legitimate flow and the attack are the same flow: a person approves, from one device, access for another device, and the only check is that person.
Changing the password doesn't remove a device-code phisher either. The access was granted to the attacker's computer and doesn't depend on the password.
What stops device-code phishing, and what doesn't?
Blocking device-code sign-in stops device-code phishing today. MFA, passkeys and password changes don't, because the attack never touches a fake site or the password.
| Control | Stops device-code phishing? | Why |
|---|---|---|
| Phishing-resistant MFA and passkeys | No | The person signs in on the real Microsoft or Google site, so the passkey works as designed and the attacker's computer still gets the access. |
| Checking the confirmation prompt | No | The attacker's computer presents itself as an ordinary Microsoft app. A person has no way to know the right answer to "Are you trying to sign in to Microsoft Office?" |
| Changing the password | No | The access was granted to the attacker's computer and doesn't depend on the password. |
| Short code lifetimes | Partly | Short lifetimes limit codes sent by email or text, but RFC 8628 notes they don't stop "a phisher from presenting a fresh token, particularly if they are interacting with the user in real time" (RFC 8628). |
| Telling people one rule | Helps | "Never enter a sign-in code that someone sent you" removes the easiest stories, but it still relies on the person noticing. |
| Blocking device-code sign-in | Yes | With the flow turned off, there is no code to send. Keep named exceptions only for the devices and accounts that need it (Microsoft). |
| Revoking sessions and sign-in tokens | After the fact | Removes access that has already been granted. Use it when someone has entered a code. |
| Device-bound keys for registered devices | Yes, with limits | The identity provider accepts only devices that prove they hold a registered key, and the attacker's computer has none. Devices that can't be registered, and the registration step itself, remain open. |
Is device-code phishing a flaw in the OAuth standard?
Yes, in its design, and the standard documents it itself. Nothing is implemented wrongly: Microsoft, Google and others do exactly what the standard says. The weakness is in what it says. The flow relies on the person to confirm that the device asking for access is the one in front of them, and the person has no way to check that. Neither does the identity provider.
The flow is the OAuth 2.0 Device Authorization Grant, RFC 8628 (2019). RFC 8628 describes the attack in its section on "Remote Phishing": "an attacker might send an email instructing the target user to visit the verification URL and enter the user code." Its mitigation is to "inform the user that they are authorizing a device" and "confirm that the device is in their possession" (RFC 8628, 5.4). That means relying on the person to notice.
RFC 10027, "Best Current Practice for Security of Cross-Device Flows" (BCP 247, August 2026), calls it Cross-Device Consent Phishing. It says these attacks "exploit the unauthenticated channel between the Consumption Device and Authorization Device using social engineering techniques." It notes that the server "typically cannot directly determine whether the Consumption Device and Authorization Device are physically close to each other," and that "End users are poorly equipped to authenticate the channel between the two devices."
"Implementers SHOULD avoid cross-device flows if risks cannot be sufficiently mitigated." (RFC 10027)
RFC 10027 applies to other cross-device flows as well, such as sign-in by QR code or by push approval on a phone, not only device-code sign-in.
How common is device-code phishing?
Device-code phishing grew fast in 2026, helped by ready-made phishing kits.
CrowdStrike's 2026 Threat Hunting Report, published in August 2026, says: "Monthly device code phishing attempts jumped 15x in the past six months" (CrowdStrike).
The Cloud Security Alliance documented one kit, EvilTokens, sold as a service on Telegram from 16 February 2026. By mid-March, the campaign tied to its infrastructure had reached 340 or more Microsoft 365 organizations across the United States, Canada, Australia, New Zealand and Germany (Cloud Security Alliance).
How do you stop device-code phishing?
Turn device-code sign-in off, and allow it only where something really needs it.
Most organizations don't need device-code sign-in at all. Where they do, it is a short list: meeting-room devices, some printers and screens, and administrators running command-line tools on servers.
In Microsoft Entra ID
- Create a Conditional Access policy for all users that blocks the device code flow under Conditions, Authentication flows (Microsoft).
- Exclude only the accounts or devices that need device-code sign-in.
- Run the policy in report-only mode for a week or two first. Filter Entra's sign-in logs by the Device code authentication protocol to see who actually uses it, so you know what would break before you switch the policy on (Microsoft).
- Switch the policy on.
In Okta, Google Workspace and other identity providers
Look for the equivalent control. Usually it is a setting that limits which apps may use device-code sign-in, or a per-app option to turn it off. In Okta, device authorization is a grant type enabled per app integration (Okta). Check with your vendor.
If you run MagicEndpoint behind Entra ID or Okta, block device-code sign-in in Entra ID or Okta as well, so the flow can't be started there.
For the exceptions you keep
Limit device-code sign-in exceptions to named accounts and known locations, and review the list from time to time.
What should you do if someone already entered a device code?
Revoke the person's sessions and sign-in tokens. Changing the password isn't enough, because the attacker's access doesn't depend on it.
- Revoke the person's sessions and sign-in tokens (Microsoft).
- Check the account for new mail rules, such as forwarding to an outside address.
- Check for new devices registered to the account.
- Check which apps the account has granted access to, and remove any it shouldn't have.
Where does a lasting fix for device-code phishing have to come from?
From tying the approval to the right device, not from asking people to notice.
Today nothing ties the code a person enters to the device in front of them. The only link between the two devices is a person reading a code from one screen and typing it on another, and nothing cryptographic checks that link.
What works is registering the devices first. Every device allowed to ask for access is registered and managed, and holds its own key. The identity provider accepts a request only from a device that proves it holds a registered key, and the attacker's computer has none. Two gaps remain: devices that can't be registered, such as a hotel TV, and the registration step itself, which becomes the next target.
The flow itself could also be designed to tie the code to the device in front of the person, for example by having the phone show the code and the person type it into the TV. None of this is in the standard today.
Until then, turning device-code sign-in off is the fix.
Check the sign-in methods your accounts still allow
An account is only as strong as the weakest sign-in method still enabled for it. Device-code sign-in is on by default and almost nobody uses it, which is exactly the kind of method attackers look for. WinMagic has worked on endpoint security since 1997. Talk to us about reviewing which sign-in methods your accounts still allow, and about phishing-resistant authentication.
Frequently asked questions
What is device-code phishing?
Device-code phishing is an attack in which an attacker requests a sign-in code from Microsoft or Google on their own computer, then persuades someone to enter that code on the real sign-in page. When the person signs in with their password and MFA, the attacker's computer receives access to their account, usually their email and files.
Does MFA stop device-code phishing?
No. In device-code phishing the person signs in on the real Microsoft or Google page with their real password and MFA. Phishing-resistant MFA and passkeys protect against fake sites, and here the site is real, so they work as designed and the attacker still gets in.
What stops device-code phishing?
Blocking device-code sign-in stops device-code phishing, with named exceptions only for the devices and accounts that need it. Phishing-resistant MFA, passkeys and password changes don't stop it. Short code lifetimes and user training help but rely on the person. Device-bound keys for registered devices would stop it, except for devices that can't be registered.
Does changing the password remove an attacker who got in through device-code phishing?
No. The attacker's access was granted to their computer and does not depend on the password. Revoke the person's sessions and sign-in tokens, then check the account for new mail rules, new registered devices and apps it has granted access to.
How do I block device-code sign-in in Microsoft Entra ID?
Create a Conditional Access policy for all users that blocks the device code flow under Conditions, Authentication flows, and exclude only the accounts or devices that need it. Run it in report-only mode for one to two weeks first, and filter the sign-in logs by the Device code authentication protocol to see who uses it.
Who actually needs device-code sign-in?
Most organizations don't need device-code sign-in at all. Where they do, it is a short list: meeting-room devices, some printers and screens, and administrators running command-line tools on servers. Keep those as named exceptions and turn the flow off for everyone else.
What should employees be told about device-code phishing?
One rule: never enter a sign-in code that someone sent you. A sign-in code is only ever entered for a device that is in front of you and that you started yourself.
Is a device code tied to the device that shows it?
No. Despite the name, a device code is a random code that is not tied to any device. Whichever computer requested the code receives the access once a person signs in and enters it, which is why an attacker's computer can stand in for a TV.
What is Cross-Device Consent Phishing?
Cross-Device Consent Phishing is the name RFC 10027 (BCP 247, August 2026) gives to attacks that use social engineering to get a person to approve, on one device, a sign-in started on a device the attacker controls. Device-code phishing is the best-known example; the same risk applies to other cross-device flows, such as sign-in by QR code.
How common is device-code phishing?
CrowdStrike's 2026 Threat Hunting Report says monthly device-code phishing attempts jumped 15 times in six months. The Cloud Security Alliance documented one phishing kit, EvilTokens, reaching more than 340 Microsoft 365 organizations within about a month of its launch in February 2026.
Sources
- IETF, RFC 8628: OAuth 2.0 Device Authorization Grant, August 2019, section 5.4 "Remote Phishing".
- IETF, RFC 10027 (BCP 247): Best Current Practice for Security of Cross-Device Flows, August 2026.
- CrowdStrike, 2026 Threat Hunting Report, 3 August 2026.
- Cloud Security Alliance, OAuth Device Code Phishing Hits 340+ Microsoft 365 Organizations, research note, 25 March 2026.
- Microsoft Learn: Conditional Access: Authentication flows, 24 March 2026; Block authentication flows with Conditional Access policy; Revoke user access in Microsoft Entra ID.
- Okta Developer: Configure Device Authorization Grant Flow.
- WinMagic: Phishing-resistant MFA; MagicEndpoint; Certifications.
Checked 6 October 2026. Vendor pages change; check the linked page before acting on it.