13 SEP 2026 — Microsoft has described a campaign that opens with a phone call about setting up your passkey and ends with an attacker reading your mailbox through an API. It has been reported as passkey phishing. Microsoft's own account says the opposite: rather than targeting passkeys, the attackers use the narrative as a ruse.
The passkey is the pretext. What gets registered afterwards is an ordinary software one-time-code app, belonging to somebody else.
The sequence, in order
It starts with a call or message to the user's personal phone from someone claiming to be the organisation's IT helpdesk, saying a passkey or MFA configuration update is needed now. The urgency is the point. So is the use of a personal number, which bypasses any channel the employer monitors.
The victim is directed to a site imitating the Microsoft sign-in page. What happens there is either adversary-in-the-middle phishing, which captures credentials and session tokens, or an abused device-code authentication flow, which persuades the victim to authorise the attacker's access outright.
Only then does the attacker register an authentication method of their own. Microsoft describes newly registered MFA devices carrying populated device tokens, and the addition of software one-time-code methods — PhoneAppOTP, SoftwareTokenActivated — with fabricated tokens.
After that comes reconnaissance through Microsoft Graph across users, groups, permissions and applications, then bulk collection from SharePoint, OneDrive and Exchange Online, visible as large volumes of file-accessed and file-downloaded events. The activity has been observed since May.
Why adding a factor is the clever part
When an organisation discovers a compromised account, the reflex is to reset the password. Against a stolen password, that works.
But it does nothing to a credential the attacker registered themselves. A one-time-code app enrolled on the attacker's own device is a legitimate factor on that account, issued through the normal flow, and it survives every password change. The account looks remediated and is not.
The irony sits in Microsoft's own remediation advice, which is to enforce phishing-resistant MFA — FIDO2, passkeys, Windows Hello — through conditional access. Passkeys are the fix for this campaign, and passkey migration is the story the attackers tell. A user who already had one would have had nothing to hand over at the fake sign-in page, because a passkey cannot be given to a site that is not the real one. The people phished are the ones who have not made the move the call claims to be helping them make.
A tenant is a different shape of problem
A consumer account with an unexpected extra factor is a bad day for one person. A corporate tenant is a different shape of problem, and two properties make it so.
The first is that an added authentication method is per-identity and invisible from every other identity. Nobody else in the organisation can see it, and the account holder will not notice a credential they never use and were never shown. Discovery depends on an administrator deliberately auditing a list most have never opened.
The second is what a single mailbox is worth inside an organisation. It carries the internal address book, the invoice threads, the naming conventions and the tone of the people who sign things off — which is the raw material for the fraud campaign Microsoft disclosed on the same day. Persistence on one account is the input to the next attack, not only an end in itself.
Bulk collection through the API, not the browser
The exfiltration half is as instructive as the persistence half. Microsoft Graph and REST APIs are the documented, supported way to read a mailbox or a document library at scale.
An attacker using them is not evading detection so much as arriving somewhere detection often is not. Monitoring built around interactive sign-ins and web sessions sees a user logging in from an odd place; it does not necessarily see an application token pulling a mailbox down over a supported interface, because that is what legitimate integrations do all day.
The signal Microsoft names is volume. Graph activity itself is normal; what stands out is an unusual amount of it against one identity in a short window.
What to check today
Audit the registered authentication methods on your tenant, specifically ones added recently to accounts that did not ask for them. Most organisations have never run this audit.
Then check whether adding a method generates an alert anybody reads. In many tenants it is logged and nothing more, which is how an attacker's enrolment sits quietly beside the legitimate ones.
When an account is remediated, treat the credential inventory as part of remediation, not just the password. The question is not what the attacker used to get in. It is what the attacker left behind that still works.
The identity perimeter, again
None of this involves a vulnerability. No software was exploited, no patch is pending, and every step used a supported feature in the way it was built to be used.
That is the recurring shape of cloud intrusion, and we have written it up repeatedly. The perimeter is identity, and the attacks that matter are increasingly about acquiring and keeping legitimate credentials rather than breaking code. A flaw gets a CVE and a deadline. An attacker-registered passkey gets neither, because nothing is broken.
What to watch
Whether Microsoft ships a control rather than guidance. Alerting on authentication-method registration is the obvious one, and making it default-on is a different commitment from documenting that customers can enable it.
And whether the reporting settles. The "passkey phishing" label has stuck, and it may lead organisations to conclude their passkey rollout is the problem, when the real gap is in detecting what happens after the initial sign-in.
View author profile → · Editorial policy
