Blog

The last post was the disaster. Four failures, perfectly stacked, with a peer comparison that was basically a public roasting.
This one’s the redemption arc. And honestly? It’s the most technically interesting post in the series so far, because when Microsoft finally got to work, they went further than fixing the minimum. They went several layers deeper than anyone expected.

---

Quick recap if you’re just joining. A Chinese threat actor used a forgotten 2016 signing key to forge authentication tokens, walked into 22 organizations’ Exchange Online mailboxes, stayed for six weeks, and Microsoft had no idea until a government agency called them. The four failures that made it possible were keys in software storage, no automated rotation, a broken trust boundary between consumer and enterprise identity, and zero forged-token detection.

This post is about the fix. Specifically, the identity and key management rebuild, which is genuinely the most fascinating part of the whole Secure Future Initiative.
The story is not just “Microsoft put keys in an HSM.” It’s a progressively deeper set of protections, each one closing an attack vector the previous layer still leaves open. That kind of architectural thinking is worth understanding, regardless of whether you run anything at Microsoft’s scale.

Four Layers, Each One Assuming the Last Can Fail

By November 2025, across three progress reports, Microsoft had added four distinct layers of defense where there were previously none. Each layer assumes the one before it can fail. That’s the right way to think about this. And it’s the first time in this whole story where I’d say Microsoft’s thinking was genuinely ahead of the minimum required fix.

Each layer assumes the previous one can fail. That’s not a nice-to-have. That’s the only design philosophy that actually holds up when someone smart is trying to break it.

Layer 1: Hardware Security Modules

The first and most fundamental fix was moving signing keys off software-managed storage and into Hardware Security Modules. An HSM is a dedicated piece of hardware, physically tamper-resistant, designed to hold cryptographic material and perform operations without ever exposing the key itself. You send data in, you get signed data back. The key never leaves the chip.

By the September 2024 progress report, Microsoft had completed HSM-based storage for Entra ID and MSA access token signing keys across public cloud and US government clouds. ADFS token signing keys moved to HSMs across all environments too. Automated rotation landed at the same time, which meant that keys now rotate on a schedule with no human in the loop. No more forgotten retirement dates. No more “a manual rotation caused an outage so we just stopped” as an excuse.
The thing that should’ve been done years ago finally happened.

But here’s the thing a lot of post-incident coverage missed. Putting a key in an HSM does not mean the service using that key is safe. The signing service itself, the process that calls the HSM and produces tokens, still runs on a host.
If that host is compromised, an attacker can abuse the signing service directly without ever touching the key material.
The HSM protects the key. It doesn’t protect the signing operation. Microsoft clearly understood this, because the next layer addresses exactly that gap.

Layer 2: Confidential Computing

By the April 2025 report, Microsoft had migrated the MSA signing service to run on Azure Confidential VMs, with the Entra ID signing service migration well underway.

Azure Confidential Compute uses hardware-enforced isolation built into the processor itself to encrypt a VM’s memory even from the underlying host and the hypervisor. Even if someone compromises the physical server or the cloud management plane, they can’t read what’s happening inside the confidential VM. The workload is cryptographically isolated at the hardware level. If you’ve ever had to explain to a compliance auditor why “the cloud provider can theoretically read our stuff” isn’t a deal-breaker, this is the technology that actually kills that conversation dead.

By the November 2025 report, 95% of Entra ID signing VMs had migrated to Azure Confidential Compute. Microsoft described this as the largest confidential compute workload in Azure. Think about that for a second. They’re now protecting their signing infrastructure from their own servers. That’s the kind of paranoia you want from the company running your identity platform.

They also ran Red Team exercises specifically to validate these improvements, confirming that improved auditing telemetry and reduced key validity periods made attacks significantly easier to detect and investigate. They didn’t just deploy it and hope for the best. They actively tried to break it. That shouldn’t be noteworthy, but given where this story started, it is.

Now an attacker needs to compromise both layers simultaneously. The HSM holds the key and won’t release it. The signing service runs in a cryptographically isolated environment the host can’t read. That’s a meaningfully harder problem than “find the key in software storage.”

They Also Designed Their Own Chip

Small detour, but worth it. Traditional cloud HSM services are centralized network resources. When a workload needs to use its key, it either makes a network round-trip to the HSM cluster with the latency that brings, or requests the key be released locally, which is weaker protection because the key leaves the hardware boundary. You’re constantly trading performance against security. It’s one of those architectural compromises everyone learns to live with.

