What Is Device Code Phishing?

Ever since Microsoft’s initial announcement on February 13, 2025, about a Russian nation-state phishing campaign using "device code phishing," many people have been wondering what it is.

This post will tell you what device code phishing is and how to defend against it.

Here are some other related reports involving the recently reported device code phishing attacks:

What Is a Device Code?
I almost hate the term – device code. It’s not very distinctive. All authentication codes are sent to devices. The difference here is that what is being authenticated is the device, so that all future connections from the same device are treated as belonging to a particular user. When you are using the same device, it must be you, or so the logic goes. Indirect user authentication.

Imagine you are trying to log into something on one device and in response, that system sends you a short code (usually six alphanumeric characters) to a second previously registered and authenticated device, your phone or portable device, to type into another login prompt on the first device, and once you do, you are authenticated and logged in. It sounds like something we do all the time when trying to log into somewhere.

Many of us do this as part of some “one-time password” (OTP) multi-factor authentication login, but device code authentication is slightly different. First, this login is tied to your devices. Most OTPs, although they could be “bound” to your device, are directly authenticating the user. It is user authentication-focused.

Note: Many advanced user authentication solutions involve looking at, identifying, and authenticating a device that you are using. When you logon using what the authentication service thinks is the same device the authentication solution assigns more trust to your logon.

Device codes focus on authenticating your device ID, and indirectly you, because of your particular device. With device code authentication, once you have entered in the code (on your second device), the first device involved becomes bound to the service requesting the authentication and you will not be asked to re-authenticate on the first device or you as a user again (at least for some set period of time).

Many of us are familiar with device codes, even if we do not know them by that name. If you have ever tried to answer a newly presented login prompt to an existing subscribed to streaming channel (e.g., Netflix, Max, Apple TV, etc.) on your TV, instead of having to type all your logon information in on the TV…one painful arrow…arrow…select keystroke at a time…the service likely sent you a code that you had to type in, instead, that then automatically logged you into your stream service and never bothered you again on that same device (i.e., TV). See example below. If you have done that, you have experienced a form of device code authentication.

Attack Method
To prepare for this attack, the threat actor starts to log into a legitimate service you already belong to (e.g., Microsoft, Netflix, third-party app, etc.) using your account’s user ID and gets a legitimate device code (meant for you) sent to them instead. They then send a phishing message to you that includes the legitimate device code and ask that you type it into the legitimate login service. They provide the link. If you do, this tricks the login service into believing that the other device under the control of the hacker is yours.

Here is the attack summary from Microsoft.

Microsoft Attacks
In the cases that Microsoft is directly involved in, the device codes are used to authenticate in corporate scenarios. Same sort of thing, like what happens on your TV, but it is used to authenticate someone during a work scenario to a work application or service. Microsoft’s major online directory service, Entra (formerly called Azure Active Directory), is used by tens of millions of Microsoft O365 users to access their accounts and related applications. It will use device codes by default for user authentication.

In the threat scenario that Microsoft is describing, potential victims are invited to join a (fake) Microsoft Teams meeting thread sent in a phishing email or chat message. When the victim clicks on the provided legitimate Microsoft login link (the URL is legit and belongs to Microsoft), they are asked to provide the device code to authenticate. When the user types in the code, the service unknowingly authenticates the first device (i.e., the hacker’s device) as being legit. So, now the hacker’s device is authenticated as one of your devices and will not be asked to re-authenticate for some set period of time. The attacker can pretend to be you on the services involved and have whatever access you legitimately possess.

Here is a great video demonstrating device code logins.

Overall Problem
The underlying problem is that using OTP codes as authentication is a really bad idea. They are just too easy to steal and socially engineer, just like a password. It is as easy to socially engineer a user out of an OTP as it is a password. With traditional OTP MFA phishing, the user is tricked into visiting the hacker’s fake web page (or man-in-the-middle site) and typing in their MFA’s OTP code, which the hacker then steals and reuses on the real site. On the plus side of that type of attack, all the user has to do is recognize that the link they are being sent is not to the real, legitimate website they normally log into. There is a good chance that the user will notice that something is wrong and will not be tricked.

Device code phishing is somewhat the reverse. Here, the real login page hands someone else’s real OTP code to the attacker first, which the hacker then tricks the legitimate user into typing from their second previously authenticated device. With device code phishing, the real login page has no way of knowing that the hacker's earlier request, to which they send the device code, is fraudulent. In both cases, OTP codes are being used and eventually mishandled by the user through no fault of their own.

Device code phishing is worse than traditional MFA OTP phishing because the link involved that the legitimate user is seeing and using is real and legit. It belongs to the real website (e.g., microsoft.com) that they would normally log into. The whole traditional security awareness training lesson of looking at URLs and verifying the legitimacy of the domain before clicking does not really help. The link the user is using is legit. The site is legit. The user has no way of easily knowing that by typing in their OTP code into the real site, they are allowing a second, unauthorized party to become part of their account, forevermore. It is really devious.

The fact that OTP codes are poor authenticators is not unknown within the cybersecurity industry. For one example, the U.S. government has been saying at least since 2016, in NIST Special Publication 800-63, the Digital Identity Guidelines, not to use authentication methods that involve sending OTP codes, because they are too easy to manipulate.

Device codes were invented as a convenience, to prevent people from having to type in a lot of information on devices (like TVs or phones) where typing a lot of login information is not really easy. Well, this convenience is allowing nation-state hackers into people’s accounts for long terms of service.

Defenses
Part of the problem is that there are not a lot of good defenses besides education or disabling device codes to prevent device code phishing.

Education wise, you need to teach users about the threat and how it is conducted. Unfortunately, it is a little more involved than most anti-phishing education. In the case of device code phishing, the user needs to be taught to be aware of unexpected requests for them to input a provided device code that they did not initiate.

In most legitimate instances of device codes, the user starts the process that leads to the device code use. For example, I am trying to log into my Netflix account on a hotel TV. It should not surprise me that the TV is giving me or asking me for a device code. I was not given a device code to input out of the blue and asked to start a new transaction. I started something that I wanted to do, which led to me being given a device code.

In the case of device code phishing, the user is not doing anything that should be expected to create a device code transaction. The request to use a login that generates the device code arrives unexpectedly and includes the device code they are expected to use. The fact that it is arriving before the user has done anything to start the process is the main tell that this is a device code scam. It is a subtle, but important difference.

Use Conditional Access
If you are a Microsoft Entra admin, you can disable “device code flow” in your conditional access policies. Keep in mind this disables all users of device codes for Entra and not just malicious uses. This means your user will have to log in, providing more information than just a device code, but it will better protect your environment from this type of phishing attack. Watch this video to learn how to configure conditional access to disable device codes.

Note: Disabling device codes is different in different applications, and it is not always possible.

Use IP Address Blocking or Geo-Fencing
Some defenders block unauthorized device code use by only allowing certain ranges if IP addresses are involved or by using geo-fencing (i.e., allowing and denying based on physical location of the device), which may or may not be an option in the application you are looking at.

Device codes are a part of life. If you do not have a healthy level of skepticism and know about scams that can involve them, you are more likely to fall for one.