I wouldn't stop your passkey rollout because of this attack.

But I would check a few things around it.

Microsoft published an interesting write-up recently about a series of cloud intrusions that started with something almost boring: someone pretending to be IT.

The pitch was that the user needed to update a passkey, MFA, or SSO configuration. From there, the attacker tried to steer the victim into a different authentication flow, including adversary-in-the-middle phishing and device-code authentication.

That detail matters because it is easy to walk away with the wrong conclusion. Passkeys are not the problem here. Phishing-resistant authentication is still one of the best improvements you can make to a Microsoft 365 identity environment.

The problem is everything around the passkey.

The part that caught my attention

When I look at this attack, the most important part is not the initial phone call. Social engineering has been around forever. What stands out is what happens after the attacker gets a foothold.

Microsoft observed attackers adding new authentication methods, using Microsoft Graph for reconnaissance, and collecting information from SharePoint, OneDrive, and Exchange. This can move very quickly from someone clicking the wrong thing to an attacker establishing persistence and learning a lot about the tenant.

Passkeys still make sense

I would not use this attack as a reason to slow down a passkey rollout. I would use it as a reason to finish the identity architecture around the rollout.

A phishing-resistant credential protects the authentication ceremony where it is used. It cannot stop someone from being talked into approving a completely different flow. It also cannot save a weak help-desk recovery process or an overly permissive authentication-method registration policy.

That means the real project is bigger than turning on passkeys.

What I would check in a Microsoft 365 tenant

• Authentication-method registration. Who can register a new method, from what devices and locations, and under what authentication conditions?
• Device-code authentication. Does the organization actually need it? If not, I would strongly consider blocking it.
• Conditional Access. Are sensitive actions protected by stronger authentication, device compliance, location, or risk controls where appropriate?
• Privileged accounts. Administrators and executives deserve a separate look because the impact of persistence is much higher.
• Microsoft Graph activity. A compromised identity doing large-scale enumeration or collection should not blend into normal activity.
• Help-desk recovery. MFA resets and account recovery need a real identity-verification process, especially for privileged users.

The bigger lesson

Microsoft 365 security has a habit of exposing the gaps between individual controls. You can deploy a very strong authentication method and still have trouble if enrollment, recovery, app consent, device access, monitoring, or incident response is weak.

That is why I am increasingly skeptical of “we enabled MFA” as a meaningful description of identity security. The details matter.

Passkeys are a good control. Conditional Access is a good control. Defender is a good control. None of them operate in isolation.

Where I would go from here

For most organizations, I would not turn this into a giant emergency project. I would use it as a reason to spend an hour looking at the identity paths attackers are now targeting.

Start with authentication registration and recovery. Then look at device-code authentication, Conditional Access, privileged identities, and the visibility you have into Graph and cloud activity.

If those pieces are solid, great. If they are not, you have a much more useful security backlog than simply chasing another few points in Secure Score.

My five-minute checklist