Microsoft’s answer was to design their own chip. Not to configure a vendor appliance, but actually design silicon, from scratch, for this specific problem. The Azure Integrated HSM is a custom ASIC that sits directly on the server. Cryptographic operations happen locally. The key physically cannot leave the chip. It’s tamper-resistant, not just tamper-evident. Physically probe it and the keys get nuked from orbit. It’s the only way to be sure.

And Microsoft is putting one in every new Azure server going forward. This is not a fix deployed to affected systems. It’s a design doctrine baked into the hardware itself.
That’s not a patch. That’s a generational infrastructure decision.

Layer 3: Key Partitioning

Even with HSMs and confidential VMs, there’s still a blast radius problem. If a single signing key covers the entire identity infrastructure and someone compromises it, the damage is total. Every service trusting tokens signed by that key is exposed. You haven’t reduced the risk. You’ve concentrated it. One key to rule them all, and not in a fun way.

The answer is partitioning. Split the signing keys so different parts of the infrastructure use different keys, and a compromise of one can’t pivot into higher-privilege management layers.
As of the November 2025 report, Microsoft completed its first milestone for key partitioning within the Entra ID infrastructure. The report describes it as reducing “blast radius so that compromised keys cannot enable traversal into higher-privilege management layers within the infrastructure.”
First milestone, though. Full compartmentalization is still ahead.
A key that can’t pivot into management layers beats one that can. That’s progress. Partial, carefully-worded progress, but progress.

Layer 4: Stateful Token Validation and Forged Token Detection

The last layer is detection. Even with hardware-protected keys and isolated signing services, you want to catch it if something goes wrong. Stateful token validation means the server checks not just whether a token is cryptographically valid, but whether it’s consistent with the known state of the session.
A token minted at an unusual time, or for a service the user hasn’t actually authenticated to, gets flagged.

By November 2025, Microsoft had deployed forged token detection and stateful validation across their most critical services, including Exchange Online and SharePoint Online, the two products at the center of the original breach.
Rapid access revocation was expanded too. If credentials are compromised, they can be killed across key management, identity, and collaboration services in one move. Which only works if you have the detection layer in the first place. Funny how that connects.

This is the layer that was entirely missing in 2023. It wouldn’t have prevented Storm-0558 on its own, but it would have caught it a lot faster than “a customer spotted something weird in premium-tier logs six weeks later.”
Which, to be clear, is how that actually went down.

The SDK Problem Was Just as Bad

Here’s the part that gets almost no coverage. Not because it’s boring, but because “authentication library fragmentation” doesn’t make for great headlines. The authentication libraries themselves were a parallel problem, and arguably just as exploitable.

Different services across the Microsoft stack had each written their own token validation logic instead of using a single shared library. One team checks key type, another doesn’t. One validates issuer strictly, another trusts whatever the shared endpoint says. Each choice seemed reasonable in isolation. Stacked across dozens of services over twenty years, they created a patchwork of slightly different assumptions about what a valid token looks like. Attackers look for exactly that kind of inconsistency.

The solution was to replace all of that with a single hardened identity SDK that every service uses, with consistent validation logic enforced in one place.

Microsoft measured adoption as a percentage across each report. September 2024: 73%. April 2025: 90%. November 2025: 94.3%.

That last number is more interesting than it looks, because Microsoft quietly expanded the denominator between the April and November reports to include Microsoft Account tokens and internal platform identity systems on top of the Entra ID tokens they were already counting. Bigger scope, same percentage. They didn’t shrink the measurement to make progress look easier. That’s worth noting, because keeping the denominator small to protect a headline number is exactly what most progress reports do.

What the Stack Actually Looks Like Now

Here’s what the full stack looks like as of November 2025.

• Signing keys in HSMs, rotating automatically with no human in the loop
• Signing services running in Azure Confidential VMs, isolated even from the underlying host
• New Azure servers shipping with integrated HSM chips so cryptographic operations never leave the silicon
• Keys partitioned so a compromise of one can’t cascade across the full infrastructure
• 94.3% of tokens validated by a single hardened SDK
• Stateful validation and forged token detection across Exchange Online, SharePoint, and other critical services

Alright, Enough Nice Things

The architecture is sound and the direction is right. But a redemption arc isn’t complete until you’ve checked the fine print, as progress reports are designed to show progress. Sometimes you have to read between the carefully chosen lines.

