What happened
On 11 July 2023, Microsoft disclosed that a China-based group it tracks as Storm-0558 had used forged authentication tokens to read email at approximately 25 organisations in the public cloud, including government agencies, beginning around 15 May 2023. The tokens were forged using an acquired Microsoft account consumer signing key. Microsoft said it blocked the forged tokens, replaced the key and updated its validation libraries.
Two months later, Microsoft published a technical account of how the key was acquired. A consumer signing system had crashed in April 2021, and the resulting crash dump contained the key because of a race condition that should not have let that happen. The dump moved from an isolated production network into a debugging environment on Microsoft's internet-connected corporate network. Storm-0558 then compromised a Microsoft engineer's corporate account that had access to that environment, which Microsoft called the most probable route by which the key was taken. A separate flaw, a missing scope check in a signature-validation library, let a key meant only for consumer accounts also sign tokens for enterprise mailboxes.
In April 2024, the government's Cyber Safety Review Board published its review. A Department of Homeland Security release summarising the report said the board found Microsoft had deprioritised enterprise security investment and risk management relative to its central role in the technology ecosystem, and it issued recommendations grouped into six areas, from cloud identity practices to victim notification.
Confidence and limits
The forgery mechanism and the government-mailbox impact rest on Microsoft's own investigation, corroborated by an independent government review board that had access beyond what Microsoft published. The review board's characterisation of Microsoft's security culture is the board's assessment, not a judicial finding, and this record does not establish a complete list of every mailbox or document read.
Why it mattered
The incident showed that a single cryptographic key error, dormant for two years inside routine crash-reporting infrastructure, could eventually cross the boundary between a consumer product and government enterprise email. It also showed that a cloud provider's internal engineering failures, not only its customers' misconfigurations, can be the direct cause of a government breach.
Defensive takeaway
If your organisation depends on a cloud identity provider, ask how that provider isolates crash diagnostics and debugging data from production signing material, and confirm you would be notified quickly if a provider-side key were ever revoked or rotated unexpectedly.
- Would your organisation know if a cloud provider revoked and replaced a signing key that your authentication depends on?
- Do your vendor contracts specify how quickly you would be told about token-forgery or key-compromise incidents affecting your tenant?
- Can you distinguish, in your own logs, a token issued through normal sign-in from one that arrived through a federated or delegated trust relationship?
The review board's findings do not resolve every open question about the intrusion, but they establish that a key's origin and handling matter as much as its cryptographic strength, and that customers of cloud identity systems have limited visibility into either.