What Storm-2949 Actually Broke: Identity Governance, Not Self-Service Password Reset

Microsoft disclosed Storm-2949 on May 18, 2026. The campaign progressed from a single compromised identity to cloud-wide breach — Microsoft 365 data theft, Azure Key Vault sweep, SQL exfiltration, VM compromise — without using malware. The most credible reaction in the security press named it "the reset gap": Microsoft's Self-Service Password Reset, the argument goes, accepted a completed MFA push as sufficient proof of identity, and social engineering harvested that proof. That diagnosis is correct as far as it goes. It also stops several steps short of what actually broke.

Storm-2949 reached Key Vault, SQL, and SharePoint because no governance control was watching what happened after the reset. Authenticator methods were changed on a privileged user account and nobody attested. A service principal was probed for credential injection and nobody monitored. A standing Azure Owner role over a critical Key Vault sat permanently assigned, and nobody asked why. The reset was the door. The lack of governance behind it was the room with the safe.

This is the first piece in our threats series. We publish here on Credential Governance — the discipline that, deployed before the breach, would have produced multiple chances to stop Storm-2949 between the SSPR call and the four-minute secrets sweep.

Two phases, ten steps, no malware. The red-glowing steps are where the attacker established and exploited each governance gap — the password reset and authenticator re-registration that made the identity look legitimate, and the standing Owner role that made the four-minute Key Vault sweep possible.

What Storm-2949 actually did

Two phases, three identity-system surfaces, no malware.

Phase one — Entra ID and Microsoft 365. The actor initiated SSPR on a targeted user — an IT administrator and a senior leader, both holding privileged Azure RBAC. The actor then placed a phone call impersonating internal IT support and coaxed the user into approving a "routine" MFA prompt that the actor had just triggered. Once approved, the actor reset the password through the legitimate SSPR flow, stripped the existing authentication methods from the account (phone, email, Authenticator), and registered a new Microsoft Authenticator on the actor's own device. The legitimate user was now locked out; the actor held compliant Entra ID MFA.

A custom Python script then enumerated the tenant through Microsoft Graph for additional privileged identities, group memberships, and service-principal listings. Three more accounts were compromised the same way. OneDrive and SharePoint were swept for VPN documentation, remote-access procedures, and operational runbooks — the kind of content that prepares phase two.

Phase two — Azure. With administrator-level RBAC inherited from the compromised user, the actor extracted an App Service publishing profile (microsoft.Web/sites/publishxml/action), pivoted into Key Vault as Owner, and harvested dozens of secrets in four minutes. SQL firewall rules were rewritten (microsoft.sql/servers/firewallrules/write) to expose databases to the actor's IP range. Storage accounts were enumerated for SAS tokens (microsoft.Storage/storageAccounts/listkeys/action). VMAccess and Run Command extensions were used to install ScreenConnect on compromised VMs and disable Microsoft Defender real-time protection.

Microsoft's published indicators include three actor IPs: 176.123.4[.]44, 91.208.197[.]87, and 185.241.208[.]243 (ScreenConnect C2). No traditional malware was deployed at any phase. Every action used legitimate Azure management-plane primitives by a properly authenticated, properly authorized identity that the attacker had successfully impersonated.

Microsoft's own framing of the campaign is precise. The Threat Intelligence team wrote that the actor was "increasingly targeting identity and control plane access rather than individual devices," and that "legitimate administrative features can be used to achieve outcomes similar to traditional lateral movement." The reactive security press has largely focused on the SSPR step. Both are right. Neither addresses what made the rest of the chain possible.

Why the "reset gap" framing misses the point

The strongest reactive analysis we have read, from a specialist vendor in the password-reset category, calls this "the reset gap" — the structural fact that Entra ID's SSPR treats a completed MFA approval as sufficient proof of identity. That diagnosis is correct. It is also the first ten minutes of a two-hour incident.

