Microsoft’s disclosure of passkey-themed phishing campaigns targeting Microsoft 365 environments demonstrates an important evolution in identity attacks: rather than trying to break passkey cryptography, attackers are increasingly attacking the processes around passkeys. Microsoft has observed campaigns since May 2026 in which threat actors research targeted employees, impersonate corporate IT or help-desk personnel, and create urgency around supposedly required passkey, MFA, or single sign-on updates. Victims may receive calls, text messages, or links on personal mobile phones directing them to websites designed to resemble Microsoft authentication pages. Despite the use of passkey terminology, Microsoft says the attackers are frequently not trying to steal an existing passkey or perform legitimate passkey enrollment. Instead, the passkey narrative provides a convincing pretext for adversary-in-the-middle phishing or device-code authentication flows that ultimately hand the attacker a valid cloud session.

This distinction is crucial because describing these attacks simply as “passkey phishing” can create the misleading impression that passkeys have lost their core security advantage. Passkeys remain fundamentally resistant to conventional credential phishing because the private key stays on the authenticator and authentication is cryptographically bound to the legitimate website origin. A fake Microsoft domain cannot normally ask the user to type in a passkey secret because there is no reusable secret for the user to enter. The attackers therefore change the problem. Instead of stealing the passkey itself, they persuade the victim to perform another legitimate authentication action that benefits the attacker. In adversary-in-the-middle scenarios, the victim can be guided through a proxied Microsoft sign-in flow so that credentials and session tokens are captured. In device-code attacks, the victim may enter a code or approve an authentication request that authorizes the attacker’s device rather than their own. The cryptographic mechanism remains intact while the surrounding workflow is manipulated.

This is a useful reminder that phishing resistance applies to a specific authentication ceremony, not automatically to every path leading into the same account. An organization may deploy passkeys for ordinary sign-in but retain device-code authentication, weaker MFA methods, help-desk resets, password recovery, legacy federation, or self-service authentication-method enrollment. Attackers will naturally choose whichever route provides the least resistance. Security therefore becomes a weakest-path problem. If the normal login requires hardware-backed phishing-resistant authentication but an attacker can persuade a help desk or victim to enroll a new authenticator through a weaker process, the strength of the original passkey matters much less.

Microsoft’s observed attack chain makes that weakness particularly clear. The threat actor typically conducts reconnaissance before contacting the victim, gathering employee names, organizational information, job roles, and potentially personal phone numbers from publicly available sources. The attacker then impersonates IT support and explains that the victim must urgently update a passkey, MFA, or SSO configuration to avoid losing access. That urgency is important because security upgrades themselves are increasingly familiar to employees. Organizations genuinely are asking users to enroll passkeys, replace weaker MFA methods, and reconfigure authentication. Attackers therefore imitate a perfectly plausible administrative task rather than inventing an unusual story.

This creates a difficult awareness problem because “never respond to an MFA enrollment request” is obviously impractical advice when organizations are actively rolling out MFA improvements. The stronger defense is procedural. Employees should understand that legitimate authentication-method enrollment should begin from a known corporate portal, device-management application, or direct navigation to Microsoft rather than from an unexpected SMS, phone call, Teams message, or emailed link. IT departments should communicate exactly how passkey registration campaigns are conducted so users can distinguish a genuine enrollment request from an attacker-created replica.

Microsoft also observed attackers using already-compromised employee accounts to send passkey-themed messages through Microsoft Teams. This makes the social engineering substantially more convincing because the communication appears to come from a genuine colleague within a trusted enterprise collaboration platform. The attacker no longer needs to spoof an external email address or convince the user that an unknown caller is really IT. They inherit the reputation of an account that the organization already trusts. This reinforces why internal messaging should not automatically be treated as authenticated intent merely because the sender identity is valid.

The same principle applies to help-desk impersonation. An attacker may know the employee’s name, department, manager, email address, or technology stack and use those details to sound legitimate. Public professional profiles make this reconnaissance easier, while previous breaches and infostealer databases can provide additional information. The sophistication of the attack therefore does not necessarily lie in malware or exploitation. It lies in assembling enough contextual information to make the security request feel routine.