Key partitioning is at “first milestone.” That is not ‘it’s completed’ language. The foundational work separating Entra ID infrastructure layers is complete, but full compartmentalization across all infrastructure layers is still ahead. The November 2025 report says they’re “laying the foundation for future compartmentalization across additional infrastructure layers.” If you’ve read enough enterprise progress reports, you know what that means. It means there’s a lot of work left.

The SDK is at 94.3%. The remaining 5.7% presumably includes services that are harder to migrate due to legacy architecture or third-party dependencies. It’ll get there. It’s not there yet though.
And in security, the last 5% is where the interesting attack surface lives.

The quantum-safe program is a separate, forward-looking workstream rather than Storm-0558 remediation, but worth a quick mention. Microsoft has started shipping post-quantum cryptography across their server, desktop, and developer platforms, with certificate services support following shortly after. Right timeline for where the industry is. Worth tracking. Not worth panicking about yet.

The Architecture Lesson

If you run an identity platform, or work on one, or are responsible for one, the Microsoft playbook here is definitely worth studying. Not because you need confidential compute infrastructure at Azure’s scale, but because the threat model applies to anyone who issues authentication tokens. And here’s the uncomfortable version of that statement. Most organizations can’t properly answer these questions yet.

• Where are your signing keys stored? Hardware or software-managed storage?
• Do your keys rotate automatically, or does someone have to remember to do it?
• If a key was extracted from your environment today, how long before you’d know?
• Can a token from one trust domain authenticate against resources in another?
• Do you have a single consistent validation implementation across your stack, or have different teams made slightly different choices?

Microsoft couldn’t answer them either, until 2023 made it very expensive for them not to. The difference now is that Microsoft has a documented, tested, layered answer for each of them.
Each layer assumes the previous one can fail. That’s what defense in depth actually looks like when you do it properly.
One very expensive lesson, now available for everyone else to read for free.

---

This is a rolling series. New posts drop over the coming weeks.

• 1. Microsoft’s Security Wake-Up Call (And Why It’s Yours Too)
  The Storm-0558 incident, the CSRB findings, and how a forgotten key put cloud accountability on trial.
• 2. Four Failures, Zero Excuses
  The specific architectural problems that made Storm-0558 possible, and why Microsoft’s peers had already solved them.
• 3. Four Layers, No Shortcuts
  How Microsoft rebuilt its token signing infrastructure from scratch, and what defense in depth actually looks like when you do it properly. (You are here.)
• 4. Six Million Ghosts in the Shell
  6.9 million inactive tenants, 1.2 million unused apps killed, and 3,000+ privilege escalation paths closed. (Up next.)

More to follow.

Questions, corrections, or pushback welcome. Especially if you work in identity and think I’ve oversimplified the confidential compute story. Drop a comment.

A forgotten 2016 signing key. No automated rotation. A shared authentication endpoint that crossed trust boundaries nobody bothered to enforce. And zero capability to detect any of it.
Before we talk about the fix, we need to talk about just how bad the starting position actually was.

---

Welcome back. In the last post we covered Storm-0558 and why the CSRB was so scathing about it.

Quick recap if you’re just joining. A Chinese threat actor used a forgotten 2016 signing key to forge authentication tokens, walked into 22 organizations’ Exchange Online mailboxes, stayed for six weeks, and Microsoft had no idea until a government agency called them.

The root cause of how the key was stolen remains officially unknown to this day.

This post is about the specific failures that made it possible. Not the vague hand-waving version. The actual, specific, architectural problems, one by one. Because “bad key management” covers a lot of ground and it’s easy to wave at it without understanding what was really going on.
There were four failures. And they stacked on top of each other beautifully. If you were designing a worst-case scenario for a cloud identity provider, you’d struggle to do better.

Failure 1: Keys in Software Storage

Microsoft’s token signing keys for Entra ID and the Microsoft Account service were not stored in hardware. They lived in software-managed storage, which means a sufficiently privileged attacker who could reach that storage could extract the key material.

That appears to be exactly what happened, though the precise method remains unconfirmed. What the CSRB found is that Storm-0558 had compromised an engineer’s device at a company called Affirmed Networks, a 5G tech startup that Microsoft acquired in April 2020.
The important detail is that the compromise happened before the acquisition closed. When Microsoft welcomed the Affirmed Networks team in, they handed corporate credentials to a device Storm-0558 had already been sitting on. Microsoft failed to assess the security posture of the devices it was onboarding. So it didn’t just inherit a company. It inherited an active intrusion.