If we close the reset gap perfectly — replace SSPR with phishing-resistant identity verification, demand government-issued ID checks and biometric liveness at every reset, lock the door — Storm-2949 would have failed at the first step in this specific incident. But the next campaign will use a different door. A compromised service-principal credential. A misconfigured CI/CD pipeline. A stolen session cookie from an unmanaged device. A consent-grant phishing scheme. A subtly exfiltrated managed-identity token. The cloud-control-plane surface is large enough that every breach we will see this year will find a way through one of those doors.

What stops a determined actor who is already past the first door is not a better reset. It is governance. Specifically: continuous evidence that the access an identity holds is still appropriate, watched by controls that fire on the change, not just on the access. Identity governance is the discipline of asking, every day, what each identity in the directory can do, who attested that they should still be able to, and what would alert us if any of those answers changed without a corresponding workflow ticket. We wrote about a structurally similar architectural failure in our Stryker analysis on MFA strategy — the lesson generalizes.

Storm-2949 produced at least five distinct governance moments that should have triggered an alert. None did. That is the actual story.

Five gaps, five controls. Each one maps to a specific moment in the published Microsoft attack chain — and each one is addressable with governance controls that are standard, well-understood, and absent from most enterprise Entra ID deployments today.

The five identity-governance gaps Storm-2949 exploited

Each of the gaps below maps to a specific moment in the published Microsoft attack chain. Each one is independently addressable with governance controls that are standard, well-understood, and absent from most enterprise Entra ID deployments today.

Authenticator-registration drift

The compromised user had a working Microsoft Authenticator, a phone number, and an email recovery method. Within minutes of the SSPR completion, all three were removed and a new Authenticator was registered on a device the user did not own. There is no plausible business workflow that produces that sequence — no help-desk ticket, no scheduled credential rotation, no enrollment ceremony.

A governance control watching for unauthorized authenticator-method changes — particularly changes that happen outside an active service-desk ticket, outside a scheduled rotation window, or to accounts with privileged RBAC — would have alerted within seconds. The technique is straightforward: subscribe to the Entra ID audit log for UserManagement.UserUpdate.AuthenticationMethod events, correlate against the lifecycle workflow system, fire on the delta. Microsoft documents the audit signal. Most tenants do not consume it.

Service-principal hygiene

The actor's Python script enumerated service principals across the tenant. According to Microsoft's writeup, the actor then attempted to inject credentials into one compromised service principal — and the attempt failed only because the principal lacked sufficient permissions, not because anyone was monitoring service-principal credential changes.

Service principals are non-human identities. They drift faster than human identities because nobody owns them by default — they were created by an application team six years ago, the application was renamed twice, the team disbanded, and the credentials never rotated. Storm-2949 found a service principal someone had forgotten about. Service-principal hygiene as a governance discipline includes ownership attestation (every SP has a named human owner), credential rotation on a schedule (90 days or shorter for privileged principals), permission recertification at the same cadence as human identity recertification, and explicit decommissioning when applications retire. Most enterprises run none of these as continuous controls.

Standing privileged RBAC

The four-minute Key Vault sweep depended on the compromised user holding a standing Owner role on the Key Vault. Standing privilege is the assumption that historic role assignments remain valid forever — that a Cloud Engineer who needed Key Vault Owner in 2022 to migrate a workload still needs it today, three years later, after the workload moved twice. Most tenants accumulate years of standing privileged RBAC. Most tenants have never recertified it.

Just-In-Time elevation — Privileged Identity Management in Microsoft's terminology, JIT RBAC in the generalized form — removes the standing assumption. The user does not hold Owner. The user requests Owner for a specific task, receives time-limited approval, performs the task, and the role expires automatically. At the moment Storm-2949 reached the Azure control plane, no human held a standing Owner role. The four-minute sweep would have needed a four-minute elevation request first, which would have failed the policy check on a recently-authenticated session from an unusual IP.

This is not theoretical. It is documented Microsoft practice. The control gap is the one between "Microsoft has built this product" and "the customer has configured it."

Service-desk identity verification

Storm-2949's initial-access step depended on the user believing the caller was IT. The attacker placed a phone call. The attacker used social engineering to coax the user into approving the MFA prompt that the attacker had simultaneously triggered. The reset gap closed if the user had refused the call. The reset gap stayed open because the user had no way to independently verify the caller's identity.

