Microsoft Passkey Phishing: How the Attack Chain Reaches Your Data

The passkey is not necessarily what attackers are breaking.

It is the story they use to make an unusual authentication request sound legitimate.

Microsoft has documented active cloud intrusions that begin with attackers impersonating IT support and claiming that a passkey, multifactor authentication method, or single sign-on configuration must be updated. After obtaining access, the attackers may register another authentication method, inspect the tenant through Microsoft Graph, and collect files or email from Microsoft 365.

The most important detection signal is not one suspicious login. It is the sequence that follows it.

Key takeaways

Microsoft has observed this intrusion pattern since May 2026.
“Passkey update” is generally a social-engineering pretext—not evidence that passkey cryptography was broken.
Initial access has involved adversary-in-the-middle phishing and device-code authorization.
Attackers may register authentication methods under their control for persistence.
Investigation must connect Entra ID, Microsoft Graph, SharePoint, OneDrive, and Exchange activity.

How does passkey-themed phishing begin?

The attack commonly begins with a call, text, or message from someone impersonating the organization’s helpdesk.

The employee is told that a passkey, MFA method, or SSO configuration must be updated urgently. The attacker may use a website that resembles Microsoft’s sign-in experience or, in some cases, a previously compromised Microsoft Teams account.

The organization’s name may appear in the phishing address, surrounded by convincing terms such as “secure passkey,” “verification,” or “SSO.” That familiarity makes the request appear connected to a legitimate internal process.

According to Microsoft Security Research, the passkey narrative frequently leads victims into one of two access paths:

An adversary-in-the-middle process that captures credentials or session material.
Device-code authorization that causes the employee to approve an attacker-controlled session.

The campaign does not demonstrate that attackers defeated passkey cryptography.

What happens after the login?

The successful sign-in is only the first stage.

Microsoft observed attackers moving through a recognizable identity-to-data sequence:

Stage	Activity
Initial access	Helpdesk impersonation followed by AiTM or device-code authentication
Persistence	Registration of a phone, authenticator application, or software-based token
Reconnaissance	Microsoft Graph queries for users, groups, roles, applications, permissions, sites, files, and mailboxes
Collection	SharePoint, OneDrive, Exchange, message, file, and attachment access
Possible exfiltration	Sustained or automated retrieval across Microsoft 365 workloads

An attacker-controlled authentication method may extend access beyond the original session. Graph reconnaissance then reveals which people, applications, files, mailboxes, permissions, and repositories the compromised identity can reach.

This is why a password reset alone may not complete recovery.

Why can isolated alerts miss the intrusion?

Each individual event can resemble legitimate Microsoft 365 activity.

Employees sign in. Authentication methods change. Applications query Microsoft Graph. SharePoint files are downloaded. Mailboxes are searched.

The meaning emerges when those events appear in sequence under the same identity, token, application, or session.

Microsoft observed collection continuing for hours or days. Attackers generally accessed fewer than 1,000 files or emails during a single hour, demonstrating why one static “large download” threshold may fail to detect gradual collection.

The better question is not:

Did one event exceed our alert threshold?

It is:

Did an unusual authentication lead to new persistence, broad discovery, and unexpected data access?

Does this overlap with device-code phishing?

Device-code authorization is one access method within the newer campaign, but it is not the complete story.

Infonaligy has already published a detailed explanation of how device-code phishing compromises Microsoft 365 accounts. This campaign deserves separate coverage because Microsoft documented a much broader progression from social engineering through authentication persistence, Graph reconnaissance, and cloud-data collection.

That full progression—not the device-code mechanics—is the focus here.

What should Microsoft 365 administrators do?

Restrict unnecessary authentication flows

Use Entra Conditional Access to block device-code and authentication-transfer flows unless a documented business requirement exists.

Require phishing-resistant authentication, such as FIDO2 passkeys or Windows Hello for Business, for sensitive applications and security-information registration.

Protect authentication-method registration

Require fresh interactive authentication before security information can be changed. Restrict registration to managed devices, trusted locations, or other controlled conditions.

Alert on new phone numbers, authenticator applications, passkeys, or software tokens—especially when enrollment follows an unusual sign-in.

Monitor the complete sequence

Connect:

Risky or unfamiliar sign-ins.
Authentication-method changes.
Token issuance.
Microsoft Graph reconnaissance.
SharePoint and OneDrive activity.
Exchange, mailbox, and attachment access.
Unusual application consent or service-principal behavior.

A common Graph request may be harmless. Systematic discovery across several categories followed by content retrieval is far more significant.

Prepare employees and the helpdesk

Give employees a verified channel for confirming unexpected authentication requests.

The helpdesk should follow a rigorous identity-verification process before resetting credentials or MFA methods. Employees should know that IT will not ask them to enter an unsolicited device code or follow an unexpected passkey-registration link.

How should a compromised identity be recovered?

For a confirmed compromise:

Revoke active sessions and refresh tokens.
Reset the affected credentials.
Remove unauthorized authentication methods.
Require controlled authentication re-registration.
Delete attacker-created forwarding or mailbox rules.
Review OAuth consent, enterprise applications, delegated permissions, and service principals.
Investigate SharePoint, OneDrive, Teams, Exchange, and downloaded content.
Determine what data the compromised identity could access—not only what alerts were generated.

The Infonaligy perspective

A cloud intrusion should not be investigated as a collection of unrelated alerts.

Authentication, persistence, Microsoft Graph discovery, and workload access belong on one incident timeline.

The decisive question is not whether MFA succeeded. It is whether the resulting identity behavior matches the authorized employee, device, application, and business purpose.

Infonaligy’s Microsoft 365 Consulting and SOC Services help organizations connect identity controls, cloud monitoring, data protection, and incident response across the full Microsoft 365 environment.

Frequently asked questions

No. Microsoft says passkeys are commonly used as a social-engineering theme that leads victims into other authentication flows.

Yes. Device-code phishing can send the victim to Microsoft's real authentication page while authorizing a session initiated by the attacker.

It can provide more durable access after the initial session and allow the attacker to satisfy future authentication challenges.

Microsoft observed reconnaissance and collection involving SharePoint, OneDrive, Exchange, mail, attachments, users, groups, applications, and permissions.

No. Recovery should also revoke sessions and tokens, remove unauthorized authentication methods and mailbox rules, review application consent, and investigate accessed data.

The passkey may be only the opening story. Infonaligy can help determine whether an unusual Microsoft 365 authentication became a larger identity and data incident.