Microsoft Security Research is tracking a cloud-compromise pattern that should make every Microsoft 365 tenant owner take a second look at “secure” authentication workflows. The lure is modern and believable: employees receive a phone call or SMS claiming the help desk needs them to update a passkey, MFA, or SSO setting to avoid an access problem.

The passkey story is the hook. The objective is identity control.

According to Microsoft, the observed intrusions have included suspicious sign-ins, attacker-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive access, and mailbox collection through REST APIs. The activity has been observed since May 2026 and shows how attackers can turn one user interaction into cloud reconnaissance and data collection.

Original source: Microsoft Security Research — Passkey-themed social engineering leads to identity and cloud compromise. Feedly surfaced the story via The Hacker News.

What Microsoft reported

The campaign starts with identity-focused social engineering. Attackers contact employees directly, often through personal phones, and impersonate internal IT support. Victims are pushed toward counterfeit Microsoft sign-in pages or legitimate device-code authentication flows under the pretext of passkey or MFA maintenance.

That matters because the attack does not always require the attacker to steal a password in the traditional sense. In device-code phishing, the victim can be tricked into authorizing the attacker’s session. In adversary-in-the-middle phishing, the attacker can capture credentials or session tokens. In other cases, previously compromised credentials are reused after an attacker-controlled MFA method has already been registered.

Once inside, the attacker’s next move is persistence. Microsoft observed actors adding authentication methods they control, such as a phone number, authenticator app, or software-based OTP token. That turns a short-lived compromise into an identity foothold that can survive longer than defenders expect if sessions are not revoked and MFA methods are not reviewed.

Why this matters for SMBs and government contractors

Passkeys are often marketed as the safer future of authentication, and in many cases they are. The problem is that attackers are not attacking passkey cryptography directly. They are attacking the enrollment, help desk, and user-trust process around it.

For small businesses and government contractors, Microsoft 365 is often the real business control plane. A compromised user may expose:

  • SharePoint and OneDrive files containing proposals, contracts, invoices, HR data, or customer records.
  • Mailbox history that helps attackers build convincing vendor, payment, or executive impersonation lures.
  • Internal Teams conversations and organizational context useful for follow-on social engineering.
  • Application access paths exposed through My Apps, enterprise app catalogs, OAuth grants, or delegated permissions.
  • Authentication-method changes that give the attacker a way back in after the initial phish.

The key lesson: phishing-resistant authentication is only as strong as the process used to enroll it, reset it, and verify support requests.

The defender problem: Graph activity can look normal

A major detection challenge is that Microsoft Graph is used constantly in legitimate enterprise workflows. A single request to users, groups, sites, drives, messages, or attachments may not look suspicious on its own.

The signal appears in the sequence:

  • A suspicious sign-in from an unmanaged device or unusual location.
  • Access to My Sign-Ins, My Apps, profile, or authentication-management pages.
  • A new MFA method or phone/authenticator registration.
  • Broad Graph enumeration of users, groups, roles, applications, SharePoint, OneDrive, and mailbox resources.
  • High-volume file, attachment, or email content access.
  • Different infrastructure used for authentication, reconnaissance, and exfiltration.

That chain is far more useful than a single IOC. Domains and IPs will change. The identity-to-Graph-to-data pattern is durable.

Practical defensive takeaways

1. Treat MFA and passkey enrollment as privileged events

Alert on new authentication methods, especially phone numbers, authenticator apps, software tokens, and passkey changes for executives, finance users, admins, and proposal/contract staff. Do not bury these events in routine identity logs.

2. Lock down device-code authentication

If device-code flow is not required, restrict it. If it is required, monitor it aggressively. Device-code phishing is dangerous because the user may interact with a legitimate Microsoft page while unknowingly authorizing an attacker-controlled client.

3. Require out-of-band help desk verification

No same-call MFA reset. No same-text passkey enrollment. No “urgent IT support” identity changes without an independently verified ticket, known callback path, or manager-approved workflow.

4. Correlate Graph activity by behavior, not just volume

Build detections around progression: sign-in anomaly → authentication-method change → Graph reconnaissance → SharePoint/OneDrive/Exchange access. A low-volume targeted collection can be just as serious as a noisy download spike.

5. Revoke sessions during containment

Password resets are not enough. If a user is confirmed compromised, revoke active sessions, remove unauthorized authentication methods, review OAuth grants, rotate exposed credentials, and inspect mailbox rules, forwarding, delegated access, Teams activity, and SharePoint/OneDrive downloads.

6. Train users on the exact lure

Generic phishing training is not enough here. Users need to know that a phone call or SMS about passkey, MFA, SSO, account activation, or identity verification can be the opening move of a cloud compromise.

Bulwark Black assessment

This is not a story about passkeys failing. It is a story about attackers adapting to stronger authentication by targeting the human and administrative workflow around it.

For Microsoft 365 environments, identity is now incident response terrain. The organizations that fare best will not simply say “we have MFA.” They will know who can enroll factors, how help desk resets are verified, which users recently changed authentication methods, what Graph activity looks like after sign-in, and how quickly they can revoke sessions when a cloud account turns suspicious.

For SMBs and government contractors, the right move is practical: tighten enrollment, harden support workflows, and hunt for the sequence. If attackers are using passkey language to create trust, defenders need passkey-specific verification and telemetry to break that trust before it becomes data theft.