The attackers used that foothold between April and August 2021 to access Microsoft’s corporate network and search SharePoint specifically for documentation on Azure service management and identity systems. That was the groundwork laid two years before the 2023 intrusion. Patient, targeted, and entirely undetected.

Failure 2: Nobody Was Rotating the Keys

There was no automated rotation. Keys rotated manually, and the 2016 MSA key was supposed to be retired in March 2021.
Here’s the specific reason it wasn’t. In 2021, a manual key rotation caused a major cloud outage. Microsoft’s response was not to fix or automate the rotation process.
They paused manual rotations entirely and put no alerting in place to flag that keys were aging. The 2016 key sat there, forgotten and live, for two more years.

A seven-year-old signing key in production with nobody watching it. The decision to stop rotating was bad. The fact that nobody noticed for two years was worse. The fact that there was no system to even flag it was the thing that should keep a CISO up at night.

Failure 3: Broken Trust Boundaries

Someone at Microsoft once had the idea to make authentication simpler for developers. They created a shared OpenID Connect (OIDC) discovery endpoint that listed signing keys for both the consumer Microsoft Account service and the enterprise identity system in one place. A convenience feature. Reasonable enough on its face.
The problem is that the SDKs were never updated to enforce the trust boundary that endpoint violated. Consumer MSA and enterprise Entra ID are supposed to be completely separate systems. A key from one should not be able to do anything in the other. But because the SDKs just trusted whatever the shared endpoint listed, that boundary didn’t exist in practice.

So when Exchange Online received a token signed with the 2016 consumer key, the validation logic accepted it as legitimate. Two entirely separate systems, made cross-compatible by a feature request that created a hole nobody went back to close. That’s not a subtle architectural flaw. That’s a fundamental failure of separation between two systems that were never supposed to share keys, left sitting open for years.

The plumbing wasn’t just inconsistent.
It was broken at the foundation, and had been for a long time.

Failure 4: No Way to Catch It

Once a forged token was in flight, there was nothing to catch it. The token looked legitimate because it was signed with a real key. Microsoft had no forged-token detection whatsoever. No stateful checks, no anomaly detection, nothing. A perfectly forged token was indistinguishable from a real one.

This is ultimately why Storm-0558 stayed undetected for six weeks. Not just because they were good. Because Microsoft had built no mechanism to catch them even if they had been obvious about it.

• Keys in software storage.
• No automated rotation because a previous rotation caused an outage, so they just stopped.
• A shared OIDC endpoint that made consumer keys valid for enterprise services, never enforced.
• No forged-token detection, so abuse was invisible once a token was minted.

The Part That Should Really Sting

Here’s the part that should make you put your coffee down.
These weren’t exotic attack vectors nobody had thought of.
They weren’t zero-days. They were gaps in basic controls that Microsoft’s peers had already closed, and the reason those peers closed them is worth saying out loud.

Google got hit by the same group in Operation Aurora back in 2009 and immediately hardened their token infrastructure, moving to stateful tokens with unique IDs, automated key rotation, and hardware-backed authentication.
AWS built request-level signing so that every API call is cryptographically tied to exactly what it authorizes.
Oracle gave each customer tenancy its own key pair.
AWS and Oracle drew the same conclusions without even needing to get hit. Microsoft, unlike its peers, essentially twiddled their thumbs and waited fourteen years for their own Operation Aurora.

The Board’s assessment of security practices at other cloud service providers, which maintained security controls that Microsoft did not.

The CSRB didn’t tuck that away in a footnote. It’s Finding #3. Named. Documented. Compared. That sentence doesn’t need interpretation. It’s the board saying, politely, that Microsoft’s peers got the memo fourteen years ago and Microsoft filed it under “definitely, maybe later.”

So that’s the before picture.
Keys in software.
No rotation.
A trust boundary violated by a feature request and never fixed.
No detection.
And a peer comparison that was, to put it diplomatically, not flattering.

The next post is about the fix. And to Microsoft’s credit, when they actually got to work on it, they didn’t just patch the minimum. They built something worth understanding.

In This Series

• 1. Microsoft’s Security Wake-Up Call (And Why It’s Yours Too)
  The Storm-0558 incident, the CSRB findings, and how a forgotten key put cloud accountability on trial.
• 2. Four Failures, Zero Excuses
  The specific architectural problems that made Storm-0558 possible, and why Microsoft’s peers had already solved them. (You are here.)
