Device Code Phishing Grew 15x in 2026: Why Passkeys Do Not Stop It
Monthly device code phishing attempts grew 15 times in the first half of 2026, according to the CrowdStrike 2026 Threat Hunting Report published on 3 August. Device code phishing is an abuse of a legitimate login flow: the victim types an attacker-supplied code into Microsoft’s genuine sign-in page, and the attacker collects the session token. No password changes hands. In the same week Palo Alto Networks Unit 42 showed how malware lifts passkeys synced through Google Password Manager off an infected Windows PC. Read the two together and the message is one sentence. Your login held. Your session got taken.
What happened in the first week of August 2026?
Three disclosures landed inside five days, from three unrelated teams.
On 3 August CrowdStrike published its 2026 Threat Hunting Report. Beyond the 15x rise in device code phishing, vishing intrusions doubled in the first half of the year. One tracked group, SNARKY SPIDER, moved from account takeover to data theft in under five minutes.
The same day Unit 42 published three attack paths against Google Password Manager, named Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key. Each one starts from malware already running on a Windows machine with a TPM chip. From there the malware signs an authentication request with no fingerprint, no PIN and no click from the user. The strongest of the three lifts a 32-byte key called the Security Domain Secret out of Chrome’s process memory and decrypts every passkey in the account. Google’s current design offers no way to rotate or revoke that key.
Two days later Entra ID researcher Dirk-jan Mollema described a third path. Malware inside a signed-in Windows session can use the Windows Hello for Business key to authenticate to Microsoft Entra ID as a FIDO2 passkey, then collect a Primary Refresh Token valid for 90 days. As of 6 August there was no CVE and no Microsoft advisory. Mollema reads the behaviour as designed.
Why does device code phishing beat strong authentication?
It runs after the part you hardened. The device code flow exists for screens with no keyboard. A TV app shows a code, you type that code on your phone, the app receives a token. An attacker copies the choreography: you get a page that looks like SharePoint, it shows a code, you type the code into Microsoft’s real portal, you pass MFA, and the attacker receives the token.
Password strength plays no part. The second factor plays no part either. What the attacker holds at the end is an access token and a refresh token, and those keep working until someone revokes them.
| Attack path | What the attacker walks away with | What a password reset achieves |
|---|---|---|
| Device code phishing | An access token and a refresh token for Microsoft 365 | Nothing until you revoke the tokens |
| Pass-ta-key on synced passkeys | The device key, or the 32-byte master key for every synced passkey | Nothing. There is no password on a passkey |
| Windows Hello for Business abuse | A Primary Refresh Token valid for 90 days | Nothing until you remove the registered device |
Notice the third column. Your incident playbook still opens with a password reset.
Are synced passkeys still worth deploying?
Yes, and the Unit 42 paper says why. The researchers broke no cryptography. Every path they demonstrated starts with a Windows endpoint that an attacker already controls. A passkey still kills credential stuffing and it still defeats the phishing page that harvests passwords. What it does not do is survive a compromised laptop.
The research also produced a useful test for anyone buying software. Unit 42 tried the stolen assertion against real services. GitHub rejected it, because GitHub validates the user verification flag. eBay accepted it and fixed the gap after being told. That flag is one bit in the protocol, and whether your vendor checks it decides whether a stolen key becomes a stolen account. Ask your SaaS vendors the question in writing.
Google removed the Security Domain Secret from Chrome’s log output after the disclosure. The key stays reachable in memory while a device re-registers.
And in Switzerland?
Identity for most Swiss SMEs lives in Microsoft 365 and Entra ID, so the device code flow is a live setting in your own tenant today. Nobody has to attack Switzerland for this to reach a firm in Lugano or Zug. The kits are sold as a subscription and they point at whoever answers.
The legal side is short. The revised Federal Act on Data Protection asks you to secure personal data in proportion to the risk, and to notify the FDPIC when a breach likely creates a high risk for the people concerned. A stranger reading a client mailbox for 90 days with a valid token meets that bar in most readings. The fact that your MFA worked is no defence, because the attacker never went through it.
One more Swiss detail worth the minute: an attacker who owns a refresh token leaves fewer traces than one who guesses a password, so the sign-in logs your auditor asks for may show a clean record while the mailbox drains.
What to do now
- Close the device code flow. In Entra ID a Conditional Access policy blocks it for the whole tenant and allows it for the handful of devices that need it. Budget an afternoon, not a project.
- Treat tokens as credentials. Put token revocation into offboarding and into the first hour of your incident procedure, next to the password reset that is already there.
- Alert on registration, not on failure. A new device or a new authentication method appearing on an account is the event worth waking someone. Failed logins are noise next to it.
- Match the key to the value of the account. A synced passkey is as strong as the laptop holding it. For admins, finance and anyone who can move money, use a hardware security key.
The same week gave a fourth number worth keeping: 88% of the exploitation CrowdStrike observed against vulnerabilities with public proof-of-concept code started within 48 hours of that code appearing. We wrote about that clock when time-to-exploit went negative.
So, who in your company can say by Friday how many refresh tokens are alive in your tenant?
FAQ
Does this mean passkeys are broken?
No. Unit 42 broke no cryptography and every attack path needs malware already running on the victim’s Windows PC. Passkeys still stop phishing pages and password reuse.
Are all passkeys affected?
The research covers passkeys synced through Google Password Manager in Chrome on Windows with a TPM. Hardware security keys and passkeys held in other ecosystems sit outside its scope.
What is device code phishing in one sentence?
An attacker starts a login for a device with no keyboard, sends you the code, and you approve their session inside Microsoft’s real sign-in page.
Can we block the device code flow without breaking anything?
In most tenants yes. Check which conference room systems and shared devices use it, allow those, block the rest with Conditional Access.
How fast do these attacks move?
CrowdStrike recorded one group going from account takeover to data theft in under five minutes, which is shorter than most alert triage queues.
Sources
CrowdStrike, 2026 Threat Hunting Report, 3 August 2026. Unit 42 (Palo Alto Networks), “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication”, 3 August 2026. BleepingComputer, “New Pass-ta-key attacks let malware hijack Google-synced passkeys”, 3 August 2026. The Hacker News, “Malware Can Abuse Windows Hello for Business Keys for Persistent Entra ID Access”, 6 August 2026. Dark Reading, “Device Code Phishing Up 1,500% in 2026; Vishing Doubles”, 4 August 2026. Huntress data via Axios, 23 June 2026.