Out-of-band service-desk verification with a workflow-tied token addresses this directly. The pattern: when a service-desk agent needs to assist a user with a reset, recovery, or authenticator change, the agent generates a verification code visible only inside the IT ticket system. The user reads the code back on the call. No code, no help. An impersonating caller cannot produce the code because the impersonator does not have access to the service-desk ticket system. The user — without any technical training — knows in 15 seconds whether the caller is legitimate. Avatier's Identity Anywhere Password Station implements this pattern. It is not novel. It is not patented. It is the standard architectural answer to phone-based social engineering at the service desk, and most enterprises have not deployed it.

Cross-environment lateral-movement visibility

The cloud control plane is many surfaces. Entra ID, Azure RBAC, Key Vault, SQL, Storage, App Service, VM extensions — each is monitored by its own logging pipeline by default. Storm-2949 moved through all of them in under an hour because no single dashboard watched the identity's path through the graph. The user signed into Entra ID. Five minutes later, the same identity hit the Graph API. Three minutes later, the same identity read a Key Vault. Twenty minutes later, the same identity rewrote a SQL firewall. Each event was logged. Each was logged in a different system. The events told a story only when reconstructed after the breach.

Identity governance at the workload graph level means watching the identity's behavior across the surfaces it touches, not just the surfaces individually. The technical pattern is unified identity-event ingestion — Entra audit logs, Azure activity logs, Defender for Cloud signals, and the workload-specific audit streams flowing into a single identity-graph view. The governance pattern is the alert that says: this identity, in the last 45 minutes, touched seven control surfaces it has not touched in the previous 90 days. That alert fires before the four-minute Key Vault sweep. Most enterprises have not built it.

Why phishing-resistant MFA alone wouldn't have stopped this

Phishing-resistant authentication — FIDO2 keys, WebAuthn passkeys, PKI smart cards — would have prevented the initial-access step in Storm-2949. The actor could not have completed the SSPR-and-impersonation chain against a user who holds a hardware-bound credential bound to the legitimate IdP origin. We have written extensively about phishing-resistant methods in our Best Passwordless Authentication Solutions for 2026 guide. For the initial-access step, phishing-resistant MFA is the right answer.

It is not, however, sufficient. Phishing-resistant MFA on the privileged user would not have prevented:

• A compromised service-principal credential being used by an actor who never touched a human-MFA flow at all
• A standing Azure Owner role assignment being used after a stolen session cookie from an unmanaged developer machine
• A misconfigured Azure DevOps pipeline emitting a managed-identity token to a compromised log aggregator
• A consent-grant phishing scheme that gets the user to authorize a malicious application with delegated permissions

Each of those alternate paths reaches Key Vault and SQL through a different door, none of which a phishing-resistant authenticator on the front door closes. The lesson Storm-2949 should leave is not "deploy phishing-resistant MFA" — that conversation was already settled in CISA's 2022 guidance and reinforced by the federal phishing-resistant MFA mandate. The lesson is that even after that conversation is settled, an enterprise still needs the governance layer to catch the exploitation once an attacker is inside.

What governance controls would have caught this earlier

The five gaps in the previous section each map to a control. Three of them are documented Microsoft practice that the customer must configure. Two of them require external tooling because the native Entra ID surface does not cover them well. None of them are novel research.

Conditional Access with phishing-resistant authentication strength for administrators. Microsoft documents this. Tenants who had configured it would have forced FIDO2 / PKI on every privileged sign-in including the Storm-2949 compromise targets. The SSPR step would have proceeded; the post-reset privileged access would have failed.

Privileged Identity Management (PIM) for all Azure Owner, Contributor, and User Access Administrator roles. Microsoft documents this. The Key Vault Owner role would not have been standing. The four-minute sweep would have required a four-minute elevation request from a session that, by configurable policy, the elevation system would have flagged as anomalous.

