Device-code phishing is up fifteenfold, and it walks straight past your passkeys

This technique defeats phishing-resistant MFA, and it does so without breaking any cryptography. That is worth sitting with for a moment, because a great deal of security advice over the last three years has treated passkeys as the end of credential phishing.

The OAuth 2.0 device authorization grant exists so you can sign in to a device with no keyboard — a TV, a printer, a conference-room display. Entra ID exposes it without pre-authentication. The attacker requests a code from Microsoft, sends it to the victim with a plausible pretext, and the victim enters it at microsoft.com/devicelogin — the real page, on the real domain, with a valid certificate. Approval happens after authentication, so the victim often sees nothing but an account picker. The attacker collects an access token and a refresh token.

There is no phishing site to detect, no lookalike domain to block, and no credential to rotate. The user did exactly what security awareness training told them to do: check the URL.

Then it gets worse inside Microsoft

From that token the attacker can escalate to a Primary Refresh Token and abuse the Family of Client IDs relationship, pivoting silently between Microsoft first-party clients — Outlook, Teams, OneDrive, SharePoint — without another prompt. Persistence sits in a long-lived refresh token and, frequently, a registered device.

The volume numbers

CrowdStrike's 2026 threat hunting data records fifteen times more device-code phishing in the first half of 2026 than in the second half of 2025 — a 1,500% rise — alongside vishing doubling over the same comparison. Push Security detected a 15x increase in device-code phishing pages by March, revised to 37.5x by May, and counts more than fourteen distinct kits in circulation. In one documented case the whole chain from phishing to attacker-registered MFA device took twelve minutes.

eSentire documented a Tycoon2FA campaign in late April wrapping this in five layers of delivery: a click-tracking link in a vendor-invoice email, a Cloudflare Workers redirect, an AES-GCM payload decrypted in the browser, anti-analysis checks against a 230-entry list of security vendor networks, and a fake Microsoft CAPTCHA before the real device-login page.

The fix is one Conditional Access policy

Block the device code flow. Microsoft's own guidance is to block it for any tenant with no legitimate use in the past 25 days, which is most tenants. Exempt the specific shared-device or developer scenarios that genuinely need it, by group, and document why.

Push Security's caveat is fair and worth repeating: blocking device code flow does not cover adjacent OAuth consent-abuse techniques. Pair it with admin consent requirements for third-party applications and Continuous Access Evaluation so that revocation actually propagates.

← All advisories