• 3. Four Layers, No Shortcuts
  How Microsoft rebuilt its token signing infrastructure from scratch, and what defense in depth actually looks like when you do it properly. (Up next.)

More to follow.

Questions or pushback welcome. Drop a comment.

A stolen key from 2016. A known Chinese threat actor with a 20-year track record. 500+ compromised accounts. And a government agency that had to call Microsoft to tell them they’d been hacked.
This is where it started.

---

Alright, let’s talk about one of the most embarrassing and frankly fascinating security incidents in recent memory. Not because it involved some crazy zero-day or an impossibly sophisticated attack chain. But because it was, at its core, a story of basic things done badly over the course of a very long time, by a company that had every reason to know better.

This is the first post in a series on Microsoft’s Secure Future Initiative (SFI). We’re going to begin from the incident that started it all, through three years of progress reports, in order to figure out what actually changed. The crucial questions that remain are: what is still smoke and mirrors, and what can the rest of us learn from it?
I’m a security architect, not a journalist. So fair warning, these posts will dig deeply into the actual technical decisions and the places where the progress reports gloss over issues that still need work.

But first, let’s go back to where it all began.

The Actor: Not Exactly a Surprise

Before we get to 2023, there’s some important context that most coverage skips. The group Microsoft calls Storm-0558, assessed to be operating on behalf of the People’s Republic of China, is not some newly discovered threat. Security researchers have been tracking this group for over 20 years.

They were linked to Operation Aurora in 2009, a sophisticated campaign that targeted more than two dozen companies including Google, to steal source code and access email accounts. Two years later, in 2011, they were connected to the RSA SecurID breach, during which attackers stole the secret seeds used to generate authentication codes for tokens used by tens of millions of people. If you were in security in 2011, you remember that one.

The reason that this context matters is simple, but important. Microsoft was not blindsided by an unknown actor using tactics nobody had seen before. This was a group with a documented, two decade-long interest in stealing authentication keys and credentials from technology companies. The attack succeeded not because Storm-0558 invented something new, but because the controls that should have been in place simply weren’t.

Summer 2023: What Actually Happened

May and June 2023. Storm-0558 quietly walked into the Exchange Online mailboxes of 22 organizations and over 500 individuals. Commerce Secretary Gina Raimondo. The US Ambassador to China. A congressman. And a whole lot of other people who really, really did not want their emails read by Beijing. The State Department alone lost around 60,000 emails. The attackers had access for at least six weeks before anyone noticed.

No zero-day. No exotic attack chain. The hackers found a 2016 Microsoft Account (MSA) consumer signing key and used it to forge authentication tokens that looked completely legitimate. That key should have been retired in March 2021. It wasn’t.

A second flaw in Microsoft’s token validation meant that a consumer key could authenticate to enterprise Exchange accounts, two trust domains that should architecturally never cross. The next post goes deep into exactly how that worked.
For now, the important thing to remember is simple. A seven-year-old forgotten key plus a gap in the authentication plumbing is what let attackers walk straight in.

22 organizations. 500+ individuals. 60,000 State Department emails. Six weeks of undetected access. One signing key from 2016 that should have been dead in 2021.

Microsoft Didn’t Find It. A Customer Did.

On June 15, 2023, the State Department found the intrusion themselves. Their security team had built a custom detection rule nicknamed “Big Yellow Taxi” that flagged anomalous access patterns in a log called MailItemsAccessed, which tracks who exactly is reading Exchange Online mailboxes. That rule managed to catch what Microsoft’s own systems missed entirely.

Here’s the part that makes it worse. That log was only available because the State Department had paid for Microsoft’s premium G5 government license tier. Standard license customers couldn’t see it at all. Most enterprises and government agencies didn’t have E5 or G5. They had no visibility into this class of activity within their own environments. You could have been compromised and wouldn’t have the slightest idea.
Security logging sold as a premium feature is not true security.
It’s a liability waiting to happen. The CSRB called this out explicitly.
A future post covers what Microsoft did about it, eventually.

The Transparency Problem

Nine days after it was spotted by the State Department, Microsoft revoked the stolen signing key. July 11th they published a public blog. Then on September 6th, they published a root cause analysis explaining that the key had probably ended up in a crash dump file accidentally accessed by a compromised engineer’s machine.

