A request to improve account security can itself be the attack. In research published September 9, Microsoft describes passkey-themed social engineering observed since May 2026. Attackers impersonated support staff, used credential or session theft and device-code authorization, and added authentication methods to compromised accounts. Microsoft also observed access to cloud files and email.
This does not show that passkey cryptography was broken. The request to enable or update authentication served as a pretext for authorizing attacker access. A separate September 3 investigation by Arctic Wolf documents helpdesk impersonation, stolen tokens and SaaS data theft. It provides independent context for the pattern, without establishing that the two investigations concern the same victims or operators. Neither report tells you whether your own organization has been compromised.
A genuine login page does not verify the caller
Microsoft describes device-code abuse in which the user completes authorization on Microsoft's real page. The dangerous part is whose client the code authorizes. Checking the domain is useful, but it does not establish that the requested operation belongs to your IT team. Microsoft continues to recommend phishing-resistant authentication.
Treat an unexpected enrollment request as a separate decision from an ordinary sign-in. Before acting, establish who requested the change, which account it affects and what device or application will gain access. Familiar terminology, an internal-looking message and a convincing caller are not substitutes for an approved change process.
Use a verification process the requester cannot choose
End an unexpected support call and open your organization's known support portal or call the number already listed in its directory. Do not use a callback number or verification link supplied in the same message. Ask the support team to confirm the exact task and ticket, including whether you should be registering an authenticator, approving an application or signing in to an existing service.
- For passkey enrollment: begin from the documented account settings on a trusted device after independently confirming the request. Know which device or security key you are enrolling.
- For a device code: use it only for an approved application and a sign-in flow you initiated. A caller reading you a code does not make that client yours.
- For a recovery request: follow the established identity-verification procedure. Do not send one-time codes, recovery codes, authenticator setup secrets or browser cookies to someone claiming to complete the process for you.
Make this interruption easy for employees. A genuine support agent should be able to continue through the established channel. Publish the verification route in advance, so someone facing an urgent call does not have to invent a way to check it.
If someone already completed the request
Report what happened promptly, even if the page looked legitimate and no password was disclosed. Record the time, the claimed support task and the application or device name shown during approval. Keep codes, tokens and other authentication material out of the ordinary ticket. The response team can collect sensitive evidence separately if needed.
Microsoft's containment guidance includes revoking sessions and refresh tokens, resetting compromised credentials and removing unauthorized authentication methods. For the account owner, the practical handback should include a review of the methods now registered and clear instructions for enrolling an approved replacement. Have the response team confirm the account is ready before starting that enrollment.
Preserve enough context to distinguish an attempted lure from a completed authorization. The support team needs to know whether you merely received a call, entered a device code, approved a prompt or registered a method. Those are different actions and may require different evidence. Do not assume that deleting the message reverses any of them.
Keep account recovery separate from secret delivery
An encrypted link cannot establish that the recipient is authorized to receive a credential. If the caller is an impersonator, delivering the password privately still gives it to the wrong person. Complete identity verification and the approved recovery process before considering any temporary-password handoff.
When that approved process requires person-to-person delivery, Secretus can carry a temporary password in a one-time encrypted link. Share only the value required for the task, keep the full link private and use a short expiry. Do not use a secret-sharing service to forward a session cookie or an authenticator setup secret. Secretus cannot remove an attacker's registered method or revoke an already authorized session.