Authentication method registration is the step this attack actually targets, and almost nobody has locked it down. In September 2026 Microsoft described campaigns in which attackers phone staff claiming to be the organization’s help desk, warn of a service disruption, and walk the person through updating their passkey or multifactor settings. What follows is not a stolen passkey, because a passkey cannot be handed over by someone who does not understand what they hold. It is an enrollment: the victim is steered into an intermediary sign-in page or a device-code flow, the attacker obtains access, and then registers their own authentication method so they no longer need the victim at all.
The Five Points That Change Your Defense
Each of these moves the problem away from user awareness and toward configuration.
- The passkey is not what gets stolen. The attacker is enrolling a new method, not extracting an old one.
- The lure is a phone call, not an email. Your mail filtering never sees it, and neither does your phishing simulation program.
- Persistence is a registered method. Once their own method is on the account, a password reset alone does not evict them.
- Registration is a permission you can restrict. Most platforms let you control who may add an authentication method and from where.
- A new method should generate an alert. This is the single highest-value detection available and it is usually switched off.
Our guide to stopping identity-based account theft covers the wider category this sits inside.
Why Authentication Method Registration Is the Real Target
An attacker who obtains a session still holds something temporary, so the first thing they do is convert it into something permanent, and registering their own authentication method is how. That single step is what turns a successful phishing call into ongoing access. It survives the victim changing their password, because the new method is independent of the old credential. It survives the session expiring. It looks entirely legitimate afterward, because the account genuinely does have that method registered and every subsequent sign-in satisfies your policy properly. Firms that respond to a suspected compromise by resetting the password and nothing else leave this in place, which is why the same account is compromised again a fortnight later and everybody concludes the user has been careless.
Restrict Who Can Register a Method and From Where
Most identity platforms allow you to control authentication method registration, and configuring it removes the attacker’s persistence step entirely. The two controls worth setting are a location or network condition on registration, so a method can only be added from a trusted network or a compliant device, and a requirement to re-authenticate strongly before registering anything new. Some organizations go further and route registration through the help desk, which is worth considering for smaller teams where that is practical. The objection is real: restricting registration creates friction for a new starter, a person with a lost phone, or somebody traveling, and the help desk absorbs that work. Our answer is that those events are rare and schedulable, while the attack is opportunistic and constant, so the trade favors the restriction as long as somebody owns the exception path.
Alert on Every New Method, Without Exception
An alert when an authentication method is added to any account is the detection that would have caught every version of this attack, and it is usually available in tooling you already pay for. The volume is low, because in a settled organization very few methods are registered in a given week. That low volume is what makes it a good alert: anything appearing that nobody expected is worth a phone call to the user, made by you on a number you hold. Build the response into the alert rather than leaving it as a notification somebody reads and files. The counterpoint is that a firm with high staff turnover will see more of these and may start ignoring them, which is a fair risk. Route new-starter registrations through a known process so they are expected, and then anything outside it stands out rather than blending in.
Why Your Awareness Training Did Not Cover This
Phishing programs are built around email and this arrives by telephone, so the training people received does not fire, and neither does the simulation program you use to measure it. The person on the phone is helpful, knows their name, may know their role and their manager, and is warning them about something plausible. There is no suspicious link to hover over and no sender address to examine. Everything the staff member has been taught to check is absent from the interaction, which is precisely why the technique works on people who would never click a phishing email. Our phishing defense guide and our note on the mistakes firms make running simulations both assume an email-shaped threat, which is the honest limit of that category.
Give Staff One Rule That Covers the Whole Class
A single memorable rule works better than teaching people to recognize a scam, because the scam will be better next time and the rule will not need updating. The rule is that IT will never ask you to change an authentication method during an unscheduled call, and if somebody does, you hang up and call the number in your directory. That is one sentence, it covers every variation of this technique, and it gives the person something to do rather than something to assess. Say it plainly and repeat it in the same terms rather than paraphrasing, since the value is in the recognition. There is a reasonable objection that a genuine help desk sometimes does need to walk somebody through an enrollment urgently, and that this rule makes real support harder. That is true, and the fix is on your side: have the help desk send a ticket reference the person can verify rather than expecting them to trust a voice.
Make It Safe to Hang Up on Somebody Senior
The technique works partly because refusing is socially awkward, so the permission to refuse has to come from leadership rather than from a policy document. Somebody claiming to be from IT, or claiming a manager sent them, is banking on an employee’s reluctance to be difficult. Tell staff explicitly that hanging up and calling back is the expected behavior, that nobody will be criticized for it, and that this applies regardless of who the caller claims to be. That is the same social mechanism that makes payment callback rules work, and it fails for the same reason when it is left unsaid. Our note on which help desk tickets should never be automated covers the flip side, which is that your own support process needs a human at exactly these moments.
What to Check If You Think It Already Happened
The evidence sits in the authentication method list and the sign-in logs rather than in the mailbox, which is why these compromises are often found late or not at all. After access, the pattern described by Microsoft continues predictably: the attacker registers their method, enumerates what the account can reach through the platform’s own interfaces, and collects data from file storage and mail. None of that looks unusual in isolation. All of it is visible if you know which three things to look at.
Read the Registered Methods on Every Privileged Account
An authentication method nobody can account for is the clearest evidence available, and reviewing the list takes minutes per account. Start with administrators, finance, and anyone with broad file access, then widen. What you are looking for is a method registered on a date nobody remembers, or an authenticator application on a device the person does not own. Ask the user directly rather than inferring, since people do add methods and forget. Where a method cannot be explained, remove it and reset the account fully rather than leaving it pending investigation. The objection that this alarms staff unnecessarily is worth taking seriously, and the framing solves it: this is a routine check we run, not an accusation.
Look for the Enumeration, Not Just the Login
After access, attackers map what the account can reach using the platform’s own programmatic interfaces, which produces a distinctive pattern of activity that a login record alone will not show. A user account suddenly reading broadly across sites it has never touched, or generating a volume of interface calls no human workflow produces, is the signal. Check whether your platform retains that activity and for how long, because the answer decides whether a future investigation is possible at all. This is the same blind spot our note on AI-generated phishing threats describes from the delivery side: the volume and quality of the lure have improved faster than most firms’ ability to see what happened after somebody fell for one. For businesses whose support is outsourced, our guides on help desk support for law firms and choosing help desk support both cover the verification question worth asking a provider before you need it.
Write the Eviction Sequence Down Before You Need It
Removing an attacker from an account they have enrolled into is an ordered sequence, and doing the steps in the wrong order lets them re-establish access while you are still working. The order that holds is: revoke active sessions and refresh tokens first, then remove the unrecognized authentication methods, then reset the password, then re-enroll the user’s legitimate method under supervision. Reversing the first two is the common mistake, because removing a method while a live session persists gives the attacker a window to simply register another one.
Then check what the account did while it was held, which means reading the sign-in history and the interface activity rather than just the mailbox. Look specifically for mail forwarding rules, because those are the standard follow-on and they survive everything above if nobody removes them. Check whether any third-party application was granted access during the window, since that is a second persistence route that no password reset touches. The objection is that this level of process is disproportionate for a single suspected account, and for a false alarm it is. It takes twenty minutes when it is written down and most of an afternoon when it is improvised, so writing it down is what makes the proportionate response available.
Frequently Asked Questions
Can a passkey actually be phished?
Not in the sense of being handed over. The attack persuades somebody to enroll a new authentication method or to complete a sign-in through an intermediary page, which achieves access without the passkey itself moving.
Why did our email security not catch this?
The lure is a phone call, sometimes followed by a text message. Your mail filtering never sees it, and neither does a phishing simulation program built around email.
What is the single most useful control?
Restricting who may register an authentication method, and alerting whenever one is added. That removes the attacker’s persistence step and tells you when somebody tries.
Is a password reset enough after a suspected compromise?
No. If the attacker registered their own authentication method, that method survives a password reset. Review and remove unrecognized methods as part of the response.
How do we tell staff to handle these calls?
One rule: IT will never ask you to change an authentication method on an unscheduled call, so hang up and call the number in the directory. Then say publicly that doing so is expected of them.
Who You Are Taking This Advice From
Mindcore runs identity security for businesses whose help desk is two people or an outsourced provider, which is exactly the setting this technique is designed for. We lock down authentication method registration, turn on the alert that almost nobody has enabled, and write the one-sentence rule in language staff actually repeat back, and the guidance above comes from tenants we have configured and incidents we have unpicked rather than from an advisory. Matt Rosenthal, who leads Mindcore, keeps the firm focused on controls that do not depend on somebody being alert at the wrong moment, which here means a configuration change rather than another training module. Your staff should not have to out-argue a professional. Our job is to make the thing they are being asked to do impossible.
Your Next Move on Account Takeover
Open your identity platform and look at two screens. The first is whatever governs who may register an authentication method, which in most tenants is wide open, and tightening it is the change that removes the attacker’s foothold. The second is your alerting, where you want a notification on every new method registration routed to somebody who will act on it rather than into a dashboard nobody opens. Both are configuration rather than procurement. Then review registered methods on your privileged accounts this week and ask about anything nobody recognizes, framing it as routine rather than as suspicion. Finally, give your staff the single sentence and have a leader say out loud that hanging up on a convincing caller is the expected behavior. The firms that lose accounts to this are not the ones with careless staff. They are the ones where registering a new authentication method was something anybody could do, from anywhere, without anybody being told. If you want help setting the registration controls and the alert, book a free strategy call and we will start with your privileged accounts.
