Passkeys are the story presented to the victim—not the broken control

Microsoft Security Research says it has observed active cloud intrusions since May 2026 in which unusual sign-ins were followed by attacker-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through APIs.

The campaign uses passkey registration, MFA updates, SSO migration, or account activation as social-engineering pretexts. Microsoft says the objective is often to steer the victim into adversary-in-the-middle phishing or a device-code flow that gives the attacker a usable session.

Do not misdiagnose the incident

Microsoft’s reporting does not show attackers breaking passkey or WebAuthn cryptography. Calling this a “passkey bypass” can send defenders toward the wrong fix. The failure is in social engineering, alternate authentication paths, session handling, and weak controls around identity changes.

A valid cloud identity becomes the route to persistence and collection

StageMicrosoft-reported behaviorDefender focus
Pretext and contactA supposed help-desk worker uses a call, text, Teams message, or personal-phone link to demand an urgent passkey, MFA, or SSO update.Give users a trusted way to verify support requests and preserve their account of off-device contact.
Session compromiseAiTM phishing captures a session, or the victim completes a legitimate device-code page for an attacker-controlled client.Correlate sign-ins, authentication protocol, device state, IP or proxy context, and the user’s reported interaction.
Authentication persistenceThe actor adds a phone number, authenticator, or software OATH method to the compromised identity.Alert on authentication-method changes, especially after a risky sign-in or from an unfamiliar session.
Cloud discoveryThe session enumerates applications, identity details, and accessible resources through Microsoft Graph and Microsoft 365 services.Baseline Graph activity and investigate rapid, broad discovery by users who do not normally automate administration.
Collection and exfiltrationThe actor collects email and downloads content from SharePoint, OneDrive, and other accessible services.Detect unusual API volume, content searches, downloads, mailbox access, and new destinations as one behavior chain.

Personal-device contact can leave the SOC without the opening scene

When the lure arrives by voice call or SMS and is opened on an unmanaged phone, corporate mail and endpoint controls may record nothing. The earliest useful evidence may be the employee’s recollection, followed by identity events that appear technically valid.

That makes single-event triage fragile. A successful sign-in, a newly registered MFA method, a Graph request, or a file download may each have an innocent explanation. Their sequence—particularly when compressed into minutes and tied to an unfamiliar device or proxy—creates the stronger investigative signal.

Threat Field Notes assessment

The durable detection is not a list of lookalike domains. It is the transition from unusual authentication to identity persistence, cloud reconnaissance, and collection. Infrastructure changes quickly; the attacker’s required objectives change more slowly.

Reduce alternate paths and make identity changes observable

  1. 1

    Create a trusted help-desk verification path. Tell users that support staff will not ask them to approve an unexpected device code, relay a code, or register an authentication method from an unsolicited link. Provide a known internal number or portal for verification.

  2. 2

    Audit device-code use before restricting it. Filter Entra sign-in logs by authentication protocol and identify legitimate dependencies. Microsoft recommends blocking device-code flow wherever possible; test the policy in report-only mode and document narrow exceptions.

  3. 3

    Protect authentication-method changes. Alert on new phones, authenticator apps, software OATH tokens, passkeys, and device registrations. Enrich each event with the initiating session, device, location, risk, administrator action, and nearby sign-ins.

  4. 4

    Prefer phishing-resistant authentication. Move privileged and high-risk users toward passkeys or FIDO2 methods while removing weaker fallback paths that permit real-time code or push relay. A strong method is undermined when an attacker can steer the user into a weaker flow.

  5. 5

    Join identity and Microsoft 365 telemetry. Correlate Entra sign-ins and audit logs with Microsoft Graph, SharePoint, OneDrive, Exchange, OAuth consent, mailbox, and endpoint events. Preserve timestamps and request identifiers for reconstruction.

  6. 6

    Rehearse complete identity containment. For confirmed compromise, block sign-in, revoke sessions, reset credentials, remove unauthorized authentication methods, review devices and app consent, and scope mailbox and cloud-data access. Test the order and required roles before an incident.

Look for the sequence across identity and cloud data

  • A device-code or AiTM-associated sign-in from an unmanaged device followed by a new authentication method or device registration.
  • Authentication-method changes made shortly before or after sign-ins from new proxy infrastructure, geographies, user agents, or device identities.
  • High-volume or unusual Microsoft Graph requests from a user who does not normally run scripts, administration tools, or data-export workflows.
  • Rapid navigation across My Apps, account-management services, SharePoint, OneDrive, Exchange, and internal SSO applications from one new session.
  • Mailbox or file collection followed by archive creation, external sharing, OAuth grants, forwarding rules, or transfers to unfamiliar destinations.
  • A password reset without corresponding removal of attacker-added authentication methods or revocation of active sessions and tokens.

Provider reporting defines the observed scope

The activity description and attack-chain assessment come from Microsoft’s telemetry and investigations. Microsoft describes active intrusions spanning multiple accounts, but the report does not establish how common this technique is across all tenants or prove that every similar event belongs to the same actors.

Tenant configuration, licensing, log retention, and legitimate device-code use differ. Defenders should validate detections and response steps in their own environment, and should not treat a registrar, hosting provider, or isolated authentication event as malicious without supporting evidence.

How this analysis was prepared

This topic was surfaced by The Cyber Security Hub newsletter on LinkedIn. Threat Field Notes independently reviewed Microsoft’s original research and current Microsoft Entra guidance, then wrote this defender-focused analysis in original language.

The article deliberately separates the newsletter’s framing from the primary-source finding: passkeys were used as a lure, while the observed compromises relied on social engineering, session theft, device-code abuse, and attacker-controlled authentication methods.