Continuous service-principal credential inventory and attestation. Microsoft surfaces the data; the governance discipline is the customer's. The actor's enumeration would have produced abnormal Graph API queries against the SP inventory. Credential injection attempts against a properly attested SP would have failed because rotation policies would have invalidated stale credentials before Storm-2949 found them.

Identity audit-log ingestion into a unified identity-graph view. Tooling required. The pattern is well-documented; the implementation requires either a SIEM with strong identity-event modeling or an identity-governance platform that does it natively. The alert pattern — "this identity touched N control surfaces it has not historically touched in the last M minutes" — is the one that fires during the breach, not after.

Out-of-band service-desk identity verification. Tooling required. The technique — workflow-tied verification codes visible only inside the ticket system — is implementable by hand for any team willing to write the integration, and is shipped natively by Avatier Identity Anywhere and a handful of comparable workforce IAM platforms.

The honest read on Storm-2949: Microsoft built the controls. The customer did not deploy them. The reactive-security framing of the incident as a Microsoft product gap is wrong. It is a governance-deployment gap.

Standing privilege gives the attacker a four-minute Key Vault sweep before any SOC alert can fire. Just-In-Time elevation removes the standing role entirely — the same compromise produces no exfiltration because the elevation request fails the policy check before access is granted.

The four-minute window — why detection alone is too late

The Microsoft writeup specifies that Key Vault secrets were enumerated in four minutes. That figure matters because it is faster than most enterprise detection-and-response pipelines can react. Even with a well-instrumented SIEM, the median time from log emission to alert review to analyst escalation to containment action is measured in tens of minutes, often hours. Four minutes is below the floor.

The architectural response is not better detection. It is prevention via standing zero privilege. If the Azure Owner role does not exist at the moment of attack — because no human holds it, because it must be requested and time-boxed before use — the four-minute sweep cannot happen. The attacker would have to either compromise the elevation system itself (a much harder target with its own audit trail) or wait for a legitimate elevation window and hope to use the same window. Both options give the defender minutes to hours of additional time. Neither relies on the SOC noticing in four minutes.

This is the architectural shift CISA's Secure-by-Design Pledge points at. The cloud platforms have the primitives. JIT elevation, default-deny RBAC, least privilege defaults — all documented, all available, all unevenly deployed. The Pledge commits signatory vendors to making those defaults easy. Avatier is a CISA Secure-by-Design Pledge signatory; Identity Anywhere aligns with CISA's published guidance on phishing-resistant MFA, and the platform's governance modules are built on the architectural assumption that standing privilege is the wrong default. The CISA framing is not marketing language. It is the policy direction the federal government is using to set procurement expectations across the security industry.

What CISA's Secure-by-Design Pledge means in this context

The Secure-by-Design Pledge is a voluntary commitment by software manufacturers to publish progress against seven security commitments — among them, default-on MFA, default-deny configurations, transparent vulnerability disclosure, and continuous public reporting. The Pledge is not a compliance attestation. It is a published commitment to security-first product design.

For breaches like Storm-2949, the Pledge framing matters because it shifts the conversation from "what additional product can the customer buy" to "what should the platform have made the default." A platform that defaults to standing privilege, that defaults to opt-in audit-log ingestion, that defaults to long-lived service-principal credentials — is a platform asking the customer to do the work the platform should have done. The Pledge is the public commitment by signatory vendors not to keep asking that.

Avatier is a signatory. Our Trust Center publishes the full posture — SOC 2 Type II audited with zero exceptions noted, ISO/IEC 27001:2022, PCI DSS v4.0.1, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned, NIST CSF, NIST AI RMF — and the Pledge commitment is part of how we evaluate product decisions. We mention this not as credentialing but because the policy conversation the Pledge anchors is the one Storm-2949 should accelerate across the identity-platform category.

The structural correction

Identity governance is not a product category that the breach press talks about during a fresh incident. It is the discipline most enterprises file under "compliance" — quarterly attestation campaigns, year-end recertification reviews, audit-window-driven recordkeeping. That filing is wrong. Identity governance is a real-time control. The attestation that should have caught the Storm-2949 authenticator-registration drift was not a quarterly campaign; it was an alert that fired on the directory change inside the same minute it occurred.

