Passkey-Themed Helpdesk Scams: Guarding the Moment a New Sign-In Method Is Added

Passkeys are spreading fast, and attackers have noticed. On 9 September 2026, Microsoft described a campaign in which callers posing as IT support told employees that an urgent passkey or MFA update was required, then steered them into handing over access to their cloud accounts. According to Microsoft's analysis, the activity has been seen since May 2026 and was followed by reconnaissance and bulk collection of data from email, SharePoint and OneDrive.

The lesson is not that passkeys failed. The passkey story was a pretext: the actual compromise came through lookalike sign-in pages, device code prompts and, critically, the attackers' ability to register their own authentication methods on the victim's account afterwards. Strong sign-in methods only protect you if the moment a method is added, reset or recovered is just as well guarded. This article looks at that moment and what to check this week.

What the campaign looked like

Microsoft attributes the activity to several groups, including actors it tracks as Storm-3121 and Storm-3032, which ID Tech Wire reports are linked to extortion operations. The chain Microsoft describes runs in a familiar order:

• Pretext. A phone call or text message, often to a personal number, creates urgency around a supposed security requirement such as passkey enrolment.
• Initial access. The victim is sent either to a lookalike sign-in page that relays credentials and the session (adversary-in-the-middle), or to a legitimate device sign-in page where entering a code quietly authorises the attacker's client.
• Persistence. The attacker registers a new phone number, authenticator app or software token on the account, so access survives a password reset as long as sessions are not revoked.
• Reconnaissance and collection. Automated queries map the directory, roles, applications, sites and mailboxes, followed by steady, paced downloads over hours or days.

None of these steps relies on a software vulnerability. Each one abuses a legitimate process: helpdesk support, a convenience sign-in flow, self-service method registration or ordinary API access.

Why method registration is the weak point

Organisations often put real effort into the sign-in itself, then treat "add a new sign-in method" as a routine profile change. That gap is what makes persistence cheap. If a session obtained through phishing is enough to add an authenticator, the attacker no longer needs the phishing page.

NIST SP 800-63B-4 is clear on this. When a new authenticator is bound to an existing account, the process must require authentication at the highest assurance level available on the account, or at the level the new authenticator will be used for, whichever is lower. The account holder must also be notified through a channel independent of the transaction that added the authenticator. Recovery is treated as its own controlled event, with defined methods such as recovery codes or repeated identity proofing.

Two practical consequences follow. First, a phishing-resistant method protects the account only if registering a weaker one requires that same strength. Second, the notification has to reach the real user somewhere the attacker does not control; an email to a mailbox the attacker can already read is not independent.

Close the convenience flows you do not use

Device code sign-in exists for devices without a keyboard or browser, such as conference room hardware. It is also a standing invitation for phishing, because the victim completes the sign-in on a genuine page. Microsoft's Conditional Access documentation calls device code flow "a high-risk authentication method" and recommends blocking it wherever possible, with narrow exceptions for specific devices or network locations. The same documentation covers authentication transfer, which moves a signed-in state from one device to another; Microsoft's campaign guidance recommends blocking both unless there is an explicit business need.

Before blocking, check the sign-in logs for real device code usage so you can carve out exceptions rather than break meeting rooms. Running the policy in report-only mode first is a sensible way to see the impact.

Make the helpdesk part of the security boundary

Helpdesk impersonation is not new. In 2025, after attacks on UK retailers, the NCSC advised organisations to review how the helpdesk authenticates staff before resetting passwords, especially for accounts with elevated privileges. Microsoft's latest guidance extends this to MFA: verify identity through a rigorous process before any helpdesk-initiated credential or MFA reset, and alert on every such reset.

The other half is the employee's side of the call. If staff are told that IT never asks them to enrol a passkey over the phone or by text, and they know exactly where to report an unexpected request, the pretext loses most of its force.

What to check this week

1. Inventory recent method registrations. List authentication methods added in the last 30 days, prioritising admins and anyone with risky sign-ins. Confirm unexpected ones with the user through a known channel and remove those that are not theirs.
2. Harden the registration step. Require phishing-resistant MFA, a fresh interactive sign-in and, where possible, a managed device or trusted location before anyone can add or change a sign-in method.
3. Notify out of band. Make sure users and the security team are alerted when a method is added, through a channel separate from the session that made the change.
4. Block device code and authentication transfer flows except for documented devices and locations, after reviewing actual usage in your logs.
5. Write down the helpdesk verification procedure for password and MFA resets, apply a stricter version to privileged accounts, and alert on every reset.
6. Tell staff what IT will never do, such as asking them to set up a passkey over the phone, and give them one place to report it.
7. Rehearse containment. For a confirmed compromise, Microsoft recommends revoking sessions and refresh tokens, resetting credentials, removing attacker-registered methods and mailbox rules, and requiring secure re-registration. Know who does each step and how long it takes.

Detection: look at the combination

Individually, a new authenticator, a burst of directory queries or a large download may each have an innocent explanation. Together, within a short window on the same identity, they tell a story. Microsoft recommends enabling Graph activity and mailbox audit logs, then correlating identity events, such as new method registrations and risky sign-ins, with programmatic enumeration and unusual file or mail access.

Useful signals include methods registered shortly after a sign-in from an unfamiliar or unmanaged device, broad enumeration of roles, applications and sites from a single session, and sustained downloads at a steady pace that stays under simple volume thresholds. Limiting unmanaged devices to web-only access without download or sync, and disabling anonymous sharing links, reduces what a stolen session can take even when detection is slow.

Conclusion

This campaign shows attackers adapting their pretext to whatever security change users have been told to expect, and right now that is passkeys. The defence is not to slow the rollout. It is to treat enrolment, recovery and helpdesk resets with the same rigour as sign-in, to switch off flows nobody needs, and to watch for the pattern of new methods followed by quiet bulk access. If you are consolidating identity across systems, a single place to enforce those rules, such as OXU Identity, makes them easier to apply consistently.

Sources

• Microsoft Security: Passkey-themed social engineering leads to identity and cloud compromise
• ID Tech Wire: Microsoft tracks passkey-themed social engineering behind cloud data theft
• NIST SP 800-63B-4: Authenticator event management
• Microsoft Learn: Authentication flows as a condition in Conditional Access
• NCSC: Incidents impacting retailers, recommendations from the NCSC