After initial compromise, Microsoft observed attackers conducting Microsoft Graph reconnaissance and collecting data from Microsoft 365 services. Microsoft Graph is particularly valuable because it provides a unified API into email, files, directory information, Teams, SharePoint, OneDrive, and other cloud services depending on the privileges of the compromised identity. Once attackers obtain a valid token, they can potentially enumerate the victim’s cloud environment through the same APIs legitimate applications use. The activity may therefore look more like ordinary SaaS access than malware-driven data theft.

This is one reason identity telemetry has become as important as endpoint telemetry. If the victim clicks a phishing link from a personal mobile device that is not enrolled in the corporate EDR platform, Microsoft notes that endpoint evidence may be minimal or entirely absent. In some investigations, the employee’s recollection of a phone call or SMS becomes the earliest evidence explaining how the account was compromised. Investigators then have to reconstruct the chain using sign-in logs, device-code events, token activity, authentication-method changes, and subsequent cloud access.

Organizations should therefore retain and monitor authentication logs independently of endpoint detection. New authentication-method registrations, device-code sign-ins, unexpected MFA changes, new passkey enrollment, sign-ins from unfamiliar devices, token usage from unusual networks, and sudden Microsoft Graph activity should all be high-value signals. A security model that assumes successful MFA means the user must be legitimate is increasingly inadequate.

The persistence step is especially important. In many modern identity attacks, the attacker does not want to rely indefinitely on the initially stolen session token. Tokens expire, sessions may be revoked, and passwords can be changed. A more durable approach is to register an attacker-controlled authentication method after compromise. If the attacker can add a new MFA method or passkey to the victim’s account, they may be able to authenticate later using their own device even after the user resets their password.

This is why authentication-method changes should be treated almost like password changes for privileged accounts, and arguably with even greater scrutiny. An administrator or executive suddenly registering a new passkey from an unfamiliar device should trigger notification and potentially require independent approval. Organizations should also maintain visibility into all authentication methods registered against high-value accounts and remove methods that are no longer recognized.

Recovery procedures need similar protection. Password resets, MFA resets, lost-device recovery, and passkey replacement are deliberately designed to bypass the user’s normal authenticator when something goes wrong. That makes them attractive attack targets. A phishing-resistant login process paired with a weak help-desk recovery procedure is not truly phishing-resistant at the account level. Attackers will simply impersonate the employee to the help desk instead of impersonating Microsoft to the employee.

High-value accounts should therefore have stronger recovery requirements, such as manager approval, hardware-backed identity verification, known-device confirmation, or in-person checks depending on organizational risk. Help-desk personnel should also be trained to recognize social-engineering patterns around “lost phone,” “new device,” “passkey migration,” and “MFA reset” requests because these are increasingly part of attacker playbooks.

Another important control is restricting device-code authentication where it is not required. Device-code flows are useful for devices without conventional browsers or keyboards, but they are also attractive for phishing because the victim can be convinced to authorize a session initiated by the attacker. Organizations should review whether device-code authentication is actually needed across all users and applications and use Conditional Access controls to restrict or disable it where possible.

Microsoft’s findings also reinforce the value of strong Conditional Access policies. A valid token should not automatically provide unrestricted access from any device or location. Requiring compliant or managed devices for sensitive applications, restricting high-risk sign-ins, enforcing location or network conditions where appropriate, and requiring stronger authentication for privileged operations can reduce the usefulness of stolen sessions. No single Conditional Access rule will eliminate identity attacks, but it can prevent one successful social-engineering interaction from becoming unrestricted access to the entire cloud environment.

Token protection is equally important. Passkeys protect the authentication ceremony, but once a session token has been issued, that token itself becomes valuable. Adversary-in-the-middle frameworks exist specifically because stealing the post-authentication session can sometimes bypass the need to reproduce the MFA ceremony. Device-bound or token-binding mechanisms can reduce replayability by ensuring that a token obtained on one device cannot simply be reused from another attacker-controlled system.