The structural correction is to treat identity governance as a control layer with the same expectations of latency, coverage, and operational maturity that we already apply to endpoint detection or network monitoring. That means continuous attestation rather than periodic. It means joiner/mover/leaver workflows that propagate changes within minutes across every identity-bearing system, not within nightly batch jobs. It means service-principal lifecycle as a managed program with named owners, not as a directory artifact. It means standing zero privilege as the default and just-in-time elevation as the only path to administrator-grade access. And it means the dashboards that watch identity behavior across the workload graph being staffed during business hours, not consulted during incident response.

We will get more Storm-2949s. The next one will use a different door. The platforms will catch up over multi-year roadmaps. The customers who survive the gap are the ones who treat identity governance as a real-time, well-instrumented control layer today, while the platforms catch up. That is the discipline this site exists to write about. We will keep writing.

Frequently asked questions

What is Storm-2949?

Microsoft's tracking designation for the threat actor behind the May 18, 2026 cloud-wide breach disclosure. The campaign progressed from a single SSPR-abused identity to Microsoft 365 exfiltration, Azure RBAC manipulation, Key Vault secret harvest, SQL data theft, and VM compromise — all without conventional malware.

How did Storm-2949 bypass MFA?

Not by bypassing it — by inducing the legitimate user to approve a fraudulent MFA prompt during a Self-Service Password Reset (SSPR) flow that the attacker had initiated. Once approved, the attacker reset the password, removed the existing authentication methods, and registered their own Microsoft Authenticator on their own device. From that point, the legitimate user was locked out and the attacker held compliant MFA.

What is service-principal hygiene?

Service-principal hygiene is the governance discipline around non-human identities — application identities and managed identities in cloud platforms. It includes scheduled credential rotation, ownership attestation, periodic permission recertification, and decommissioning when applications retire. Storm-2949 attempted to inject credentials into a compromised service principal and only failed because the principal lacked sufficient permissions, not because anyone was monitoring service-principal credential changes.

What is Just-In-Time (JIT) RBAC?

JIT RBAC removes standing privileged role assignments. Instead of a user permanently holding the Owner role over a Key Vault, the user requests elevation for a specific task, receives time-limited approval, and access auto-expires. Microsoft Entra calls this Privileged Identity Management (PIM). It directly mitigates the four-minute Key Vault sweep Storm-2949 performed.

Why didn't Microsoft's published mitigations catch Storm-2949?

Microsoft's mitigations are correct. Most affected tenants had not deployed them. Conditional Access requiring device compliance, phishing-resistant authentication strength for administrators, Key Vault private endpoints, App Service legacy-auth disabling, and audit logging of RBAC changes are all documented. The Storm-2949 breach was not a Microsoft control failure — it was a customer deployment failure.

Would phishing-resistant MFA alone have prevented Storm-2949?

Phishing-resistant MFA — FIDO2, WebAuthn, certificate-based — would have prevented the initial-access step. It would not have prevented the four-minute Key Vault sweep, the SQL firewall manipulation, or the Storage SAS-token harvest if the attacker had reached those control planes another way (through a compromised service-principal credential or a misconfigured CI/CD pipeline). Identity governance is the layer that catches the exploitation once an attacker is inside.

What does CISA's Secure-by-Design Pledge commit a vendor to?

The pledge is a voluntary commitment by software manufacturers to ship products with secure defaults — MFA enabled by default, default-deny configurations, vulnerability transparency, and progress reporting. Avatier is a signatory. The pledge is not a compliance attestation; it is a published commitment to security-first product design that aligns with what regulators and federal customers increasingly require.

What is the difference between identity governance and identity access management (IAM)?

IAM controls who has access. Identity governance controls whether that access is appropriate over time — who reviewed it, who attested to it, when it expires, what triggers recertification. Storm-2949 succeeded because IAM was working as designed (the compromised users genuinely had the access they used), and governance was not watching (nobody attested the privileged Azure RBAC assignments before the breach, and nobody caught the authenticator-method changes after).