Start here: when a caller who claims to be IT tells you to “update your passkey right now,” the danger is not that they copied the Passkey private key. It is that you handed them a live sign-in. Adversary-in-the-middle kits steal the session. In the device-code path, the page can even be a real Microsoft host. Changing the password covers only the password layer. It does not retire an authenticator they already enrolled. What you can check on this device is the call path, the hostname in the address bar, and whether Security info grew a device you do not own—not the sentence “I already use a Passkey.”
Answer the search intent in one sentence
A passkey, as WebAuthn defines it, keeps the private key on this device or in a synced keychain and binds it to the relying-party origin. A fake login host cannot export that key. That is the range in which “phishing-resistant” is true. The range in which it is not: you are rushed through a sign-in, and the session token lands with them; or you type a code they gave you on a genuine Microsoft page, and the token is issued to a client they control.
This note is for people who already enrolled a passkey and still get a call or text that says “update it,” and for developers and ops who have to explain why a Passkey is not a get-out-of-vishing card. It is not a substitute for Microsoft’s incident write-up, and it is not a how-to for turning passkeys off. What you should take away is which layer the script covers, which layer the session and the device code each steal, why changing the password is not enough, and what you can check on this device after you hang up.
What this disclosure split apart
On 9 September 2026, Microsoft Security Research published an English briefing. They are tracking ongoing cloud-identity intrusions: unusual sign-ins, then authentication methods the actor added, heavy Microsoft Graph traffic, SharePoint and OneDrive downloads, and mailbox collection through REST APIs. The write-up says this activity has been observed since May 2026.
It does not open with a polished phishing email. It opens with a call or a text to a personal mobile number. The caller claims to be the company help desk and manufactures urgency: the passkey, multifactor authentication, or single sign-on must be updated at once or the account will break. The link often arrives in a second SMS to the same personal phone. Microsoft is blunt: even though the script talks about Passkeys, enrolling a passkey is often not the real goal. The story exists to walk someone into one of two technical paths—adversary-in-the-middle (AiTM) phishing, or device-code authorization.
The AiTM path captures credentials and session tokens. In the device-code path, the victim is talked into typing a short code on Microsoft’s own authentication page; the token is issued to a client the actor controls, so they do not need a browser cookie. Either path can let later access skip MFA. If the link is opened on a personal phone that is not onboarded to Defender, endpoint telemetry can be almost empty. In those cases, the person’s memory of the call or the text is often the earliest—and sometimes the only—evidence of how the intrusion started.
The infrastructure is built to look familiar. Themed hosts in the write-up include passkeyhelpdesk.com, setupmypasskey.com, add-passkey.com, and secure-passkey.com, plus company names dropped into a subdomain, such as contoso.add-passkey.com. The same company name can also sit under an SSO-themed host such as integratedsso.com. Domains can go live hours after registration, which leaves a short block window. In some cases the actor also uses an already-compromised colleague account to send the same “update your passkey” message in Teams, stacking internal trust on top of the phone call.
Microsoft ties the initial-access work to several clusters, including Storm-3121 and Storm-3032. Storm-3121 often feeds ShinyHunters and Falcon extortion. Storm-3032 is described as a split from BlackFile that now operates under the Helix banner. That is ecology, not a proof that every “IT call” you get is the same crew. What belongs in a handoff note is the script plus the two technical paths—not a gang name.
A passkey stops a fake host. It does not stop a session you hand over
Reading “phishing-resistant” as “I cannot be talked into this” welds the credential layer to the session layer. A passkey is bound to the site origin at enrollment. A lookalike of the Microsoft sign-in page on some other host still cannot pull the private key you stored for login.microsoftonline.com. That advantage over password reuse is real. It does not need to be walked back.
One timeline in the investigation shows where the advantage stops. At T+0 minutes, an unmanaged context hits OfficeHome and gets error 50074, which asks for a second factor. At T+1, MFA completes—the write-up says adversary-in-the-middle plus non-phishing-resistant MFA—then 50140 interrupts “keep me signed in.” In the same minute, authentication succeeds and a session is established. Over the next hour, that same session opens My Apps, the profile, approval management, and Security info, then walks SharePoint and Outlook through Graph. Once the session exists, they do not need your passkey again.
So “I already use a Passkey” only supports a narrow claim: a fake host is unlikely to export that private key. It does not support: you will not be rushed through a password or SMS code on a lookalike page; an adversary-in-the-middle kit cannot take the token that sign-in just minted; Security info will not grow their authenticator. Those last sentences need other evidence: whether the hostname you opened is an official sign-in host, and whether Security info shows a device you did not add.
Do not use a real work account to “test” the link or the device code from the call. A disposable line is enough: hang up, then call back through the IT channel your company published in writing. You are checking the call path and the address bar—not handing them another live sign-in.
Why device code can succeed on a real host
Adversary-in-the-middle still has to stand up a page that looks like sign-in. Device code removes that layer. The official flow is: a client shows a short code; you open Microsoft’s device-login page in a browser; you type the code; that approves “that client” to act as you. The page is real. The certificate is real. The address bar survives “is this Microsoft.” The trick moves to a different question: who generated this code, and which app receives the grant.
The second attack sequence in the write-up is exactly that: after the passkey script, the victim types a code the actor supplied on a legitimate authentication page, and the token is issued to a client they control. They then replay that token, enumerate the directory and files, and skip both cookie theft and another MFA prompt. For anyone trained to check the lock and the hostname, this is harder to catch in the moment—the layer you were taught to inspect is green.
So “the address bar is Microsoft” only supports: you did not type a password into a lookalike such as add-passkey.com. It does not support: this code belongs to your own laptop; after you approve it, the token will stay in your browser. A code read to you on a call, in a text, or in chat should be treated as their client by default—not as “official page, therefore safe.”
Why changing the password does not cover an authenticator they enrolled
After they get in, the first move is often not more file browsing. It is writing their own authentication method into your identity. The write-up lists a new phone number, an authenticator app, or a software one-time-password token. A real audit sample from 4 September 2026 shows a newly added record whose device name is NO_DEVICE, whose device tag is SoftwareTokenActivated, and whose hash-function field is hmacsha1. That is not “they set another password.” It is “the next second factor can be completed by them.”
Microsoft’s remediation for a confirmed compromise is one sequence: revoke active sessions and refresh tokens, reset credentials, delete the methods they enrolled, remove mailbox rules they added, and re-enroll with a phishing-resistant method. Changing the password and skipping Security info leaves a key they already fitted. A third investigation sequence shows they can come back days later with a PhoneAppOTP they enrolled earlier, then walk Graph with a Node.js automation—password correct, second factor “passed,” and the factor is theirs.
Local Password Audit compares the string against a public list of common leaked passwords. The password is not uploaded, and the check is not a full-web Have I Been Pwned lookup. It can tell you the string is too common. It cannot tell you Security info grew a NO_DEVICE row, and it cannot prove the call was fake. A weak password and a hijacked session are not the same column of data. Do not substitute one for the other.
| What you see | What it supports | What it does not support |
|---|---|---|
| I already enrolled a passkey | A fake host is unlikely to export that private key | Nobody can rush you into handing over a live sign-in |
| The address bar is a Microsoft host | You did not type a password into a lookalike | The device-code grant is for your own client |
| The caller named the company and a department | They did open-source reconnaissance | The call used a callback path your company verified |
| I changed the password | The password layer was rotated | Strange authenticators and unrevoked sessions are dead |
| I opened the SMS on my phone; the work PC looks clean | This workstation’s endpoint log may be empty | No cloud-identity session was established for them |
| A colleague also pinged me in Teams to update the Passkey | The message came from a signed-in internal account | That account is still controlled by the person it names |
After you hang up, which layers you can check now
A slogan is not evidence. Check only what you control: whether the call used a channel you already trust, the hostname you are about to open, and whether Security info grew a device. Do not use a production account to open the link from the call as an experiment.
- Hang up. Contact IT through the ticket portal, internal site, or callback number your company published in writing. Do not call the number that just rang. Do not tap the SMS link. Microsoft tells employers to give staff a verified channel for reporting unsolicited authentication requests.
- If you already opened the link: look only at the hostname. A company name in the subdomain with a suffix such as
add-passkey.com,setupmypasskey.com, orsecure-passkey.comis not a Microsoft sign-in host. Do not type a password, an SMS code, or a passkey confirmation on that page. - If someone asks you to “type a code on the official site”: ask which app and which device generated it. A code someone else read to you is their client. The official device-code page can still be genuine while the grant lands on their app.
- After you sign in through a path you trust, open Security info / My Sign-Ins and read every method. Extra phone numbers, authenticators, and software tokens—especially a device name that is not your phone—get a session revoke and a delete through the admin process. Do not stop at a password change.
- When you must hand a short one-time secret to a colleague you already verified, switch to a ciphertext path. Open Burn-Link and write a disposable canary such as
canary-fp-20260921-passkey-lure. Open DevTools Network and check Preserve log. After you generate the link, search for that canary: thePOST /secretsbody should hold ciphertext, expiry, and read count—not the plaintext, and not the key after#. The link shape iss.html?id={id}#{key}. RFC 9110 says the request target URI excludes the fragment.
The first four steps close the channel that takes over the identity. The fifth step covers a different common mistake: screenshotting “the code IT asked for” or a temporary password into chat. Image hosts and albums keep pixels and, often, OCR. The previous note covered that. Burn-Link uploads ciphertext only; the key stays after #. Do not mix the two channels—do not screenshot into chat and then paste the full burn URL back onto the same image.
Do not put the full link and the plaintext on the same path. A device code read over the phone, a screenshot in chat, and a full s.html?id=…#… string are three different leak surfaces. If the key and the lock travel in the same message, the hash no longer protects anyone who can see that message.
Three ways to over-read “I have a Passkey”
First, reading phishing-resistant as social-engineering-resistant. A passkey is bound to the origin. That targets a fake login page that tries to export the private key. A call, a text, or an internal chat can walk around that layer and land you in adversary-in-the-middle or device code. Microsoft’s own mitigation list puts training against voice and email phishing next to “enforce phishing-resistant MFA,” and it also says to block device-code flow when you do not need it.
Second, reading “the page is official” as “the grant is mine.” The device-code page can be a real host. The lock icon does not tell you who the token is issued to. The evidence is where the code came from: a prompt on your own device, versus a number someone read to you, are not the same event.
Third, reading a password change as closure. Password, session, authenticators they enrolled, and mailbox forward rules are different switches. The write-up wants them handled together. Generating a new password locally only covers services that still use a password: open the password generator—ready to use, length 6–128, default 16, a warning below 8, computed in the browser, nothing uploaded. That does not revoke sessions. It does not delete a method you did not enroll.
FAQ
I already enrolled a passkey. Can this phone call still work?
Yes, and often not because the Passkey was copied. The script uses passkeys as a pretext. What they want is the session an adversary-in-the-middle kit captures, or the device code you type on a real Microsoft host for their client. A passkey is bound to the relying-party origin. That blocks a fake login page from exporting the private key. It does not block you from authorizing their app.
If the address bar looks like Microsoft, is it safe to enter a device code?
The device-code sign-in page is supposed to be a genuine Microsoft host. The risk is not “is this a fake site.” It is “who generated this code, and which app receives the grant.” A code read to you on a call or in a text authorizes their client, not your own browser session.
If I change the password, is the incident over?
No. Microsoft wrote that after they get in, they enroll their own phone number, authenticator, or software token. Changing the password without revoking sessions and deleting those methods leaves a factor they already control. Extra devices on the Security info page have to come off through the official remediation steps.
A colleague asked for a one-time code in chat. Can I send a screenshot?
Do not drop a live OTP or a device code into a chat album. Encrypt a short string in this tab with AES-256-GCM and send it through Burn-Link, with the key after #. The shape is s.html?id={id}#{key}. Create and read are both ready to use; no account. Confirm the person through a channel your company already published—not the call that just claimed to be IT. Material larger than 32 KB belongs in the File Encryption Box: one file up to 5 GB, output .lock / .enc.
Move a short secret onto a ready-to-use path
If you want a page that writes the compute boundary in the open, so you can practice “hand back a password, skip the screenshot,” open FastPwd Burn-Link. No signup. Write the canary above, leave the read count at 1, generate the link, then compare Network as in the fifth step: the body should hold ciphertext only—not the plaintext, and not the key after the hash. Use this path only after the colleague is verified. Do not screenshot first. Do not read a device code back to a stranger on the phone.
If a chat log or a ticket still stacks phone numbers and ID numbers, run rule-based redaction on Clean Link before you decide to send. The wash stays on this device. Source text is not uploaded as business data and is not written to analytics. For sites that still use a password, generate a unique one locally. Do not reuse the string the caller rushed you to type. Password Audit only answers “is this a publicly common weak password.” It does not answer “was that call fake.”
The next time a caller says “update your passkey now,” keep three sentences. First, Passkey in the script is often only the pretext; they want a session or a device-code grant. Second, a real host does not stop you from issuing a token to someone else’s app. Third, closure is Security info plus session revoke—not a password change alone. Those three sentences can go in a handoff note. “I turned on passkeys, so I can ignore the call” cannot.
Further reading
After a password is cropped into an image host, a login hash does not cover OCR plaintext or an Image ID—see Why OCR plaintext and Image IDs from a screenshot host are more dangerous than a password hash. A burn-after-read link can prove the server deleted the ciphertext; it cannot prove the recipient skipped a screenshot—see Why a burn-after-read link can prove the server deleted the ciphertext, but cannot prove the recipient did not take a screenshot. Why the span after # stays out of HTTP—see Why a URL hash can hold a key, and when that protection fails.