Microsoft has documented criminals phoning staff, posing as IT, and walking them through a fake passkey setup. The cryptography held, and the unfamiliar enrolment prompt is what they exploited.
The Passkey Prompt We Warned You About Is Now the Attack
A month ago we wrote that Microsoft's move away from SMS codes would put an unfamiliar security setup screen in front of your staff on a random morning, with nobody having warned them and no easy way to tell whether it was genuine. We called it a phishing-awareness problem as much as an IT one.
On 9 September Microsoft published research showing criminals running exactly that pretext. Someone phones your employee, claims to be from IT, and walks them through what looks like a passkey enrolment. By the end of the call the attacker holds a working credential in your tenant.
One thing to be clear about before anything else, because plenty of the coverage has got it wrong: passkeys were not broken. Microsoft is explicit that the cryptography held and the security model was not bypassed. What failed was the space around it, the unfamiliar prompt and an authentication flow most businesses have never thought about.
What Microsoft described
The research covers two groups Microsoft tracks as Storm-3121 and Storm-3032, active since May 2026. Storm-3121 is an access broker, meaning it doesn't monetise the intrusion itself. It sells the way in to somebody else.
The pattern runs like this. The victim gets a phone call, sometimes preceded by a phishing email, from someone presenting themselves as internal support. They're told they need to set up a passkey, and they're talked through it live. The page they're sent to sits between them and Microsoft, passing the real login through while capturing the session.
In parallel the attackers abuse the device code authentication flow. That's the mechanism you'd normally use to sign a smart TV or a conference room display into a Microsoft account: the device shows a short code, you type it into a browser on your phone, and the sign-in completes. Turned around, it lets an attacker generate a code, persuade a human to enter it, and receive a valid token without ever handling the password or the second factor. Microsoft's own description is that this effectively bypasses multi-factor authentication.
Once in, the pace is worth noting. Microsoft observed sessions moving from first look to data leaving the tenant inside 50 minutes. SharePoint and OneDrive downloads and mailbox collection ran through Microsoft's own APIs, which is why it looks like ordinary traffic to most monitoring.
Microsoft gives no victim count, no financial figure and no percentage. If you see one attached to this story, it came from somewhere else.
Why your helpdesk is the weak point, not your technology
The uncomfortable part is that the victim did nothing obviously stupid. They answered a call from IT, during a period when their employer genuinely was changing how they log in, and followed instructions.
A business rolling out passkeys creates a window where an unfamiliar prompt is expected, and expected prompts don't get questioned. The attackers are relying on a change that is genuinely happening.
We said in August that this was avoidable with a fortnight's notice by email. That's still the control we would put first. Tell people the date, describe what the screen will look like, and say plainly that nobody from IT will ever ring to walk them through it. Staff who know the rollout is due on the 14th will find a call on the 9th strange.
Worth being honest about the limits of that claim: we described the risk, we didn't predict this campaign. We named no attacker and no phone-based pretext, and we weren't the only ones pointing at the enrolment window. What we did get right is where the exposure would sit.
Block the device code flow this week
In most businesses of forty people, nobody has ever looked at this setting.
Almost nobody in a normal office needs the device code flow. It exists for devices without a proper browser, and if you don't have shared meeting-room displays or similar hardware signing into Microsoft 365, nothing in your business uses it. Leaving it enabled keeps open a route your business never uses.
In Microsoft Entra, Conditional Access can block authentication flows, device code among them. Build the policy in report-only mode first, leave it a few days, and look at whether anything legitimate trips it. Report-only mode records what the policy would have blocked while still letting the sign-in through, so you get the evidence before you change anything. If nothing trips it, which is the usual outcome, switch it on.
If something does trip it, you've learned which device depends on it, and you can exclude that one rather than leaving the flow open to everybody.
The attestation problem nobody mentions
The enrolment window deserves attention beyond this campaign, and the reason is a detail in how Microsoft checks passkeys.
Microsoft checks passkey attestation, the proof that a credential came from hardware you trust, at the moment of registration and not afterwards. A passkey registered while attestation is switched off keeps working when you switch attestation on later. Tightening the setting protects future registrations and leaves the existing ones exactly as they are.
We flagged this in August as a reason to get the configuration right before the rollout rather than after. It matters more now. If an attacker has talked a user through registering a credential during a period when your tenant accepted anything, that credential is indistinguishable from a legitimate one, and no amount of tightening removes it.
Registered passkeys are listed per user in the Entra admin centre, under that user's authentication methods. Review what is there, particularly anything registered outside the window when you were deliberately rolling them out, and remove the credentials nobody can account for.
What to do about it
Send the notice. If passkeys are coming, tell staff the date and what the prompt looks like, and say clearly that IT will never ring to walk them through it. We would do this one first.
Block the device code flow in Conditional Access, in report-only mode first.
Audit registered passkeys, especially any from before you enforced attestation, and remove anything unexplained.
Give your helpdesk a script for the reverse call. Staff will now ring to ask whether the prompt is real. That's the behaviour you want, and it needs somebody who can answer quickly rather than a ticket queue.
Keep going with passkeys. This is the conclusion the coverage keeps missing. The attack did not defeat the technology, it defeated the rollout. Retreating to SMS codes would move you to a method Microsoft is retiring and that is weaker against exactly this kind of phishing. Our post on the SMS retirement timetable covers the dates and the configuration decisions.
The honest summary
An attacker phoned an employee during a genuine security upgrade and got a credential. The cryptography held, and there is no patch to install.
The businesses that come through this well will be the ones whose staff were told what was coming, and who closed a login route they never used. None of that depends on having better technology than anyone else.
If you'd like us to check which authentication flows your tenant currently allows, and what's registered in it, book a discovery call and we'll take a look with you.