One problem though. It wasn’t true.
Microsoft acknowledged to the CSRB in November 2023 that they had no evidence or logs supporting this claim. They didn’t update the public blog until March 12th, 2024, four months later, when the CSRB was finishing up its review and had repeatedly asked them about it.

So to recap: a customer told Microsoft they’d been breached, Microsoft published an incorrect explanation of events that had taken place, knew this was incorrect for months, and decided to sit on it anyway. As of the CSRB’s final report, how the key was actually stolen remains officially unknown. That’s not a reassuring or comforting sentence for the world’s largest software company and its most critical cryptographic material. But it’s the accurate one.

Then It Got Worse

January 2024. While Storm-0558 was still being investigated, Microsoft disclosed an unrelated intrusion. Midnight Blizzard, Russia’s SVR, used a password spray attack against a legacy test account with no MFA and pivoted into senior leadership email accounts and source code repositories.

Two separate nation-state intrusions, six months apart, at the world’s largest software company. One from China. One from Russia. Both preventable.

And Microsoft’s public response to the Midnight Blizzard breach? They published a blog post recommending customers buy Entra ID Protection, Purview Audit Premium, and Entra Password Protection as the fix. For a breach of Microsoft’s own infrastructure. Security researcher Alex Stamos nominated it to what he called the “Cybersecurity Chutzpah Hall of Fame.” That’s probably the most polite thing anyone said about it.

The Gates Memo

In 2002, Bill Gates wrote a company-wide memo called Trustworthy Computing. The key message was simple. “When we face a choice between adding features and resolving security issues, we need to choose security.” The CSRB specifically invoked that memo in their 2024 findings. Not as a rhetorical flourish. As a direct and challenging question asking what happened to the ethos its founder put in writing twenty years ago.

Their conclusion was that Microsoft’s security culture had drifted so badly that basic controls that other cloud providers had already shipped, such as automated key rotation, hardware-based key storage and stateful token validation, simply weren’t there.
The CSRB didn’t just say Microsoft had failed technically.
They said Microsoft had failed institutionally.

A future post covers what Microsoft did to try to fix its culture.
It’s more interesting than it sounds.

The CSRB Does Not Hold Back

In March 2024, the Cyber Safety Review Board published its full review. It is one of the most high profile and strongly worded public takedowns of a major tech company’s security practices I have ever read. The kind of report where you can truly feel the frustration behind the formal language.

Their headline conclusion was that “This intrusion was preventable and should never have occurred.”
And that “Microsoft’s security culture was inadequate and requires an overhaul.”

It wasn’t one mistake. It was a cascade. Microsoft failed to detect the compromise of its own cryptographic keys. Other cloud providers had controls in place that Microsoft simply didn’t have. The company left inaccurate public statements uncorrected for months while actively being aware that they were wrong.
And they were so far behind their peers on basic security hygiene that the CSRB felt the need to spell it out plainly.
For a company this central to global enterprise infrastructure, their standards were unacceptable.
That’s not a compliment dressed up as criticism.
That’s a government board saying you are too important to run security like a startup in 2010.

By the numbers

• 22 organizations compromised
• 500+ individuals
• ~60,000 State Department emails exfiltrated
• At least six weeks of undetected access
• A signing key from 2016 that should have been retired in 2021
• A root cause that remains officially unknown
• Four months of inaccurate public statements left uncorrected after Microsoft knew they were wrong
• 25 CSRB recommendations
• One very uncomfortable Microsoft board meeting, probably

What Came Next

In November 2023, before the CSRB had even published its report, Microsoft announced the Secure Future Initiative. Then in May 2024, Satya Nadella publicly tied security to leadership compensation and made it the company’s stated top priority.
The equivalent of 34,000 full-time engineers was redirected towards this effort. Six pillars, 28 objectives, and a commitment to publish regular progress reports.

Three reports have been published so far: September 2024, April 2025, and November 2025. That’s what this series digs into, one pillar at a time, with the actual numbers rather than the press release version.

This is a rolling series. New posts will drop over the coming weeks.

• 1. Microsoft’s Security Wake-Up Call (And Why It’s Yours Too)
  The Storm-0558 incident, the CSRB findings, and how a forgotten key put cloud accountability on trial. (You are here.)
• Four Failures, Zero Excuses
  The specific architectural problems that made Storm-0558 possible, and why Microsoft’s peers had already solved them. (You are here.)

More to follow.

Questions, corrections, or strong opinions welcome. These posts exist because this story deserves more than a press release summary.