The broader lesson is that authentication security has moved beyond passwords. Organizations spent years telling users not to reveal passwords, then deployed OTP-based MFA and discovered that attackers could ask for OTPs as well. Push notifications produced MFA fatigue attacks. Adversary-in-the-middle phishing targeted session cookies. Passkeys remove many of those weaknesses, so attackers are now shifting toward enrollment, recovery, OAuth consent, device authorization, help-desk impersonation, and other workflows surrounding the authenticator.

This is not evidence that passkeys have failed. It is evidence that attackers adapt to stronger controls.

When one security boundary becomes difficult to break, adversaries search for another boundary that leads to the same outcome.

That is precisely what good security controls are supposed to force them to do.

The next step for defenders is ensuring that the alternate paths are not dramatically weaker.

Organizations should therefore avoid using phrases such as “phishing-proof MFA.” Passkeys and FIDO2 authentication are correctly described as phishing-resistant because their cryptographic design prevents many traditional phishing techniques. But no authenticator can stop a user from being socially engineered into authorizing an attacker’s device through an entirely different workflow, nor can it protect an account if administrators permit weaker authentication methods to coexist indefinitely.

The objective should be phishing-resistant identity architecture rather than merely phishing-resistant login.

That means securing initial enrollment, daily authentication, device-code flows, authentication-method changes, account recovery, help-desk resets, OAuth consent, session tokens, and privileged actions as one continuous trust lifecycle.

The attack also highlights the importance of removing weaker fallback authentication once passkeys are deployed. If users retain SMS OTP, email verification, push MFA, and weak account recovery alongside passkeys, attackers may simply ignore the passkey. Security teams should progressively phase out weaker methods where business and platform capabilities permit, particularly for executives, administrators, finance personnel, and other high-value identities.

User awareness still has a role, but it needs to evolve. Employees should be taught that attackers increasingly impersonate IT support and use security terminology correctly. A caller knowing that the company uses passkeys is not evidence that the caller works for IT. Unexpected requests to re-register authentication, visit a link sent through SMS, read out a device code, approve a login, install remote-access software, or alter MFA should trigger independent verification through a known corporate channel.

The most effective verification process should be simple enough that employees actually use it. If validating an IT request requires finding a six-page intranet document and opening three service-desk tickets, people will predictably take shortcuts. Organizations should provide one obvious mechanism, such as calling the known internal help-desk number or opening the official IT application, to confirm security-related requests.

Incident response must also reflect the persistence mechanisms attackers use. Changing the password alone may not remove access. Responders should revoke active sessions and refresh tokens, review authentication methods and registered passkeys, remove unauthorized devices, inspect OAuth application consent, review mailbox rules and forwarding, investigate Microsoft Graph activity, and examine remote-access tooling if present. The account should not be considered recovered until all alternate access paths have been evaluated.

The broader significance of Microsoft’s disclosure is that passkeys are beginning to change attacker economics. Traditional credential phishing becomes less useful against accounts using strong origin-bound authentication, forcing adversaries toward more interactive social engineering and identity-workflow abuse. That raises the cost and complexity of compromise, which is a security improvement. However, attackers with sufficient motivation can still exploit gaps between the authenticator and the processes controlling it.

The right conclusion is therefore not that passkeys can be phished in the traditional sense. The more accurate conclusion is that attackers are phishing the human and the surrounding identity workflow when they cannot phish the cryptographic credential. That distinction matters because the remedy is different. You do not fix this by abandoning passkeys. You fix it by making enrollment, recovery, session management, and administrative changes as resistant to impersonation as the passkey itself. Passkeys close one of the biggest doors attackers have used for years. The current campaigns show them searching for the side entrance. The job now is to make sure that entrance does not have a spare key sitting under the mat.

Microsoft has disclosed details of two campaigns in which threat actors are abusing third-party email delivery infrastructure to blast financial fraud scam messages and using passkey-themed social engineering to breach cloud environments. The first campaign, per the tech giant, involved sending over a million scam emails between August 3 and 5, 2026, by masquerading as chief executive officers

Source: Attackers Use Passkey Phishing to Hijack Microsoft Cloud Accounts and Exfiltrate Data via The Hacker News — published 13 Sep 2026.