Skip to content

All posts

IT security, Identity, Entra ID

Device Code, the second login in Entra ID

A short code, the real Microsoft sign-in page, confirmed MFA. In the end the mailbox sits with the attacker.

An employee gets a mail with an invoice subject line. Inside sit a short code and the link microsoft.com/devicelogin. She enters the code, confirms MFA, and the sign-in succeeds. The next morning she finds forwarding rules in her mailbox that she never created.

MFA worked. Beside the usual login, Entra ID offers a second sign-in path: the Device Code Flow. It is built for devices without a keyboard — Teams rooms, digital signage, or shared devices: the sign-in starts on one device and is confirmed on another. Attackers start the flow themselves and send the victim only the code. The victim signs in on the real Microsoft page, and the tokens land on the device that started the flow.

What happens technically

The Device Code Flow is the OAuth 2.0 Device Authorization Grant from RFC 8628. The sequence has three steps:

  1. The attacker sends a POST to /oauth2/v2.0/devicecode with a client_id and a scope. Back come a device_code, which they keep, and a user_code, which goes into the phishing lure.
  2. The victim enters the user_code on microsoft.com/devicelogin and completes the full sign-in, including MFA.
  3. Meanwhile the attacker polls /oauth2/v2.0/token with the device_code. Once the victim has confirmed, they receive an Access Token and a Refresh Token.

Three details make the attack practical:

  • No separate app registration needed. Attackers use the client IDs of first-party public clients such as Microsoft Office or Azure CLI. In the consent prompt the victim therefore sees a Microsoft app, not an unknown tool, and a consent dialog that might raise suspicion often never appears.
  • The code expires after about 15 minutes. That is why PhaaS kits generate the code only when the victim opens the phishing page. A code that sits statically in the mail would usually already have expired.
  • The Refresh Token is the real prize. With it the attacker can keep minting new Access Tokens even after a password change, until someone revokes the sessions. With a suitable client ID it can also be redeemed for further resources such as Graph, Exchange, or SharePoint.

Why MFA does not help here

On 22 September 2026, Microsoft Threat Intelligence published an analysis of EvilTokens, a phishing-as-a-service platform built for exactly this attack. Microsoft counts more than 12,000 compromised mailboxes across more than 10,000 organizations. EvilTokens is a commercial panel with token management, so anyone with a budget can run the attack.

MFA establishes that the right person is signing in. It does not check who receives the session afterward. From Entra ID’s point of view this was a clean sign-in with a strong second factor, and that is how it appears in the log.

What Conditional Access controls on the flow

In Conditional Access, under Authentication Flows, there is a dedicated condition for the Device Code Flow. Here is how to proceed:

  1. Check the Sign-in logs for who uses the flow today. In Log Analytics or Sentinel a short query is enough:

    SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == "deviceCode"
| summarize Anmeldungen = count(), Apps = make_set(AppDisplayName), IPs = make_set(IPAddress)
    by UserPrincipalName
| order by Anmeldungen desc

    A hit from a Teams room is expected. A regular employee with Azure CLI as the app and an IP that does not belong to the company deserves a closer look.

  2. Create a policy in Report-only mode and let it run for a week or two.

  3. Switch it to Block. Keep exceptions documented and narrow — usually the resource accounts of the Teams devices — and additionally restrict those to known networks.

Microsoft Learn recommends the same path: block as broadly as practical, and justify every exception individually.

Token Protection helps as well. It binds session tokens to the device that issued them and stops a stolen token from being replayed elsewhere. It does not replace the flow block, though. In Device Code phishing the victim herself authorizes the attacker’s session, so the token is already issued on their device.

If it has already happened, a password reset is not enough. The sessions must be revoked (Revoke-MgUserSignInSession), and inbox rules, newly registered devices, and MFA methods on the account need a check.

How does that look for you: Is there a policy that blocks the Device Code Flow, and is it on Report-only or On? And which accounts actually need the flow?