Parag Mali - tag: secure-future-initiative

The Layer Above the OS: The Windows Security Wars Part 6 (2023-2026)

noreply@paragmali.com (Parag Mali) — Sat, 30 May 2026 00:00:00 GMT

**Three failures. Three soft layers. One era.** Between 2023 and 2026, Microsoft publicly admitted that the largest attack surface on a modern Windows machine is no longer the OS itself -- it is the third-party kernel-mode security vendor, the institution's own identity-token custody, and the AI feature plane sitting on top of both.

Storm-0558 forged enterprise Exchange tokens with a 2016 consumer signing key. CrowdStrike's July 19, 2024 outage bricked roughly 8.5 million Windows hosts in ninety minutes -- no attacker, no exploit, just twenty bytes of bad data in a sanctioned kernel driver. The Recall saga proved that VBS, TPM, and DPAPI do not know how to enforce policy on what an AI agent decides to do next.

Microsoft's reply is the Secure Future Initiative, the Windows Endpoint Security Platform, and the April 14, 2026 Cross-Signing trust deprecation -- the first sustained engineering re-architecture of all three soft spots in parallel. Whether the response lands before the 2026 ransomware wave is the open forward question.

1. Twenty Bytes at 04:09 UTC

At 04:09 UTC on July 19, 2024, a CrowdStrike Falcon sensor running on roughly 8.5 million Windows hosts pulled a routine Rapid Response Content update [@ms-weston-jul20-2024] -- Channel File 291, twenty-one input fields where the in-kernel Content Interpreter expected twenty, the twenty-first treated as an address the kernel was never meant to follow [@crowdstrike-rca-pdf] -- and the world's airline desks, hospital admissions systems, and emergency dispatch terminals began the bluest morning in the history of the NT kernel. No attacker was involved. No exploit ran. A non-malicious data-parsing defect inside a sanctioned, signed, kernel-mode third-party security driver took down a sovereign country's flight network in ninety minutes [@ms-jul27-2024-security-tools] because the operating system, twenty-five years earlier, had agreed to let security vendors run there [@theregister-2006-vista].

Three months before that morning, the United States Cyber Safety Review Board had published a different verdict on a different vendor failure. Its review of the summer 2023 Microsoft Exchange Online intrusion -- the Storm-0558 episode in which a Chinese threat actor forged Outlook tokens against enterprise Exchange Online using a 2016 consumer-tier Microsoft Account signing key -- concluded that the breach was "preventable and should never have occurred" and that "Microsoft's security culture was inadequate and requires an overhaul" [@csrb-2024]. The CSRB had only reviewed two prior incidents [@dhs-press-2024]; the third reviewed company was the steward of the world's most widely deployed operating system.

Ten weeks after the Storm-0558 verdict, on June 13, 2024, Microsoft's group product manager for Windows quietly added an in-place editor's note to a blog post he had published six days earlier. The note pulled the company's flagship Copilot+ PC AI feature, Recall, from a planned ship date of June 18, 2024 -- five days before launch -- and shifted it to the Windows Insider Program [@recall-davuluri-jun7-2024].

Note: This is the sixth installment of The Windows Security Wars. Earlier parts walked BitLocker, Credential Guard, VBS, Pluton, and the Defender-and-WDAC arc that produced the modern Windows security baseline. This part picks up where Part 5 left off and argues that the era's actual story is what happens above that baseline.

Three failures, three soft layers, one era -- and the 2023-2026 chapter is the first in NT's history in which the layer above the OS (the institution's own identity-token custody, the third-party kernel-mode security vendor, and the AI feature application plane) became the load-bearing security boundary under public scrutiny while the OS layer itself kept hardening. David Weston's July 20, 2024 post framed the 8.5 million figure as "less than one percent of all Windows machines" [@ms-weston-jul20-2024]. The number itself is sourced from Windows Error Reporting crash dumps and customer telemetry, so machines stuck in a boot loop with no network or with WER disabled are not counted; treat it as a credible lower bound rather than a full census [@wiki-crowdstrike-outage]. The framing is correct and worth holding onto: this is a story about which 1% mattered, not about the platform's defect rate. To see why that is an architectural inflection rather than a coincidence of three bad years, we have to walk the prior arcs the three events belong to.

2. Three Lineages Converging

The era did not begin in June 2023. Three long-running arcs converged on the 2023-2026 chapter, and each event in the opening is the latest generation of one of them.

Lineage 1: Identity-authority forgery

The first lineage is the oldest. In 1997, a researcher known as Hobbit, distributing through the Avian Research mailing list, documented that Windows CIFS authentication could be replayed with the password hash rather than the password itself. Microsoft's own Mitigating Pass-the-Hash and Other Credential Theft whitepaper, in its 2014 second edition, treats the Hobbit observation as the foundational primitive for the entire credential-theft family [@ms-pth-whitepaper]. In 2014, Benjamin Delpy stood up at Black Hat USA and demonstrated that the Active Directory KRBTGT account's long-lived signing key, once stolen, let an attacker mint Kerberos tickets for any user, including domain administrators -- the "Golden Ticket" attack, packaged into the mimikatz toolchain [@delpy-bh-slides] [@mimikatz-github]. In 2017, CyberArk's Shaked Reiner extended the same idea to SAML identity providers: steal the IdP's signing certificate and mint cross-application tokens at will [@cyberark-golden-saml]. In December 2020, FireEye and Microsoft together disclosed that a sophisticated nation-state actor had compromised the upstream SolarWinds build process and minted trusted certificates with that compromise [@mandiant-fireeye] [@msrc-solarwinds-2020].

In June 2023, Storm-0558 widened the trust domain again. The forged tokens were signed by a consumer-tier Microsoft Account key issued in April 2016 [@wiz-storm0558], but the tokens worked against enterprise Exchange Online inboxes [@mstic-storm0558-jul14-2023]. Each generation of this lineage widens the issuer domain by one level: from one user's hash, to one directory's ticket-signing key, to one IdP's SAML key, to one supply chain's signing certificate, to one cloud provider's consumer signing key crossing into its enterprise trust boundary.

flowchart LR A["1997: Pass-the-Hash, Hobbit"] --> B["2014: Golden Ticket, Delpy"] B --> C["2017: Golden SAML, Reiner"] C --> D["2020: Sunburst supply chain, FireEye and Microsoft"] D --> E["2023: Storm-0558 cross-tier MSA key"]

Lineage 2: Third-party AV in the kernel

The second lineage runs in parallel. In the late 1990s, anti-virus drivers on Windows NT loaded unsigned and hooked the kernel directly through the System Service Descriptor Table. PatchGuard arrived first, shipping in April 2005 with Windows XP Professional x64 Edition and Windows Server 2003 SP1 x64; it policed the integrity of protected kernel structures so SSDT hooking could no longer survive [@patchguard-2005-history]. Eighteen months later, Vista x64 made Kernel-Mode Code Signing (KMCS) mandatory: every kernel driver now had to chain to a trusted Authenticode certificate [@kmcs-policy-docs] [@msrc-vista-2005-kernelmode]. The combined effect landed at scale with Vista x64, because that was the release in which unsigned x64 kernel code stopped loading by default.

The Windows policy, introduced with x64 editions of Vista, that requires every kernel-mode driver to be signed by a certificate chaining to a Microsoft-trusted root. The Cross-Signing Program let third-party certificate authorities issue compatible certificates; the Windows Hardware Compatibility Program (WHCP) is the modern submission path.

The AV industry pushed back. McAfee, Symantec, and Kaspersky argued publicly through 2006-2009 that PatchGuard amounted to an antitrust violation, since Microsoft's own Defender ran where they were now locked out [@theregister-2006-vista] [@msnews-2006-collab]. The EU-mediated settlement that followed produced the substrate of what eventually became the Microsoft Virus Initiative (MVI) -- a sanctioned set of kernel-access patterns and APIs that third-party AV vendors could use [@mvi-criteria].

Microsoft's program for vetting third-party endpoint security vendors that ship code into Windows. Membership requires meeting Microsoft-defined product and testing criteria. MVI is the institutional residue of the 2006-2009 antitrust settlement that produced today's third-party-AV-in-kernel model.

By the early 2020s, the visible failure mode of the kernel-resident AV class had become BYOVD ("bring your own vulnerable driver") attacks, in which an attacker loaded a signed-but-buggy legitimate driver as a privilege-escalation primitive. Microsoft's response was the Vulnerable Driver Blocklist, default-on in Windows 11 22H2 [@driver-block-rules]. That settled the malicious-vendor case. It did not settle the failure mode CrowdStrike would demonstrate in 2024.

Lineage 3: AI as a security boundary

The third lineage is the youngest. Windows Hello, launched with Windows 10 in 2015, was the first widely deployed Windows feature whose security decisions depended on a statistical classifier -- the biometric matcher that decided whether the face in front of the camera matched the enrolled template [@hello-for-business]. Defender's machine-learning detection components and Edge's SmartScreen reputation engine extended the same pattern through 2017-2020: statistical scoring as one input to a security decision. Microsoft 365 Copilot, launched in 2023, moved the statistical surface deeper into the trust model by letting an LLM execute actions on a user's behalf inside the tenant.

On May 20, 2024, the Copilot+ PC class moved the statistical surface onto the local device with a programmable NPU and a flagship feature, Recall, designed to take screenshots of everything on screen and index them for semantic search [@copilot-pcs-may-20]. Recall would force the question the prior generation had merely circled: is the AI agent's judgment a security boundary, and if so, what enforces it?

All three lineages reach their newest soft layer in the same three-year window. The next question is whether each soft layer was equally well defended on the morning of June 15, 2023 -- the morning the United States State Department's GCC-High security operations center pulled the audit-log query that flagged the Storm-0558 token misuse [@csrb-2024].

3. Pre-CSRB Posture and Storm-0558

On the morning of June 15, 2023, Microsoft's security posture looked complete. A decade of methodical work had pushed the platform's boundary primitives downward and outward: BitLocker, Credential Guard, VBS, HVCI, Pluton; Smart App Control; Continuous Access Evaluation; Defender for Endpoint as a managed cloud service. The operating assumption was that the platform was the boundary worth defending and that the institution sat above the boundary as a trusted operator. By the close of business that day, the assumption was wrong, and the State Department's GCC-High SOC was about to be the first organization on the planet to find out. Per the CSRB report (page 11), Microsoft was notified on June 16, 2023 [@csrb-2024].

The Storm-0558 forgery primitive worked because four independent decisions, each defensible in isolation, had aligned across six years.

The four pre-conditions

The first pre-condition was an unrotated 2016 MSA consumer signing key. Wiz Research's reconstruction of the published JWKS history shows the certificate was issued April 5, 2016 and expired April 4, 2021; the key continued to be trusted by at least one Outlook Web Access validator after expiry [@wiz-storm0558].

The second pre-condition was software-resident custody at the moment of key acquisition. The MSA signing service was not in a hardware security module at the time; only after the April 2025 Secure Future Initiative progress report did Microsoft confirm that MSA and Entra ID signing keys had been moved to hardware-backed security modules with automatic rotation and that the MSA signing service itself had been migrated to Azure Confidential VMs [@sfi-apr-2025].

The third pre-condition was a converged OWA token validator that accepted tokens signed by either MSA or Entra ID issuers. The September 2018 metadata-endpoint convergence had been a developer-experience decision that worked correctly; the failure was a later OWA migration onto that endpoint without adding the cross-tier guard.

The fourth was a missing issuer and audience check on the OWA validation path. Microsoft's September 6, 2023 root cause statement, later edited in place on March 12, 2024, is unambiguous: "developers in the mail system incorrectly assumed libraries performed complete validation and did not add the required issuer/scope validation" [@msrc-storm0558-key-acq].

flowchart TD A["2016 MSA signing certificate issued"] --> E["Forgery primitive"] B["Software-resident key custody"] --> E C["Converged MSA plus Entra ID validator endpoint"] --> E D["OWA path missing iss and aud validation"] --> E E --> F["Forged tokens accepted by enterprise Exchange Online"]

The combination produced a forgery primitive that worked at nation-state scale. The CSRB tallied the victims: 22 enterprise organizations, approximately 503 personal accounts, and roughly 60,000 emails from 10 State Department accounts [@csrb-2024]. The CSRB's April 2, 2024 verdict, on page ii of the public report, is the load-bearing sentence of the era and is reproduced verbatim in the PullQuote below [@csrb-2024]. The report was the third the Board had completed since its February 2022 announcement [@dhs-press-2024]; the prior two had reviewed Log4j and Lapsus$, neither of which was a single-vendor failure of the same kind [@thehackernews-csrb] [@cybersecuritydive-csrb].

A United States public-private review board, modeled loosely on the National Transportation Safety Board, that conducts after-action reviews of consequential cybersecurity incidents. The CSRB has no enforcement authority; its product is a public report with recommendations. The consumer-tier identity tenant that backs personal Outlook, OneDrive, Xbox, and similar consumer services. Its canonical tenant GUID at the OpenID Connect discovery endpoint is `9188040d-6c67-4c5b-b112-36a304b66dad` [@msa-oidc-discovery]. The Storm-0558 forgery primitive used an MSA-issued signing key against an enterprise Exchange Online validator that did not reject the consumer-tier issuer. This intrusion was preventable and should never have occurred... Microsoft's security culture was inadequate and requires an overhaul. -- United States Cyber Safety Review Board, *Review of the Summer 2023 Microsoft Exchange Online Intrusion*, April 2, 2024 [@csrb-2024].

Note: Microsoft's September 6, 2023 post initially hypothesized that the MSA key had been extracted from a 2021 crash dump. On March 12, 2024 Microsoft edited the post in place with a verbatim note: "the actor access may have resulted from a crash dump in 2021, but we have not found a crash dump containing the impacted key material" [@msrc-storm0558-key-acq]. The CSRB report (page 17) is equally explicit: "Microsoft has been unable to determine how or when Storm-0558 obtained the MSA key" [@csrb-2024]. Any account that asserts the crash-dump path as fact is reading a retracted hypothesis as confirmed history.

The validation step Microsoft says was missing on the OWA path is not exotic: RFC 8725, the IETF's JSON Web Token best current practices, treats issuer and audience checks as baseline obligations [@rfc-8725]. The browser-runnable snippet below shows the shape of the check the OWA validator skipped.

{` const consumerTenantGuid = "9188040d-6c67-4c5b-b112-36a304b66dad"; const token = { iss: "login.microsoftonline.com/" + consumerTenantGuid + "/v2.0", aud: "outlook.office.com", sub: "victim@statedept.example", };

function validate(token, expectedIssuer, expectedAudience) { if (token.iss !== expectedIssuer) return "reject: wrong issuer"; if (token.aud !== expectedAudience) return "reject: wrong audience"; return "accept"; }

// What the OWA path should have done for enterprise mailboxes const enterpriseTenantGuid = "your-enterprise-tenant-guid"; const enterpriseIssuer = "login.microsoftonline.com/" + enterpriseTenantGuid + "/v2.0"; console.log(validate(token, enterpriseIssuer, "outlook.office.com")); `}

Storm-0558 was the first half of the proof: the layer above the OS -- Microsoft's own identity-token custody -- is a soft layer. The second half arrived almost exactly one year later, on July 19, 2024. Before walking that morning, we have to walk the institutional response Microsoft launched in the four months between the two events, because the response is what the rest of the article evaluates.

4. Five Threads Across 2023-2026

The 2023-2026 era has five parallel storylines. They have to be walked as concurrent, not sequential, because the era's institutional fact is that all five moved at once and reinforced each other.

4.1 The CSRB and the Secure Future Initiative

Microsoft's response to Storm-0558 began five months before the CSRB ruled the breach preventable and continued for two years after. On November 2, 2023, Microsoft Vice Chair and President Brad Smith published a post on the company's On the Issues blog announcing the Secure Future Initiative (SFI). The original framing had three pillars: AI-based cyber defenses, advances in fundamental software engineering, and advocacy for international norms [@sfi-nov-2023].

Two events between November 2023 and May 2024 forced a reframing. The first was the January 2024 Midnight Blizzard disclosure -- the Russian SVR-linked actor that compromised Microsoft corporate email through a legacy test tenant. The second was the April 2, 2024 CSRB verdict. On May 3, 2024, in an unusual move, Microsoft Chairman and CEO Satya Nadella wrote directly to employees and posted the memo publicly: "I want to talk about something critical to our company's future: prioritizing security above all else... we will commit the entirety of our organization to SFI" [@sfi-may3-2024-nadella]. The Microsoft Security blog technical companion the same day reframed SFI as three principles (Secure by Design, Secure by Default, Secure Operations) and six pillars (Protect Identities and Secrets, Protect Tenants and Isolate Production Systems, Protect Networks, Protect Engineering Systems, Monitor and Detect Threats, Accelerate Response and Remediation) [@sfi-may3-2024-secblog].

On June 13, 2024, in front of the House Committee on Homeland Security, Brad Smith said the sentence that anchors Microsoft's post-CSRB posture: "Microsoft accepts responsibility for each and every one of the issues cited in the CSRB's report. Without equivocation or hesitation. And without any sense of defensiveness" [@smith-house-testimony-jun-2024] [@ms-on-issues-jun-2024].

Microsoft accepts responsibility for each and every one of the issues cited in the CSRB's report. Without equivocation or hesitation. And without any sense of defensiveness. -- Brad Smith, June 13, 2024, before the House Committee on Homeland Security [@smith-house-testimony-jun-2024].

The progress reports that followed quantified the institutional commitment. The September 23, 2024 update is the first to use Microsoft's signature phrase: "we have dedicated the equivalent of 34,000 full-time engineers to SFI -- making it the largest cybersecurity engineering effort in history" [@sfi-sept-2024]. The same post is the first to link senior leadership compensation to security outcomes and to formalize the Cybersecurity Governance Council and Deputy CISO structure. The April 21, 2025 progress report reports that MSA signing keys had been moved to hardware-backed security modules with automatic rotation, the MSA signing service had been migrated to Azure Confidential VMs, and identity-SDK validation for Microsoft's own apps had moved from 73% to 90% [@sfi-apr-2025]. The November 10, 2025 Windows-and-Surface-specific SFI report introduced the Hotpatch metric -- 81% of enrolled devices compliant within 24 hours of Patch Tuesday -- and announced the Rust rewrite of Surface UEFI firmware and Windows drivers, paired with the Open Device Partnership opening those Rust drivers to OEM partners [@sfi-nov-2025-windows].

Microsoft's "34,000 full-time engineers" wording is an FTE-equivalent calculation, not a literal headcount [@sfi-sept-2024]. The April 2025 report rephrases it as "34,000 engineers working full-time for 11 months" [@sfi-apr-2025], which is the same arithmetic in a more honest grammar.

SFI report	Identity-SDK validation	Signing-key custody	Audit-log retention	Hardware and firmware	Employee and exec ties
Nov 2, 2023 [@sfi-nov-2023]	Not yet reported	Pre-Storm-0558 baseline	Pre-incident baseline	Not in scope	Three pillars framing only
Sept 23, 2024 [@sfi-sept-2024]	Reported, no number	Azure Managed HSM with automatic rotation	2-year retention committed	Pluton firmware over OS channel	Senior leadership compensation tied; Cybersecurity Governance Council
Apr 21, 2025 [@sfi-apr-2025]	90% (up from 73%)	MSA service in Azure Confidential VMs; Entra ID migration in progress	2-year retention live	Pluton across all three x86 vendors	Continuing
Nov 10, 2025 [@sfi-nov-2025-windows]	Continuing	Continuing	Continuing	Surface UEFI and Windows drivers in Rust; Open Device Partnership	95% of employees completing AI-attack training

SFI is the first time a platform vendor has publicly tied executive compensation, two years of audit-log retention, the equivalent of 34,000 full-time engineers, a Rust rewrite of UEFI firmware and Windows drivers, and a sustained cross-progress-report measurement program to the explicit premise that the vendor's own security culture is part of the platform's attack surface. That is the institutional half of the thesis.

On the very day Brad Smith's House testimony committed Microsoft to the SFI roadmap, an entirely different soft layer -- one that had nothing to do with identity-token custody -- had already failed quietly. That morning's failure is the second thread.

4.2 Recall as the AI-feature security-review worked example

The second thread arrived from an unexpected direction. On the same June 13, 2024 that Brad Smith committed Microsoft to the SFI roadmap, Microsoft pulled its flagship Copilot+ PC AI feature five days before launch over a structural problem in its own threat model. The feature was Recall. The timeline that followed is the worked example of what post-SFI AI-feature security review looks like under sustained adversarial pressure.

On May 20, 2024, Yusuf Mehdi announced Copilot+ PCs with a 40+ TOPS NPU minimum and Recall as the flagship feature [@copilot-pcs-may-20]. Recall's Generation-1 design was simple: take a screenshot of the user's screen at intervals, extract text and entities with on-device AI, and store the result in an SQLite database protected by AES-128-XTS volume encryption plus filesystem ACLs scoped to the user. The "Recall is not shared with anyone" framing implied a clean trust boundary. It was wrong.

On May 28, 2024, the Swiss researcher Alexander Hagenah (@xaitax) released TotalRecall, a proof-of-concept extractor that walked the SQLite store with the user's own privileges and dumped every snapshot [@totalrecall-github]. Two days later, Kevin Beaumont's DoublePulsar post amplified the threat model into the community's consciousness with the line that defined the news cycle: "Recall enables threat actors to automate scraping everything you have ever looked at within seconds" [@beaumont-doublepulsar] [@helpnetsecurity-totalrecall]. On June 3, 2024, Google Project Zero's James Forshaw published the structural-bound observation that the rest of the Recall story would have to live with: "Spoiler, it is only protected through being ACL'ed to SYSTEM and so any privilege escalation (or non-security boundary cough) is sufficient to leak the information" [@forshaw-acl-jun3-2024]. The parenthetical pointed at Microsoft's own Security Servicing Criteria for Windows, which treats same-user post-authentication as not a security boundary [@msrc-servicing-criteria].

Spoiler, it is only protected through being ACL'ed to SYSTEM and so any privilege escalation (or non-security boundary *cough*) is sufficient to leak the information. -- James Forshaw, Google Project Zero, June 3, 2024 [@forshaw-acl-jun3-2024].

On June 7, 2024, Pavan Davuluri posted a Generation-2 commitment: Recall would be default-off, gated by Windows Hello Enhanced Sign-in Security, and would use just-in-time decryption [@recall-davuluri-jun7-2024]. On June 13, 2024, in an in-place edit to the same post, Davuluri pulled Recall from the planned June 18, 2024 Copilot+ PC ship date and moved it into the Windows Insider Program [@recall-davuluri-jun7-2024]. On September 27, 2024, Davuluri posted the Generation-3 architecture: "Encryption keys are protected via the Trusted Platform Module (TPM), tied to a user's Windows Hello Enhanced Sign-in Security identity, and can only be used by operations within a secure environment called a Virtualization-based Security Enclave (VBS Enclave)" [@recall-davuluri-sept27-2024]. Recall returned to Insiders on November 22, 2024, expanded to AMD and Intel Copilot+ silicon in spring 2025, and reached general availability on May 13, 2025 [@recall-manage-docs].

A user-mode trustlet that runs inside Virtual Trust Level 1 -- the same isolated environment used by Credential Guard and the Secure Kernel -- with an attested code identity, so that code outside the enclave (including a compromised normal-world kernel) cannot read enclave memory [@vbs-enclaves-docs]. Recall's Generation-3 design uses a VBS Enclave to perform decryption with TPM-bound keys gated by Windows Hello ESS [@recall-davuluri-sept27-2024] [@hello-ess-docs]. flowchart LR subgraph G1 ["Generation 1 (May 20, 2024)"] A1["Screenshots"] --> B1["Plaintext SQLite"] B1 --> C1["Filesystem ACL to user"] C1 --> D1["Any user-mode process reads"] end subgraph G3 ["Generation 3 (Sept 27, 2024)"] A3["Screenshots"] --> B3["AES-encrypted snapshot"] B3 --> C3["VBS Enclave decrypts in VTL1"] C3 --> D3["TPM key release"] D3 --> E3["Windows Hello ESS gate"] E3 --> F3["UI plane render"] end

Generation	Key storage	Decrypt gate	Trust boundary	Known public attack	Status
Gen 1 (May 20, 2024)	Software, filesystem ACL	Logon	Same user account	TotalRecall, May 28, 2024 [@totalrecall-github]	Withdrawn
Gen 2 (Jun 7, 2024)	Default-off, just-in-time decrypt	Hello ESS	Same user account	Not shipped	Withdrawn before June 18 [@recall-davuluri-jun7-2024]
Gen 3 (Sept 27, 2024)	TPM-bound, VBS Enclave [@recall-davuluri-sept27-2024]	Hello ESS plus enclave attestation	Enclave with attested identity	TotalRecall Reloaded, April 2026 -- standard-user COM and DLL injection against AIXHost.exe [@itnews-totalrecall-reloaded]	GA May 13, 2025 [@recall-manage-docs]

Recall is *not* the first Microsoft product to ship on VBS Enclaves. SQL Server 2019 Always Encrypted with secure enclaves, generally available November 4, 2019, is the substrate precedent and used the same VTL1 trustlet pattern Recall inherits [@sql-always-encrypted-enclaves]. The correct narrow claim is that Recall is the first VBS-Enclave deployment in the *Windows desktop shell* to face sustained adversarial review by named external researchers.

Note: Both the June 18, 2024 Copilot+ PC ship date and the October 1, 2024 broad-SKU 24H2 RTM date passed without Recall. Recall reached general availability on May 13, 2025 [@recall-manage-docs]. The "24H2 launched with Recall" framing repeated in secondary press is a marketing-cycle compression error; primary sources rule it out.

The April 2026 TotalRecall Reloaded disclosure closed the loop. Hagenah did not attack Recall's encryption, which he described as sound, or the VBS enclave, which he called "rock solid." He attacked the AIXHost.exe process that decrypts and renders the timeline for the user, using a standard-user COM and DLL injection chain. Microsoft determined that the technique "operates within the current, documented security design of Recall" [@itnews-totalrecall-reloaded]. The vault is solid; the delivery truck is, by design, not.

Recall demonstrated that the AI-feature application plane is a third soft layer, distinct from both identity-token custody and third-party kernel drivers. But the most measurable failure of the era did not involve an AI feature, an attacker, or an exploit. It involved twenty bytes.

4.3 CrowdStrike and the road to WESP

The third thread is the load-bearing one. A non-malicious data-parsing bug in a third-party kernel driver -- no attacker involved -- bricked roughly 8.5 million Windows hosts because the OS layer had given that third-party vendor kernel privilege. This is the failure mode the 2006-2009 EU-engagement settlement never stress-tested.

CrowdStrike's August 6, 2024 External Technical Root Cause Analysis names the mechanism precisely. Falcon ships two kinds of detection updates: signed Sensor Content shipped infrequently with the sensor itself, and Rapid Response Content shipped multiple times per day as data files interpreted by an in-kernel Content Interpreter. On July 19, 2024 at 04:09 UTC, CrowdStrike pushed Channel File 291, an IPC Template Instance file used by the Inter-Process Communication template type. The Content Interpreter expected 20 input parameters; the file provided 21. The mismatch produced an out-of-bounds memory read in csagent.sys. The kernel page fault that followed was logged by Microsoft's own incident analysis at nt!KiPageFault+0x369 with a csagent+0xe14ed faulting instruction address [@crowdstrike-rca-pdf] [@crowdstrike-exec-summary] [@ms-jul27-2024-security-tools].

CrowdStrike's term for the Rapid Response Content delivery unit -- a data file interpreted at runtime by the in-kernel Content Interpreter inside the Falcon sensor. Channel files are not driver binaries and do not go through KMCS; they configure the behavior of a driver that is already loaded [@crowdstrike-rca-pdf]. sequenceDiagram participant Cloud as CrowdStrike cloud participant Sensor as Falcon sensor (csagent.sys) participant CI as In-kernel Content Interpreter participant Kernel as NT kernel Cloud->>Sensor: Push Channel File 291 (IPC Template Instance) Sensor->>CI: Load 21 input parameters Note over CI: Expected 20 parameters, got 21 CI->>CI: Index past array bound CI->>Kernel: OOB read at csagent+0xe14ed Kernel->>Kernel: nt!KiPageFault+0x369 Kernel->>Sensor: BSOD across 8.5M hosts

The scale was unambiguous. David Weston's July 20, 2024 post put the number at "8.5 million Windows devices, or less than one percent of all Windows machines," and noted that the "broad economic and societal impacts reflect the use of CrowdStrike by enterprises that run many critical services" [@ms-weston-jul20-2024]. Delta Air Lines cancelled approximately 7,000 flights between July 19 and July 25 -- a figure the carrier's May 2025 lawsuit filings and contemporaneous reporting both anchor to [@wiki-crowdstrike-outage]. Parametrix estimated the direct losses to US Fortune 500 companies alone at roughly 5.4 billion dollars [@cso-hints-kernel].

Microsoft's response over the next nineteen months was a paced institutional walk away from the 2006-2009 settlement, framed publicly as resilience rather than retreat. On September 10, 2024, Microsoft hosted the Windows Endpoint Security Summit at Redmond with eight MVI vendors in attendance [@ms-securityweek-wesp]. David Weston's September 12, 2024 post captured the framing: "endpoint security vendors and government officials from the U.S. and Europe... strategies for improving resiliency and protecting our mutual customers' critical infrastructure" [@weston-sept12-2024-wess]. On November 19, 2024 at Ignite, Microsoft publicly named the Windows Resiliency Initiative [@thehackernews-crowdstrike-rca] [@ms-securityweek-wesp].

On June 26, 2025, the Windows Experience blog made the load-bearing commitment that re-opened the kernel-residency question: "Next month, we will deliver a private preview of the Windows endpoint security platform to a set of MVI partners. The new Windows capabilities will allow them to start building their solutions to run outside the Windows kernel. This means security products like anti-virus and endpoint protection solutions can run in user mode just as apps do" [@wri-jun26-2025]. The private preview opened in July 2025 to Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure [@ms-securityweek-wesp] [@heise-resilient-windows].

The Windows-supplied user-mode API surface for endpoint security vendors announced at Microsoft Build 2025 and opened to MVI 3.0 partners in private preview in July 2025 [@wri-jun26-2025]. WESP separates kernel-resident event collection (owned by Windows) from vendor-owned policy evaluation (run in a tamper-protected user-mode service). It is the architectural answer to the failure mode CrowdStrike demonstrated -- a vendor data-parsing bug can no longer take the kernel down with it.

In parallel, Microsoft began closing the legacy escape hatch. On March 26, 2026, Microsoft IT Pro group program manager Peter Waxman posted "Advancing Windows driver security: Removing trust for the cross-signed driver program," announcing that the April 14, 2026 Windows security update would remove trust for the cross-signed driver program in evaluation mode on Windows 11 24H2, 25H2, 26H1, and Server 2025 [@techcommunity-cross-signing]. The April 14, 2026 driver-protection KB followed, blocking the psmounterex.sys family as the first named exemplar [@april-2026-driver-kb]. Industry coverage framed the move as "closing a 20-year-old critical security hole" [@computerworld-cross-signing] [@techpowerup-cross-signing] [@cybersecuritynews-cross-signing]; the Custom Kernel Signers feature in Application Control for Business is the escape hatch Microsoft preserved for organizations that legitimately need to sign internal kernel drivers, with the Windows Hardware Compatibility Program as the canonical path [@custom-kernel-signers].

The legacy KMCS trust path, introduced in the early 2000s, that let third-party certificate authorities issue Windows-trusted code-signing certificates for kernel drivers. Because developers managed their own private keys, the program became a frequent target for credential theft and rootkit deployment [@cybersecuritynews-cross-signing]. The April 14, 2026 Windows update removes trust for cross-signed drivers in evaluation mode, leaving WHCP as the canonical submission path.

Note: Microsoft has not publicly committed to a hard "AV kernel-driver ban" date. The April 2026 update is a driver-loading-policy change with a Code Integrity-anchored evaluation window (100 runtime hours plus 2 or 3 restarts before policy activates) [@techcommunity-cross-signing], not a categorical AV kernel-driver eviction. WHCP-certified kernel drivers continue to load. Conflating WESP with the Cross-Signing trust deprecation is a recurring citation-audit failure: they are separate primitives that are part of the same multi-year transition.

If the OS layer kept hardening while the layer above became the soft spot, the AI agent layer is the youngest version of the same pattern -- and the era is producing its first CVE-grade exemplars in real time.

4.4 AI threat-model arrivals

The fourth thread is the youngest. By mid-2024 the agentic-AI persistence catalog was beginning to populate in the CVE database, and Microsoft, Apple, Google, and Anthropic were converging on a structural admission: no existing operating-system primitive knows how to enforce policy on an AI agent's judgment.

The substrate arrived in pieces. May 20, 2024 brought the Copilot+ PC announcement and the NPU as a programmable local surface [@copilot-pcs-may-20]. June 10, 2024 brought Apple's Private Cloud Compute design paper, whose five core requirements -- stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency -- now anchor every "what would attested AI infrastructure look like" conversation in the industry [@apple-pcc]. June 26, 2024 brought Microsoft's first public write-up of a multi-turn jailbreak class -- Skeleton Key, originally demonstrated by Mark Russinovich at Microsoft Build 2024Russinovich's stage demo called the technique "Master Key"; the MSRC blog renamed it "Skeleton Key" for public disclosure on June 26, 2024 [@ms-skeleton-key]. -- and the corresponding Prompt Shields mitigation in Azure AI Content Safety [@ms-skeleton-key] [@jailbreak-detection-shields]. August 8, 2024 brought Michael Bargury's Black Hat USA sessions "15 Ways to Break Your Copilot" and "Living off Microsoft Copilot," where Bargury demonstrated SharePoint-RAG-grounded exfiltration chains and the LOLCopilot tool that used a victim's own Copilot to write spear-phishing email in the victim's writing style [@mbgsec-bargury-pdf] [@thurrott-bargury] [@theregister-bargury].

The CVE catalog populated through 2025-2026. The single most consequential entry is EchoLeak (CVE-2025-32711) -- a single-email, zero-click data-exfiltration chain against Microsoft 365 Copilot disclosed by Aim Labs in June 2025 [@aim-labs-echoleak] [@nvd-cve-32711]. SecurityWeek's reporting captures the structural achievement: "In order to execute an EchoLeak attack, the attacker has to bypass several security mechanisms, including cross-prompt injection attack (XPIA) classifiers" [@securityweek-echoleak]. Sentra's reconstruction enumerates the four bypasses: the XPIA classifier was evaded by phrasing the malicious instructions as if addressed to the human recipient; Copilot's link-redaction was circumvented with reference-style Markdown; the email client's automatic image pre-fetch was used to trigger an exfiltration request; and Microsoft Teams' asynchronous preview API -- an allowed domain under Copilot's Content Security Policy -- was used to proxy the exfiltrated data to the attacker [@sentra-echoleak]. Microsoft classified the vulnerability "critical" with CVSS 9.3 and patched it server-side with no customer action required [@checkmarx-echoleak] [@securityweek-echoleak].

flowchart TD A["Attacker email lands in user inbox"] --> B["XPIA classifier bypass via direct-to-user phrasing"] B --> C["RAG retrieval pulls email into Copilot context"] C --> D["Markdown reference-style link bypass of redaction"] D --> E["Automatic image pre-fetch triggers exfiltration request"] E --> F["Teams preview API as allowed CSP domain proxies data"] F --> G["Attacker receives sensitive M365 content"] Per OWASP LLM01, the class of attacks in which adversary-controlled text fed into a large language model causes the model to take an action the system designer did not intend [@owasp-llm-top10]. Indirect prompt injection is the subclass in which the malicious text reaches the model through retrieved context (RAG, web fetch, email body) rather than the user's prompt directly. EchoLeak is the canonical indirect-prompt-injection chain against an LLM-application-layer agent.

The catalog around EchoLeak is now substantial. PromptJacking is Koi Security's collective name for three Anthropic Claude Desktop extension RCE vulnerabilities (Chrome, iMessage, and Apple Notes connectors) -- AppleScript injection from a maliciously crafted URL, rated CVSS 8.9 by Anthropic, fixed in version 0.1.9 in September 2025 [@koi-promptjacking] [@infosec-magazine-promptjacking]. ShadowPrompt, disclosed by Koi Security on March 26, 2026, chained a wildcard origin allowlist (*.claude.ai) in the Claude Chrome extension with a DOM-based XSS in an Arkose Labs CAPTCHA hosted on a-cdn.claude.ai to let any website silently inject prompts; the extension had over 3 million users at the time of disclosure [@koi-shadowprompt]. CVE-2025-53773 -- "ZombAIs" -- is a GitHub Copilot RCE via prompt-injection-controlled writes to .vscode/settings.json that enable chat.tools.autoApprove ("YOLO mode") and grant the agent unrestricted shell access [@nvd-cve-53773] [@cybersecuritynews-copilot-rce].

CVE or named class	Affected agent	Structural bound exploited	Mitigation status
EchoLeak (CVE-2025-32711) [@nvd-cve-32711]	Microsoft 365 Copilot	LLM Scope Violation -- agent treats retrieved context as trusted	Server-side patch June 2025 [@securityweek-echoleak]
PromptJacking (CVSS 8.9) [@koi-promptjacking]	Claude Desktop extensions	Unsanitized AppleScript template interpolation	Fixed in version 0.1.9 [@infosec-magazine-promptjacking]
ShadowPrompt [@koi-shadowprompt]	Claude Chrome extension	Wildcard origin allowlist plus third-party CAPTCHA XSS	Origin checks tightened in 1.0.41
CVE-2025-53773 (ZombAIs) [@nvd-cve-53773]	GitHub Copilot agent	Agent writes own configuration; YOLO-mode toggle	Patched [@cybersecuritynews-copilot-rce]
Skeleton Key / Master Key [@ms-skeleton-key]	Azure-managed LLMs	Multi-turn safety-policy override	Prompt Shields mitigation [@jailbreak-detection-shields]
Living off Microsoft Copilot [@mbgsec-bargury-pdf]	Microsoft 365 Copilot tenant	RAG-grounded post-compromise abuse	Phillip Misner: "similar to other post-compromise techniques" [@thurrott-bargury]

Aim Labs coined the phrase "LLM Scope Violation" for the EchoLeak chain. The vocabulary matters: the bug is not that the model failed a safety filter; it is that the model treated retrieved content as instruction. Anthropic's mid-2025 research note frames the structural caveat in similar terms: "prompt injection is far from a solved problem, particularly as models take more real-world actions... every webpage an agent visits is a potential vector for attack" [@anthropic-prompt-injection].

The taxonomies these CVEs are graded against are themselves new. OWASP published its Top 10 for Large Language Model Applications in 2023 and refreshed it in 2025 [@owasp-llm-top10]; NIST released the AI Risk Management Framework in January 2023 and the GenAI-specific Profile (AI 600-1) in July 2024 [@nist-ai-rmf] [@nist-ai-600-1]. Both treat prompt injection as a first-class class. Neither is a normative standard the way RFC 8725 is for JWTs.

Note: The structural bound EchoLeak demonstrates is general: any LLM agent that reads adversary-controllable text and can take an action -- write, send, fetch, execute -- has the structural template. Composition (cage plus input filter plus output filter) reduces blast radius; it does not eliminate the class.

If the AI agent's judgment is now a trust principal, the defensive arrivals across the era are the OS-layer hardening that the layer-above-the-OS soft spots are contrasted against. The next subsection inventories them so the state-of-the-art section can evaluate the whole stack.

4.5 Defensive arrivals across the era

The fifth thread runs underneath the other four. While the layer above the OS was failing publicly, the OS layer itself kept hardening -- across hardware roots of trust, on-device confidentiality, identity-side enforcement, and the cryptographic substrate.

Pluton expanded. The November 2020 Microsoft-AMD-Intel-Qualcomm joint announcement is the prior context, AMD Ryzen 6000 in 2022 was the first PC-class shipment, and Intel Core Ultra Series 2 (Lunar Lake, GA September 24, 2024) brought Pluton-as-Partner-Security-Engine to mainstream Intel mobile silicon [@pluton-docs]. Microsoft moved Pluton firmware servicing to the OS update channel, decoupling security-critical TPM-and-RoT updates from OEM BIOS-release cadences. Personal Data Encryption -- the per-user, per-file successor to EFS that uses Windows Hello to derive the file-encryption key -- shipped as a default-on option on Windows 11 24H2. Continuous Access Evaluation became the default revocation primitive for Microsoft 365 services, providing roughly 3-minute token-revocation latency in place of the prior cache-bound model [@cae-docs] [@openid-sse].

The cryptographic substrate finalized. On August 13, 2024, NIST published FIPS 203 (ML-KEM, the Module-Lattice-Based Key Encapsulation Mechanism standard) [@fips-203], FIPS 204 (ML-DSA, the Module-Lattice-Based Digital Signature standard) [@fips-204], and FIPS 205 (SLH-DSA, the Stateless Hash-Based Digital Signature standard) [@fips-205], with the Federal Register notice following on August 14, 2024 [@federal-register-pq].

The three NIST-standardized post-quantum primitives finalized August 13, 2024. ML-KEM (FIPS 203) is the lattice-based key encapsulation mechanism; ML-DSA (FIPS 204) is the lattice-based digital signature standard; SLH-DSA (FIPS 205) is the hash-based signature standard that hedges against future lattice-attack discoveries [@fips-203] [@fips-204] [@fips-205]. NIST chose three families precisely because no single family has both the security-margin and the performance properties needed for every Windows surface.

Microsoft's SymCrypt cryptographic library shipped ML-KEM and ML-DSA implementations; SChannel began previewing TLS 1.3 with ML-KEM hybrid key exchange; DPAPI-NG envelope-key migration to ML-KEM is in research; Kerberos post-quantum migration is named in the SFI April 2025 progress report as a multi-year program [@sfi-apr-2025]. The eight Windows AI updates published in coordination on April 25, 2025 captured the parallel: responsible AI commitments, Phi Silica multimodal, and Copilot+ PC AI features shipped together as a single coordinated public moment [@blogs-windows-apr25-2025].

FIPS 206 -- the FN-DSA standard derived from FALCON -- remains in draft as of May 2026; the URL csrc.nist.gov/pubs/fips/206/ipd returns HTTP 404 because NIST has not published an Initial Public Draft. Anyone needing a current status should look at the NIST Post-Quantum Cryptography project page rather than the per-FIPS page.

The defensive arrivals are real and substantial. They do not change the article's thesis -- they harden the OS layer (Pluton, VBS, PDE, Driver Block List) and the cryptographic substrate (PQC). The thesis is about what happens above the OS layer.

Five threads. One inflection. The question the next section must answer: what architectural insight ties them together?

5. The Insight

Three insights define the era. The article's thesis is the first; the other two are the context that makes the first ring true. All three must be named because the era's actual insight is that all three are true simultaneously and reinforce each other.

The third-party kernel privilege insight

The first insight is the article's thesis. The CrowdStrike outage refuted the 2006-2009 EU-engagement assumption that AV and EDR vendors needed kernel access to be effective by demonstrating a failure mode the argument did not address: a non-malicious data-parsing bug inside a privileged third-party kernel driver, no attacker involved, 8.5 million hosts offline, roughly 5.4 billion dollars in Parametrix-estimated direct losses to US Fortune 500 [@ms-weston-jul20-2024] [@cso-hints-kernel] [@crowdstrike-rca-pdf]. The Windows Endpoint Security Platform is the architectural answer: a sanctioned user-mode EDR API surface (tamper-protected, performance-equivalent target, MVI-3.0-gated) co-engineered with the major AV vendors [@wri-jun26-2025]. The April 14, 2026 Cross-Signing Program trust deprecation closes the legacy escape hatch [@techcommunity-cross-signing]. Together, they are a quiet admission that the 25-year settlement was a compromise the era's evidence has now made unsustainable.

flowchart TD subgraph Kernel ["Kernel (OS-owned)"] K1["ETW providers"] --> K2["Event broker"] K3["Process and file telemetry"] --> K2 end K2 --> U1["Tamper-protected user-mode service"] subgraph User ["User mode (vendor-owned)"] U1 --> U2["Vendor detection logic"] U2 --> U3["Vendor action API call"] end U3 --> Kernel L["Vendor channel-file or model update"] --> U2

The institution-is-the-boundary insight

The second insight is what Storm-0558 plus the CSRB verdict prove together: the vendor's internal security culture is part of the platform's attack surface for every downstream customer. The unrotated 2016 MSA signing key was not a bug; it was a decision (or a default) made inside Microsoft about how long signing keys lived and how they were stored. The missing OWA issuer-validation check was not a bug; it was an architectural assumption developers made about which libraries handled which validation steps. The Secure Future Initiative is the first time a platform vendor has publicly bet executive compensation and the cross-progress-report engineering commitments enumerated in §4.1 on this insight at the corporate level [@sfi-sept-2024] [@sfi-apr-2025] [@sfi-nov-2025-windows].

The AI agent is a new trust principal insight

The third insight is what the Recall saga is the first widely public worked example of. An AI feature whose threat model is not covered by AppContainer, VBS, TPM, or DPAPI alone forced Microsoft to invent a new pattern: VBS Enclave plus Windows Hello ESS gating plus TPM-rooted device key plus in-enclave content filtering, with explicit acknowledgement that the UI plane that decrypts content for display is, by Microsoft's own Security Servicing Criteria, not a security boundary [@recall-davuluri-sept27-2024] [@msrc-servicing-criteria] [@hello-ess-docs] [@vbs-enclaves-docs]. The April 2026 TotalRecall Reloaded disclosure proves the boundary holds at the vault and breaks at the delivery truck, exactly as the September 2024 design predicted it would [@itnews-totalrecall-reloaded]. The agentic-AI CVE catalog -- EchoLeak, PromptJacking, ShadowPrompt, ZombAIs -- shows the broader version of the same pattern: existing primitives can sandbox the agent's process and protect its data; none of them knows how to enforce policy on the agent's decisions.

Key idea: The three insights are not separable. The institutional failure (Storm-0558), the kernel-architectural failure (CrowdStrike), and the AI-trust-model failure (Recall and the EchoLeak class) are one architectural inflection seen from three angles: the layer above the OS has become the soft layer, and the OS-layer primitives Microsoft spent 25 years building do not extend upward into it. WESP, SFI, and the Recall Generation-3 architecture are Microsoft's first sustained engineering re-architecture of all three soft spots in parallel.

The thesis foregrounds the third-party kernel privilege insight because CrowdStrike is the single most measurable evidence -- the §4.3 numbers above, plus the Delta cancellations and the April 14, 2026 Cross-Signing trust deprecation. The other two are the context that explains why the layer above the OS is now the soft layer in multiple different ways.

If those three insights are right, what does the actual production deployment picture look like in May 2026? Six surfaces. The next section walks each one.

6. State of the Art, May 2026

May 2026 is the first calendar window in which all three soft-layer responses are simultaneously visible in production deployment, sanctioned private preview, or public roadmap. Six surfaces have to be evaluated together.

Identity. MSA and Entra ID signing keys live in hardware-backed security modules with automatic rotation [@azure-managed-hsm]; the MSA signing service runs in Azure Confidential VMs and Entra ID signing service migration is in progress [@sfi-apr-2025] [@azure-confidential-vm]. Microsoft's April 2025 progress report states that 90% of Entra ID tokens for Microsoft's own apps validate through the hardened identity SDK [@sfi-apr-2025]. Continuous Access Evaluation is the default revocation primitive for Microsoft 365 [@cae-docs]. Kerberos and SChannel post-quantum migration roadmaps are public; ML-DSA code-signing is in research.

Endpoint. Windows 11 24H2 RTM'd on October 1, 2024 for broad SKUs (Copilot+ PCs reached the same RTM on June 18, 2024, without Recall) [@copilot-pcs-may-20]. Windows 11 25H2 is in market. Windows 10 went end-of-life on October 14, 2025 [@ms-windows10-lifecycle]. Smart App Control ships default-on for new installs; Personal Data Encryption is generally available; Application Security Reduction rules cover AI-feature exclusions; Recall is GA on Snapdragon, AMD, and Intel Copilot+ silicon [@recall-manage-docs].

Antivirus and EDR. The Windows Endpoint Security Platform is in MVI 3.0 private preview as of July 2025 with Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure participating [@ms-securityweek-wesp] [@wri-jun26-2025]. Defender is already user-mode-capable. The April 14, 2026 Windows security update has begun the Cross-Signing Program trust deprecation in evaluation mode with the 100-runtime-hour and 2-or-3-restart criteria; WHCP-only enforcement is opt-in [@techcommunity-cross-signing] [@april-2026-driver-kb].

On-device AI. Recall Generation-3 is the worked example of the VBS Enclave plus TPM-rooted plus Windows Hello ESS gating pattern [@recall-davuluri-sept27-2024]. Copilot Vision and the on-device agent surface inherit the same template. Azure AI Content Safety Prompt Shields are the input-filter substrate for prompt-injection mitigation [@jailbreak-detection-shields]. OWASP LLM Top 10 [@owasp-llm-top10] and NIST AI RMF [@nist-ai-rmf] [@nist-ai-600-1] are the threat-class taxonomies.

Hardware. Pluton is across all three major x86 vendors plus Snapdragon: AMD Ryzen 6000+; Intel Core Ultra Series 2 and Series 3 with Partner Security Engine; Qualcomm Snapdragon 8cx Gen 3 and X Series [@pluton-docs]. Pluton firmware on 2024+ AMD and Intel ships through the OS update servicing channel. Per the November 2025 SFI report, Surface UEFI firmware and Windows drivers are being rewritten in Rust [@sfi-nov-2025-windows].

Cryptography. SymCrypt-OpenSSL ships with ML-KEM and ML-DSA. TLS 1.3 with ML-KEM hybrid key exchange is in SChannel preview. DPAPI-NG envelope-key migration to ML-KEM is in research [@sfi-apr-2025] [@fips-203] [@fips-204].

Cross-platform comparison

The state of the art is plural. Apple has shipped a user-mode Endpoint Security Framework since macOS 10.15 in October 2019 [@apple-esf-docs]; the Windows transition is catching up to an existing platform precedent rather than inventing the architecture. For cloud-attested AI confidentiality, Apple Private Cloud Compute is the published reference design [@apple-pcc]. For kernel-resident EDR with constrained programmability, the Linux eBPF route -- Falco and Tetragon -- is a credible third option [@falco-docs] [@tetragon-docs]. Microsoft maintains an eBPF for Windows project that targets networking-class use cases, not EDR-class collection, so eBPF is not a third Windows option as of May 2026 [@ms-ebpf-for-windows].

Surface	Microsoft 2026 position	Apple peer	Linux peer	Status
Identity-token custody	Managed HSM + Confidential VMs [@azure-managed-hsm]	iCloud Keychain, ADP	AWS CloudHSM [@aws-cloud-hsm]	Live, post-Storm-0558
EDR architecture	WESP user-mode, MVI 3.0 private preview [@wri-jun26-2025]	ESF, GA since macOS 10.15 [@apple-esf-docs]	eBPF: Falco, Tetragon [@falco-docs] [@tetragon-docs]	Private preview
On-device AI confidentiality	Recall: VBS Enclave + TPM + Hello ESS [@recall-davuluri-sept27-2024]	On-device Apple Intelligence	None equivalent	GA May 2025
Cloud-attested AI	M365 Copilot tenant boundary; Confidential Inferencing roadmap	Private Cloud Compute [@apple-pcc]	None equivalent	Apple ahead
Hardware RoT	Pluton (AMD, Intel, Qualcomm) [@pluton-docs]	Secure Enclave Processor	Various (Google Titan, AWS Nitro)	Pluton ahead on PC
Post-quantum	SymCrypt ML-KEM, ML-DSA; TLS preview [@fips-203] [@fips-204]	CryptoKit ML-KEM, iMessage PQ3	Liboqs, OpenSSL providers	Industry parity

Falco's ADOPTERS.md lists Booz Allen Hamilton, Frame.io, GitLab, MathWorks, Secureworks, Skyscanner, Sumo Logic, and Shopify as production adopters as of May 2026 [@falco-adopters]. Earlier write-ups frequently named Google, Netflix, and Pinterest; that list is incorrect against the current file.

Microsoft's distinctive bet is the institution-plus-kernel-architecture-plus-AI-trust-model triple. No peer matches at all three layers simultaneously. Apple has the cleanest user-mode EDR story and the cleanest cloud-attested AI story; it does not have a public equivalent to SFI's institutional commitments at the corporate-governance level. Linux has the most flexible kernel-residency-with-constrained-programmability story for EDR; it has no equivalent to the Recall-style on-device AI feature plane because no Linux desktop ships such a feature at scale.

The state of the art is plural. Three real and live disagreements remain unresolved as of May 2026, and they sit at the heart of where the field goes next.

7. Competing Approaches

Three real and live disagreements as of May 2026. The article's thesis takes a position on the first; the other two are honestly named as open.

Inside the kernel or outside

The first disagreement sits at the heart of the article's thesis. Microsoft and Apple converge on outside-the-kernel as the strategic answer -- WESP on the Windows side [@wri-jun26-2025], the Endpoint Security Framework on the macOS side, generally available since October 2019 [@apple-esf-docs]. Linux's eBPF-based EDR architectures are a third option that combines kernel-residency with constrained programmability -- the eBPF verifier rejects programs that can crash the kernel before they load [@falco-docs] [@tetragon-docs]. CrowdStrike, SentinelOne, and Sophos all have public commitments to the WESP user-mode path while continuing to ship kernel components during the transition [@ms-securityweek-wesp].

The trade-offs are honest. In-kernel sees more, runs faster on the hot paths, and can intervene at lower latency. User-mode cannot crash the OS, can be sandboxed, and trades blast radius for visibility. eBPF tries to take both: kernel-residency speed plus a static verifier that bounds what the program can do.

Architecture	Visibility	Blast radius	Latency	Attestation	Deployment status
Legacy in-kernel third-party	Highest	Whole OS BSOD risk (CrowdStrike-class)	Lowest	KMCS + WHCP	Default through April 2026; cross-signing trust deprecated [@techcommunity-cross-signing]
WESP user-mode (Windows)	High via OS-provided ETW + brokers [@wri-jun26-2025]	User-mode service restart	Higher than kernel-mode	OS-attested user-mode service	MVI 3.0 private preview [@ms-securityweek-wesp]
Apple ESF (macOS)	High via system extensions [@apple-esf-docs]	User-mode extension only	Higher than kernel-mode	macOS notarization	GA since 10.15
eBPF (Linux: Falco, Tetragon) [@falco-docs] [@tetragon-docs]	High; in-kernel programs	Verifier-bounded; cannot crash kernel	Near kernel-mode	None standardized	Production at Booz Allen, GitLab, MathWorks [@falco-adopters]

The article's thesis takes the position that the CrowdStrike proof case has settled the trade-off in favor of out-of-kernel for the general AV and EDR class. The lingering question is whether eBPF-style constrained programmability is a viable third option in the Windows lineage. Microsoft's eBPF for Windows repository targets networking, not EDR collection [@ms-ebpf-for-windows]; nothing in the public roadmap suggests that changes before Part 7.

Hardware-rooted on-device or cloud-attested

The second disagreement sits at the boundary of confidential computing and AI inference. Apple's Private Cloud Compute bets that the heavy AI inference belongs in attested confidential-VM cloud nodes -- five core requirements (stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, verifiable transparency) [@apple-pcc]. Microsoft (Recall, Copilot+ on-device inference) and Google bet on hardware-rooted on-device enclaves; the Recall Generation-3 architecture is the worked Windows example [@recall-davuluri-sept27-2024]. The trade-offs are latency, privacy-by-non-transmission, the hardware-attestation surface, and the harder question of what happens when the model itself becomes sensitive intellectual property the device must protect from the device's own owner.

Whether the AI trust boundary can be formalized at all

The third disagreement is the hardest. Anthropic's published prompt-injection research note acknowledges directly that prompt injection is "far from a solved problem" and that "every webpage an agent visits is a potential vector for attack" [@anthropic-prompt-injection] [@anthropic-claude-chrome]. The structural question is whether the AI-agent-as-trust-principal model can be made architecturally safe at all, or whether the only durable answer is to keep the agent in a strict permission cage along the lines of the iOS App Sandbox model or Win32 App Isolation [@app-isolation]. The article must name this disagreement as live, not pretend it is resolved.

Microsoft's eBPF for Windows repository describes itself as a work in progress to bring existing eBPF toolchains and APIs from the Linux community to Windows [@ms-ebpf-for-windows]. As of May 2026 the project targets networking use cases. It is not yet a Windows-side answer to Falco or Tetragon.

Some bounds in the era are honest disagreements; others are mathematical. The next section walks the limits that cannot be argued away.

8. Theoretical Limits

Some of the era's bounds are not engineering deficits. They are mathematical, physical, or structural -- and naming them honestly is the only way to evaluate the era's architecture without sliding into apologist framing.

The Forshaw bound on Recall

James Forshaw's June 3, 2024 post named a bound that the April 2026 TotalRecall Reloaded disclosure confirmed empirically: any privilege escalation, or any non-security boundary, is sufficient to leak Recall's data because the user account that owns the data is also the principal that runs the AI feature that decrypts it [@forshaw-acl-jun3-2024]. The Generation-3 architecture pushes the key into a VBS Enclave bound to a TPM-released device key gated by Windows Hello ESS [@recall-davuluri-sept27-2024]; what it cannot do is hide the decrypted plaintext from the AI host process that has to render it. Microsoft's own Security Servicing Criteria treats same-user post-authentication as not a security boundary [@msrc-servicing-criteria]. TotalRecall Reloaded attacked exactly that delivery-truck process -- the AIXHost.exe renderer -- and Microsoft determined the technique "operates within the current, documented security design of Recall" [@itnews-totalrecall-reloaded]. The §4.2 vault-and-delivery-truck framing is the empirical anchor for the Forshaw bound's general form.

The trusted-insider-with-physical-access bound on hardware enclaves

No hardware-rooted on-device confidentiality survives the device-physically-compromised attacker over a long enough adversarial window. Pluton, Hello ESS, and VBS Enclaves all raise the cost of attack; they do not eliminate it. The architectural goal is to make the attack expensive enough that mass-scale attacks become uneconomical, not to prove that no attack exists.

The 4096-byte problem in post-quantum signatures

NIST standardized three post-quantum signature families precisely because no single family has both the security-margin and the performance properties needed for every Windows surface. ML-KEM (FIPS 203) is fast but lattice-only [@fips-203]. SLH-DSA (FIPS 205) is hash-based and hedges against future lattice attacks at the cost of signatures large enough to be impractical for many surfaces [@fips-205]. ML-DSA (FIPS 204) is the workhorse but inherits the lattice-attack-class uncertainty SLH-DSA is meant to hedge against [@fips-204].

The hardware bound is concrete. Per FIPS 204 final, ML-DSA-44 produces 2,420-byte signatures, ML-DSA-65 produces 3,309-byte signatures, and ML-DSA-87 produces 4,627-byte signatures [@fips-204-pdf] [@encryptionconsulting-fips204]. The TPM 2.0 Library Specification sets the default command and response buffer at 4,096 bytes (TPM2_MAX_COMMAND_SIZE and TPM2_MAX_RESPONSE_SIZE in the Implementation-Dependent Constants table) [@tcg-tpm2-spec] [@tpm2-tss-types]. The arithmetic is unforgiving: $$2{,}420 < 3{,}309 < 4{,}096 < 4{,}627$$ ML-DSA-44 and ML-DSA-65 fit in a default TPM 2.0 buffer; ML-DSA-87 does not. Any Windows surface that wants TPM-resident ML-DSA-87 signing has to either negotiate larger buffer sizes (vendor-specific) or settle for the smaller parameter set and accept a lower classical-security margin.

The previous iteration of this article reported ML-DSA byte sizes as 2,420 (correctly for ML-DSA-44 but mis-labeled for ML-DSA-65) and 4,595 (incorrectly for ML-DSA-87). The corrected sizes from FIPS 204 Appendix B and the EncryptionConsulting cross-attestation are 2,420 / 3,309 / 4,627 [@fips-204-pdf] [@encryptionconsulting-fips204]. The load-bearing inequality -- ML-DSA-65 fits, ML-DSA-87 does not -- survives the correction.

The AI-agent-judgment bound

No existing formal-verification framework knows how to prove safety properties about an AI agent's decision process. The boundary is, by construction, statistical -- and statistical security boundaries are a new thing in the Windows lineage. The composition Microsoft uses today (Win32 App Isolation as the cage [@app-isolation], Prompt Shields as the input filter [@jailbreak-detection-shields], Groundedness Detection and Task Adherence as the output filter, OS-attested enclaves where confidentiality matters) reduces blast radius. It does not eliminate the class. This is the era's defining open theoretical question.

The Rice's Theorem bound on driver validation

Even WESP cannot guarantee that no future user-mode EDR component will introduce a Channel-File-291-class failure. Rice's Theorem says that no general decision procedure exists for non-trivial semantic properties of arbitrary programs; the WESP architectural fix is blast-radius reduction (kernel-mode crash becomes user-mode service restart), not defect elimination. Naming this honestly avoids the apologist failure mode in which WESP gets framed as a solution rather than a mitigation.

Note: WESP changes the consequence of a vendor data-parsing bug from a kernel BSOD into a user-mode service restart. It does not prevent the bug. The right comparison is not "the bug never happens" but "when the bug happens, what is the blast radius." The CrowdStrike Channel File 291 defect in a WESP-architected world is a vendor process that exits and restarts -- the host stays up.

Some of these limits will be relaxed by future engineering; others will not. The next section asks which are live research and which are accepted physical bounds.

9. Open Problems

Where active research and engineering is happening as of May 2026 -- and where the thesis's open forward questions live.

Whether the user-mode EDR API surface is empirically sufficient for the AV and EDR class. WESP is in private preview as of May 2026 [@wri-jun26-2025]. Whether it can match in-kernel EDR for the BYOVD and rootkit attack class is not yet empirically settled. This is the load-bearing open question for the article's thesis. If WESP cannot deliver visibility-equivalent-to-kernel for the rootkit class, the third-party-AV-in-kernel model has not actually ended -- it has only been administratively constrained. The MVI 3.0 private preview cohort is the empirical test bed; the first public benchmark write-ups should arrive in 2026-2027.

Production deployment of post-quantum identity-token signing. Kerberos PKINIT, OAuth-token JWS, SAML XMLDSig -- Apple, Google, and Microsoft all have public roadmaps; none has shipped at production scale to consumer endpoints as of May 2026. Microsoft's SFI April 2025 progress report names Kerberos PQ migration as a multi-year program [@sfi-apr-2025]; the FIPS 203/204/205 finals from August 13, 2024 are the gating standards [@fips-203] [@fips-204] [@fips-205] [@federal-register-pq].

The agentic-AI persistence attack class. The CVE catalog is beginning to populate (EchoLeak [@nvd-cve-32711], PromptJacking [@koi-promptjacking], ShadowPrompt [@koi-shadowprompt], ZombAIs [@nvd-cve-53773], the Bargury chain [@mbgsec-bargury-pdf]). Microsoft's response surface is Win32 App Isolation expansion plus Edge AI Browser sandboxing plus Prompt Shields plus Distinct Agent Accounts (announced in the November 18, 2025 roadmap post) [@nov18-2025-preparing-next] [@app-isolation] [@jailbreak-detection-shields]. An OS-level "policy on AI agent judgment" primitive is not yet visible in production.

Whether SFI's cultural change compounds. The April 2025 and November 2025 progress reports quantify improvement on the identity-token and signing-key axes [@sfi-apr-2025] [@sfi-nov-2025-windows]. Whether the same compounding occurs on the supply-chain, third-party-dependency, and human-OPSEC axes is the next progress report's load-bearing claim. The Hotpatch metric (81% of enrolled devices compliant within 24 hours of Patch Tuesday) [@sfi-nov-2025-windows] is the most measurable single indicator.

The OpenID Foundation Shared Signals Framework is the cross-vendor standardization vehicle for Continuous Access Evaluation equivalents [@openid-sse]; production-grade CAE-equivalent deployments outside the Microsoft 365 boundary are a 2026-2027 open problem.

Whether the Pluton-vs-discrete-TPM bifurcation gets settled. As of May 2026, Dell, Lenovo, and HP still have public reservations about Pluton-as-TPM on enterprise SKUs; the Pluton-as-TPM configurability flag is the live compromise [@pluton-docs]. The default behavior varies by OEM and SKU.

The forward question. Does the WESP rollout land in time for the 2026 ransomware wave? If WESP private preview hardens into GA before the next CrowdStrike-class incident -- malicious or not -- then the institutional response has matched the threat timeline. If it does not, the era's open question becomes the opening question of Part 7.

If those are the open problems, the question for a working practitioner is: what should you actually do today? The next section answers per surface.

10. Practical Guide

What a Windows platform security practitioner should be doing today, per surface. The thesis is the architectural diagnosis; this section is the operational prescription.

Identity. Move your workloads to the hardened identity SDK; require Continuous Access Evaluation on Conditional Access policies; rotate any unrotated long-lived signing keys; verify your tenant's Entra ID and MSA flow is on the post-SFI signing-key infrastructure [@sfi-apr-2025] [@cae-docs].

Endpoint. Default-on Smart App Control on new builds; enable Personal Data Encryption for user-folder protection; deploy Application Security Reduction rules including the AI-feature exclusions; track WESP private-preview availability if you ship an antivirus or EDR product [@wri-jun26-2025].

AV and EDR. If you operate a Windows fleet, audit your kernel-driver dependency surface against the April 2026 vulnerable-driver-blocking list (the psmounterex.sys family is the named exemplar) [@april-2026-driver-kb] [@driver-block-rules]; verify your AV or EDR vendor has a WESP transition roadmap and an MVI 3.0 commitment [@ms-securityweek-wesp]; budget for a 12-to-24-month transition from kernel-mode to user-mode EDR; instrument Event ID 3077 in the Code Integrity log for blocked-driver visibility [@techcommunity-cross-signing].

AI features. Default-off the AI features that store user content (Recall, Copilot Vision history) until you have an enterprise policy; use the Intune Settings Catalog policies for Recall (AllowRecallEnablement, DisableAIDataAnalysis) [@recall-manage-docs]; evaluate prompt-injection exposure for every browser-integrated and Office-integrated AI agent [@anthropic-prompt-injection]; treat the AI agent's network reach as a Conditional Access surface.

Post-quantum. Audit your TLS, IPsec, code-signing, and key-management surfaces for PQ-migration readiness; track Microsoft's published PQ-migration timelines per surface [@sfi-apr-2025]; do not deploy custom ML-KEM or ML-DSA outside NIST-validated libraries [@fips-203] [@fips-204].

Pluton. Verify your hardware-refresh cycle moves to Pluton-capable silicon (AMD Ryzen 6000+; Intel Core Ultra Series 2 and later; Snapdragon 8cx Gen 3 and X Series) [@pluton-docs]; decide your Pluton-as-TPM configuration policy for new procurement; remember "Pluton present" is not "Pluton enabled" -- confirm OEM-exposed TPM type via Get-Tpm plus BIOS toggle inspection.

Two of those operational steps -- the Pluton-as-TPM status check and the Event ID 3077 monitoring -- are concrete enough to demonstrate. The runnable code blocks below are the verifiable form.

{` // PowerShell on Windows: Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion, ManagedAuthLevel // The JSON below is a representative shape returned by a Pluton-as-TPM machine. const tpm = { ManufacturerIdTxt: "MSFT", ManufacturerVersion: "1.0.0.0", ManagedAuthLevel: "Full", TpmPresent: true, TpmReady: true, };

function classifyTpm(tpm) { if (!tpm.TpmPresent) return "no TPM detected"; if (!tpm.TpmReady) return "TPM present but not ready (clear/initialize via tpm.msc)"; if (tpm.ManufacturerIdTxt === "MSFT") return "Pluton-as-TPM (Microsoft firmware TPM)"; if (tpm.ManufacturerIdTxt === "AMD" || tpm.ManufacturerIdTxt === "INTC") return tpm.ManufacturerIdTxt + " firmware TPM (fTPM); Pluton may be present but not the TPM"; return "discrete TPM by manufacturer " + tpm.ManufacturerIdTxt; }

console.log(classifyTpm(tpm)); `}

{` // PowerShell: Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -FilterXPath "*[System[EventID=3077]]" // Event ID 3077 = a driver was blocked from loading. // Representative subset of fields shown below. const events = [ { Id: 3077, FileName: "psmounterex.sys", PublisherName: "Cross-Signed Legacy CA", Action: "Blocked" }, { Id: 3077, FileName: "vulndrv.sys", PublisherName: "WHCP", Action: "Blocked-Driver-Blocklist" }, { Id: 3076, FileName: "okaydriver.sys", PublisherName: "WHCP", Action: "AuditOnly" }, ];

const blockedLoads = events.filter(e => e.Id === 3077 && e.Action.startsWith("Blocked")); for (const e of blockedLoads) { console.log("BLOCKED:", e.FileName, "(" + e.PublisherName + ")"); } `}

Note: The April 2026 vulnerable-driver-blocking list names psmounterex.sys as the first exemplar [@april-2026-driver-kb]. Any third-party tool that depends on it for backup or storage management will fail until the vendor ships a WHCP-signed replacement. Inventory your driver dependency graph before the April 14, 2026 Patch Tuesday lands across your fleet.

The April 2025 SFI progress report states that Entra ID and MSA access-token signing keys are in hardware-backed security modules with automatic rotation, and that the MSA signing service runs in Azure Confidential VMs [@sfi-apr-2025]. This is a Microsoft-side fact about *Microsoft's own tenants and signing services*, not a customer-tunable setting. For your own tenant, the things you can actually verify are: that Conditional Access policies enable CAE (Entra admin center: Conditional Access > Sessions); that your applications validate the `iss`, `aud`, `kid`, and `tid` claims per RFC 8725 [@rfc-8725]; and that any long-lived application secrets you manage are stored in Azure Key Vault Managed HSM with rotation enabled [@azure-managed-hsm]. There is no customer-visible knob for "use the post-SFI signing service" -- the signing service is upstream of your tenant and is managed by Microsoft.

11. Frequently Asked Questions

Seven load-bearing misconceptions of the era. Each gets a short answer with a back-reference to the relevant section.

No. Microsoft's September 6, 2023 post initially hypothesized that path, then retracted it in an in-place edit on March 12, 2024 with the verbatim sentence: "we have not found a crash dump containing the impacted key material" [@msrc-storm0558-key-acq]. The CSRB report (April 2, 2024, page 17) is equally explicit: "Microsoft has been unable to determine how or when Storm-0558 obtained the MSA key" [@csrb-2024]. The acquisition mechanism is, as of May 2026, unknown. See section 3. No. Windows 11 24H2 reached Copilot+ PC RTM on June 18, 2024 and broad-SKU RTM on October 1, 2024; neither shipped Recall. Recall was pulled from the planned June 18, 2024 Copilot+ PC ship date via an in-place editor's note on the June 7, 2024 Davuluri post -- a five-day pull, not "weeks before launch" [@recall-davuluri-jun7-2024]. Recall returned to the Windows Insider Program on November 22, 2024 and reached general availability on May 13, 2025 [@recall-manage-docs]. See section 4.2. No. Microsoft is *transitioning* AV and EDR to user mode via WESP, which opened in MVI 3.0 private preview in July 2025 [@wri-jun26-2025] [@ms-securityweek-wesp]. Microsoft is *separately* deprecating the legacy Cross-Signing Program in the April 14, 2026 Windows security update, beginning in evaluation mode with a 100-runtime-hour and 2-or-3-restart criterion [@techcommunity-cross-signing]. No public document names a hard categorical ban date. WHCP-certified kernel drivers continue to load. See section 4.3. No. PatchGuard prevents in-kernel patching of protected kernel structures by other in-kernel code. It does nothing about a signed, KMCS-trusted, third-party driver loading malformed configuration data into a kernel-resident process -- the CrowdStrike Channel File 291 pattern [@crowdstrike-rca-pdf]. The vendor's own data pipeline is the failure surface PatchGuard was never designed to cover. See section 4.3. The honest answer: SFI has produced measurable deliverables on identity and signing-key custody. The April 2025 report quantifies the identity-SDK validation lift from 73% to 90%, the MSA signing-key move to hardware-backed security modules with automatic rotation, and the MSA signing service migration to Azure Confidential VMs [@sfi-apr-2025]. The September 2024 report formalizes the executive-compensation tie-in [@sfi-sept-2024]. Whether the same compounding occurs on the supply-chain and human-OPSEC axes is the open empirical question. The institutional change is real; whether it durably shifts the security culture is still being measured. See sections 4.1 and 9. No. Pluton can be used *as* a TPM or *with* a discrete TPM. The configuration is OEM-determined and per-SKU [@pluton-docs]. "Pluton present" is not the same as "Pluton acting as TPM"; confirm via `Get-Tpm` and BIOS toggle inspection. See section 4.5. No. SQL Server 2019 Always Encrypted with secure enclaves, generally available November 4, 2019, is the substrate precedent [@sql-always-encrypted-enclaves]. The correct narrower claim is that Recall is the first VBS-Enclave deployment in the Windows desktop shell to face sustained adversarial review by named external researchers. See section 4.2.

Key idea: The 2023-2026 era is the first in NT's history in which the layer above the OS -- the institution's own identity-token custody, the third-party kernel-mode security vendor, and the AI feature application plane -- became the load-bearing security boundary under public scrutiny while the OS layer kept hardening. SFI, WESP, the Recall Generation-3 architecture, and the April 14, 2026 Cross-Signing trust deprecation are Microsoft's first sustained engineering re-architecture of all three soft spots in parallel. Whether the response lands in time for the 2026 ransomware wave is the open forward question of Part 7.

The 2006-2009 EU-engagement settlement was an honest engineering compromise of its time -- the AV industry needed a sanctioned kernel path; Microsoft needed PatchGuard not to be antitrust-actionable; customers needed both. The compromise survived eighteen years because the failure mode the era worried about was the malicious kernel-resident driver, and KMCS plus the Vulnerable Driver Blocklist eventually contained that mode. What it never tested was a non-malicious data-parsing bug in a sanctioned, signed driver at fleet scale. The morning of July 19, 2024 ran that test once. The verdict came in twenty bytes.

Forged from 2016: How Storm-0558 Turned One Stolen Signing Key into U.S. Government Email Access

noreply@paragmali.com (Parag Mali) — Thu, 28 May 2026 00:00:00 GMT

**In summer 2023, a stolen Microsoft consumer signing key from 2016 was used to forge cryptographically valid tokens that read the email of U.S. Commerce Secretary Gina Raimondo, U.S. Ambassador to China Nicholas Burns, Congressman Don Bacon (R-NE), and approximately 60,000 messages from 10 State Department accounts.** The cloud provider did not detect the breach -- the State Department did, on June 15, 2023, by spotting an unfamiliar `ClientAppID` in Microsoft 365 Purview audit logs. Three years on, Microsoft cannot publicly explain how the key was stolen. The Cyber Safety Review Board called the intrusion "preventable" and Microsoft's security culture "inadequate"; Microsoft's Secure Future Initiative now custodies signing keys in hardware security modules and Azure Confidential VMs and validates 90% of Entra ID tokens for Microsoft apps with a hardened SDK -- a four-for-four mapping to the four ways the pre-incident architecture failed at once.

1. A 2016 Key That Forged 2023 Government Email

On June 15, 2023, an analyst at the U.S. State Department's Security Operations Center was sifting through MailItemsAccessed events in Microsoft 365 Purview audit logs when something did not fit. A ClientAppID was reading mailboxes that did not match any application the State Department ran. The tokens that ClientAppID had presented to Exchange Online were cryptographically valid. They had been signed by a key Microsoft itself had published. Just not in 2023.

The certificate for that key was issued April 5, 2016. It had expired April 4, 2021 [@wiz-storm0558]. And per Microsoft's own admission to the Cyber Safety Review Board nine months later, nobody at Microsoft can publicly tell you how Storm-0558 got hold of it [@csrb-report-2024; @msrc-key-acquisition].

The State Department notified Microsoft on June 16, 2023 [@csrb-report-2024]. The Cybersecurity and Infrastructure Security Agency was looped in within days. On July 11, 2023, Microsoft published its first public mitigation post, attributing the campaign to a China-based actor it called Storm-0558 and reporting that approximately 25 organizations were affected [@msrc-storm0558-jul11]. Three days later, the Microsoft Threat Intelligence team published a longer technical analysis confirming the same actor had used "forged authentication tokens" beginning May 15, 2023 [@ms-security-jul14].

The Board finds that this intrusion was preventable and should never have occurred. The Board also concludes that Microsoft's security culture was inadequate and requires an overhaul. -- Cyber Safety Review Board, April 2, 2024 [@csrb-report-2024]

The plain English of what happened is this. Storm-0558 had stolen one private signing key. By the construction of Microsoft's identity infrastructure, that key was authoritative for the consumer-grade Microsoft Account (MSA) issuer -- the same issuer that signs tokens for @outlook.com, @live.com, Xbox accounts, and personal applications. The actor used the key to mint OpenID Connect access tokens that named enterprise mailboxes as their target. Those tokens should not have been accepted by Exchange Online, because Exchange Online is an enterprise resource and the signing key was a consumer issuer's. But they were accepted.

Once accepted, they granted read access to the named mailboxes. For six weeks, that access was active and uninterrupted. The Cyber Safety Review Board's final tally puts the harvest at approximately 60,000 emails from 10 State Department accounts and a total of 22 enterprise organizations along with approximately 503 related personal accounts [@csrb-report-2024]. Identified individual victims include U.S. Commerce Secretary Gina Raimondo, U.S. Ambassador to China Nicholas Burns, and U.S. House of Representatives accounts that publicly include Congressman Don Bacon (R-NE) [@csrb-report-2024].

A class of attacks in which an adversary obtains an identity authority's private signing key and uses it to mint cryptographically valid credentials (tokens, tickets, or assertions) that no downstream defender can distinguish from those issued by the legitimate authority. MITRE catalogs the technique family as T1606, "Forge Web Credentials," with sub-techniques for web cookies (T1606.001) and SAML tokens (T1606.002) [@mitre-t1606; @mitre-t1606-002].

Four facts about this incident are what make it architecturally important, and each is a separate failure with its own remediation path. The first is that the stolen key was seven years old. It was issued in 2016 and had not been rotated since [@csrb-report-2024]. The second is that the validator on the enterprise side accepted a token signed by the wrong issuer for an enterprise resource. The third is that the cloud provider did not detect the breach -- a paying customer did, on routine threat-hunting against an audit log the customer had to pay extra to collect. The fourth, perhaps most uncomfortable, is that the cloud provider does not know how its own root signing secret was stolen.

Microsoft published a hypothesis in September 2023 (a crash dump exfiltrated through a compromised engineering account) [@msrc-key-acquisition], partially walked it back in March 2024 ("we have not found a crash dump containing the impacted key material") [@msrc-key-acquisition], and three weeks later the CSRB concluded definitively: Microsoft "has been unable to determine how or when Storm-0558 obtained the MSA key" [@csrb-report-2024].

The "Storm-0558" name is Microsoft's. Microsoft adopted a weather-themed taxonomy on April 18, 2023, in which Storm-NNNN denotes a developing actor pending attribution and family names like "Typhoon" indicate origin -- in this case, China [@ms-learn-actor-naming]. After attribution work matured, Microsoft renamed the group "Antique Typhoon" in August 2024 [@ms-security-jul14].

Each of those four facts is the closure of a separate architectural failure, and each is fixable in isolation. So how did all four fail at once? That answer begins with where the attack class came from, and why it had been written about for six years before it caught the State Department's attention.

2. The Lineage of Signing-Key Forgery

Storm-0558 is not a novel attack class. The primitive it instantiates -- steal an identity authority's signing secret, mint cryptographically valid tokens that no downstream defense can distinguish from legitimate ones -- has a six-year published lineage and an even longer informal one. The most important word in the previous sentence is "lineage." Each generation widened the trust domain the forgery primitive defeats.

Storm-0558 is the cloud-provider generalization of a technique whose first formal name dates to November 2017, when Shaked Reiner of CyberArk Labs published a CyberArk Threat Research post titled Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps [@reiner-golden-saml]. Reiner named the technique deliberately, riffing on Benjamin Delpy's earlier "Golden Ticket" name for the Kerberos analog.

Walking the lineage forward in order from oldest primitive to Storm-0558 is the cleanest way to see what is genuinely new in 2023.

timeline title Lineage of Identity-Authority Forgery 1997 : Pass-the-Hash : User credential reuse, host scope 2014 : Golden Ticket (Mimikatz) : krbtgt theft, AD forest scope 2017 : Golden SAML (Reiner / CyberArk) : AD FS Token-Signing key, federation scope 2020 : Sunburst SAML token forgery : Customer federations via supply chain 2023 : Storm-0558 : Cloud provider's own MSA signing key

Generation one is Pass-the-Hash, first published as working exploit code by Paul Ashton on NTBugtraq in April 1997 (a modified Samba SMB client whose orig_client.c diff is dated Tue Apr 8 17:27:29 1997) [@ashton-pth-1997] and described in Microsoft's own canonical whitepaper as the user-level baseline that all later generations replaced [@ms-pth-paper; @mitre-t1550-002]. The attacker captures the NTLM hash from a host they have already compromised and re-presents it to other Windows hosts. No password is recovered, no signing infrastructure is touched.The CIFS/SMB authentication exchange that PtH abuses passes the NTLM hash as a cryptographic proof of knowledge without ever needing the plaintext password -- which is why hashing the password did not reduce the attacker's working set. The blast radius is a single Windows host or, when paired with lateral movement, a constellation of hosts that share a credential. The trust authority being attacked is the user account, and the prerequisite is local code execution.

Generation two is Golden Ticket, attributed to Benjamin Delpy's mimikatz tool from approximately 2014 [@mitre-t1558-001; @mimikatz-kerberos; @crowdstrike-golden-ticket]. Where Pass-the-Hash forges user credentials, Golden Ticket forges Kerberos Ticket-Granting Tickets by signing them with the stolen krbtgt account's password hash from a domain controller. A forged TGT carries arbitrary PrivAttrCert SIDs, so the attacker can claim membership in any AD group, including Domain Admins. The blast radius widens from a host to an entire Active Directory forest. The trust authority being attacked is the forest's Key Distribution Center, and the prerequisite is extracting the krbtgt hash from a domain controller -- a one-time theft that, until krbtgt is rotated, lets the attacker mint TGTs indefinitely.

Generation three is Golden SAML, the technique Reiner named in 2017 [@reiner-golden-saml]. The vector is the same shape: steal the AD FS Token-Signing private key, forge SAML assertions, present them to any cloud Service Provider federated to that AD FS. Quoting Reiner verbatim, the technique "enables an attacker to create a golden SAML, which is basically a forged SAML 'authentication object,' and authenticate across every service that uses SAML 2.0 protocol as an SSO mechanism." The blast radius widens again: from a single forest to every cloud Service Provider configured to trust that customer's AD FS -- Azure, AWS, vSphere, and any SaaS in the customer's SSO catalog. CyberArk published a proof-of-concept tool, shimit, the same year [@shimit].

The naming lineage is deliberate. Delpy's "Golden Ticket" was an explicit reference to the visual of unlimited, never-expiring access; Reiner's "Golden SAML" was equally explicit homage to Delpy. Reiner notes the connection openly in the original CyberArk post: "the golden SAML name may remind you of another notorious attack known as golden ticket, which was introduced by Benjamin Delpy who is known for his famous attack tool called Mimikatz" [@reiner-golden-saml]. Storm-0558 is the unnamed fifth generation.

Generation four is Sunburst, December 2020. The Russian Foreign Intelligence Service (SVR) compromised the SolarWinds Orion build pipeline, planted a backdoor in Orion updates, and from that initial-access foothold used Golden SAML against the federations of victim organizations to mint forged SAML tokens for Microsoft 365 and other federated SaaS [@aa20-352a; @cyberark-golden-saml-revisited]. Microsoft itself was among the victims. The company's February 2021 final update acknowledged that SVR had accessed source code for "small subsets" of Azure, Intune, and Exchange components but found "no evidence of access to production services or customer data," and reported that the actor was not able to gain access to privileged credentials or apply the SAML forgery techniques against Microsoft's own corporate domains [@msrc-solorigate-final].

The blast radius pattern of Sunburst was: one supply-chain compromise on the way in, then Golden SAML in each federation once inside. CISA attributed the SAML-token forgery technique explicitly in AA20-352A and named the SVR as the responsible actor in an April 2021 update to the advisory [@aa20-352a].

A 2017 attack technique by which an adversary who possesses the AD FS Token-Signing private key forges SAML 2.0 assertions and authenticates as any user to any cloud Service Provider that federates with that AD FS. Cataloged by MITRE as T1606.002 ("Forge Web Credentials: SAML Tokens") and named by Shaked Reiner of CyberArk Labs in deliberate homage to Mimikatz's "Golden Ticket" [@mitre-t1606-002; @reiner-golden-saml].

Generation five -- the one this article is about -- is Storm-0558. The earlier four generations had one structural property in common: the trust authority being forged was the customer's identity infrastructure. The customer's NT account database, the customer's domain controller, the customer's AD FS Token-Signing certificate, the customer's Orion-installed SolarWinds environment that fed those things. Sunburst, when it reached Microsoft, attacked Microsoft as a customer of its own corporate AD FS infrastructure. Storm-0558 attacked something different: the cloud provider's own consumer identity-provider signing key. The trust authority being forged was Microsoft's MSA issuer -- the consumer-tier signing infrastructure that Microsoft itself operates as a service.

The blast radius of an attack of this shape is bounded only by where the relying-party validation libraries accept the cloud provider's issuer. In Storm-0558's case, as Wiz Research showed in independent analysis, the key could in principle have signed tokens accepted by Outlook.com, SharePoint, Teams, OneDrive, and any third-party multi-tenant application using Microsoft's converged v2.0 endpoint that accepts "Sign in with Microsoft" for personal accounts [@wiz-storm0558]. The publicly documented exploitation was scoped to Exchange Online and Outlook Web Access, but, as Wiz's authors put it, "the compromised signing key was more powerful than it may have seemed" [@wiz-storm0558].

So Storm-0558 is generation five in a chain whose earlier four generations had been documented, named, simulated, and operationalized for the better part of a decade. Sunburst still required compromising one customer's federation at a time. Storm-0558 compromised something different: Microsoft's own consumer identity provider. To understand how a consumer signing key could authenticate against an enterprise mailbox, we have to look at three architectural decisions Microsoft made between 2016 and 2022 -- and how they layered on top of an unrotated 2016 key.

3. The Architecture Before Storm-0558

Two parallel Microsoft identity providers operate under one corporate roof. The first is the consumer Microsoft Account (MSA) issuer, which signs tokens for @outlook.com, @live.com, Xbox accounts, and the personal-account flavor of "Sign in with Microsoft." The second is the enterprise Microsoft Entra ID issuer (formerly Azure AD), which signs tokens for @contoso.com-style workforce identities under a per-tenant issuer URL. Each issuer has its own signing keys and its own JWKS endpoint -- the public-key distribution endpoint that relying parties fetch to validate signatures.

These are separate systems with separate signing infrastructure, but the cross-tier distinction is finer than "different domains." Both the MSA and Entra ID issuers publish their v2.0 OpenID Connect tokens under the same login.microsoftonline.com host. What distinguishes them is the tenant GUID inside the issuer URL. The MSA "consumers" tenant has the well-known GUID 9188040d-6c67-4c5b-b112-36a304b66dad, so its v2.0 OIDC issuer is https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 (verifiable live from the MSA OpenID Connect discovery document) [@msa-oidc-discovery]. Every Entra ID enterprise tenant has its own tenant GUID, so its issuer is https://login.microsoftonline.com/{enterprise-tenant-GUID}/v2.0.

Microsoft's own July 11, 2023 disclosure put it plainly: "MSA (consumer) keys and Azure AD (enterprise) keys are issued and managed from separate systems and should only be valid for their respective systems. The actor exploited a token validation issue to impersonate Azure AD users and gain access to enterprise mail" [@msrc-storm0558-jul11]. The architectural sentence to hold on to from that paragraph is should only be valid for their respective systems. The next 1,500 words are an explanation of how that "should" became "did not."

A compact, URL-safe token format consisting of three Base64URL-encoded parts: a header (algorithm and key identifier), a payload (claims like `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration), `nbf` (not-before), and application-specific claims), and a signature over the header and payload. JSON Web Token Best Current Practices are codified in IETF RFC 8725 [@rfc-8725]. JWKS is the *JSON Web Key Set* a token issuer publishes at a well-known URL. Each key in the set carries a `kid` (Key ID). The JWT header names a `kid`, and the relying party uses it to locate the matching public key from the issuer's JWKS for signature verification. RFC 8725 specifies that "validators MUST be able to handle JWTs signed with different algorithms" and that the `kid` lookup is bound to a specific issuer's keys, never to a global key namespace [@rfc-8725].

To understand the cross-tier flaw, walk a standard JWT validation flow in order. Step one: the relying party parses the JWT header to read the alg and kid. Step two: it looks up the issuer's JWKS using the iss claim from the payload (or a hard-coded issuer URL it trusts). Step three: it locates the public key whose kid matches the one in the header. Step four: it verifies the signature using that key.

Step five is the one that matters. The validator checks the payload claims: iss must match the trusted issuer for this resource, aud must match this resource's identifier, exp and nbf must bracket the current time, and any application-specific tenant or scope claims must be enforced [@rfc-8725]. RFC 8725 (the IETF JWT Best Current Practices, published February 2020) makes step five mandatory: "the issuer of the JWT MUST be validated to ensure that it is from a trusted source." When step five does not happen, the entire validation reduces to "the signature is valid for some key the issuer signed something with," which is not the same as "the token authorizes the bearer for this resource."

flowchart LR A["JWT arrives at relying party"] --> B["Parse header: alg, kid"] B --> C["Fetch issuer JWKS by iss claim"] C --> D["Find key by kid"] D --> E["Verify signature with public key"] E --> F["Check iss, aud, tenant, scope, exp, nbf"] F --> G["Allow request"] F -.->|"omitted in OWA path before 2023"| G Microsoft Account is the consumer identity provider for `@outlook.com`, `@live.com`, Xbox, and personal-account "Sign in with Microsoft" flows. Its v2.0 OpenID Connect issuer is `https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0` -- the MSA "consumers" tenant on the shared `login.microsoftonline.com` host [@msa-oidc-discovery].

Microsoft Entra ID (formerly Azure Active Directory) is the enterprise identity provider for tenant-scoped workforce identities like user@contoso.com, with per-tenant issuers of the form https://login.microsoftonline.com/{enterprise-tenant-GUID}/v2.0 on the same host. The cross-tier distinction is therefore tenant-GUID-vs-tenant-GUID inside the same v2.0 URL template, not domain-vs-domain. The two systems are operationally separate with separate signing keys, separate JWKS endpoints, and separate intended audiences [@msrc-storm0558-jul11; @msa-oidc-discovery].

Now bring in the three architectural decisions that lined up to create Storm-0558's window.

The first decision, in September 2018, was that Microsoft published a converged metadata endpoint. Microsoft's own September 6, 2023 retrospective is explicit about the motivation: "To meet growing customer demand to support applications which work with both consumer and enterprise applications, Microsoft introduced a common key metadata publishing endpoint in September 2018" [@msrc-key-acquisition].

The point of the converged endpoint was developer ergonomics. Build one app, use one validation library, accept users from @outlook.com and @contoso.com alike. Internally, the shared validation library would verify signatures against either issuer's keys, and was documented to expect that callers would add their own issuer and scope checks for resource-side authorization decisions.

The September 2018 decision was a developer-experience choice, not a security choice. Microsoft was responding to demand for unified consumer/enterprise app flows. The validation library it shipped could check iss, but the design left that decision to the caller -- under the (reasonable, at the time) assumption that each caller best understood which issuers should be acceptable for its resource. The flaw Storm-0558 exploited was not a bug in the library; it was a missing line in a caller five years later.

The second decision, in 2022, was that Microsoft's mail platform team migrated Outlook Web Access (OWA) and Exchange Online's token-validation code to consume that converged endpoint without adding the issuer and scope check the library expected callers to add.

The exact verbatim language from Microsoft's September 6, 2023 retrospective is worth quoting: "Developers in the mail system incorrectly assumed libraries performed complete validation and did not add the required issuer/scope validation. Thus, the mail system would accept a request for enterprise email using a security token signed with the consumer key" [@msrc-key-acquisition]. Two systems, both built by Microsoft, with a shared interface contract that was undocumented at the precise boundary that mattered.

The third precondition, which is not strictly a 2018-or-2022 decision but rather a non-decision running through both, is that the 2016 MSA consumer signing key had never been rotated. The CSRB report is direct about why: "Microsoft automated the key rotation process in the enterprise system with the intent for the consumer MSA system to follow and use the same technology, but it had not done so in the consumer MSA system before the intrusion" [@csrb-report-2024].

The MSA system had previously rotated keys manually. In 2021, the CSRB notes, Microsoft paused manual MSA rotation after a manual-rotation-related cloud outage, and the automated replacement never arrived. The 2016 key stayed live for seven years. Its certificate, per Wiz Research's recovery from public JWKS history, was issued April 5, 2016, and expired April 4, 2021 -- which means even after the certificate's nominal expiry, the underlying signing key was still accepted by the converged validator [@wiz-storm0558].

Key idea: By 2022, the four preconditions for Storm-0558 were all in place. (1) An unrotated 2016 MSA consumer signing key. (2) Software-resident key custody (no HSM) for that key. (3) A 2018 converged metadata endpoint whose validation library left issuer/scope enforcement to callers. (4) A 2022 mail-platform migration onto that endpoint with the issuer/scope check missing. All that was needed was the attacker holding the key.

These three (or four, counting the implicit software custody) factors did not align by accident. Each was an independent decision, made for an independent reason, by people working in good faith on different timelines. Developer ergonomics in 2018, mail-platform consolidation in 2022, a paused rotation process in 2021. None of them was a security decision. None of them was a vulnerability when shipped in isolation.

The 2018 library would happily check iss if the caller asked it to. The 2022 mail platform would happily reject a consumer-key-signed token if the integrator had added the check. The unrotated key would not have mattered if either of the validation layers had enforced separation. Storm-0558 required all four to be wrong at once. They were.

4. The Attack Chain, Step by Step

The attack itself happened in five operational stages. The forged-token activity began May 15, 2023 and continued until Microsoft remediated on July 5, 2023, after the State Department's notification on June 16 [@ms-security-jul14; @csrb-report-2024]. Forty-one days.

By the time the campaign was contained, Storm-0558 had been inside the cloud's identity infrastructure long enough to harvest tens of thousands of emails. What the attacker did is now mostly understood. What is not understood is how the attacker got the key in the first place.

sequenceDiagram participant Atk as Storm-0558 participant Key as 2016 MSA signing key participant MSA as MSA issuer infra participant OWA as OWA, Exchange Online participant Mbx as Target mailboxes Note over Atk,MSA: Mechanism unknown. Microsoft cannot determine how the key was obtained. MSA-->>Atk: 2016 MSA signing key, by May 2023 Atk->>Key: Forge OIDC JWT, kid for 2016 key Key->>OWA: Token signed by MSA issuer, claims target enterprise user OWA->>OWA: Verify signature, omit iss and aud check OWA->>Mbx: Authorize as enterprise user Mbx-->>Atk: MailItemsAccessed events, 60,000 emails over 6 weeks

4.1 Key acquisition (mechanism unknown)

What is known is that by May 15, 2023, Storm-0558 held a valid 2016 MSA signing key. What is unknown -- and this is the most important sentence in the entire article -- is how the actor obtained it.

Microsoft's September 6, 2023 retrospective offered a four-step hypothesis. A signing system crashed in April 2021. The crash generated a memory dump. The signing key was supposed to be redacted from such dumps, but a race condition allowed it through. The dump was supposed to remain inside an air-gapped production-isolated network but was migrated to the corporate debugging network. There, the credentials of a Microsoft engineer's account were compromised by an actor consistent with Storm-0558's tradecraft, and the dump was exfiltrated.

That was the September 2023 story.

Note: Microsoft updated its September 6, 2023 retrospective on March 12, 2024 to add the following: "The blog below states that the actor access may have resulted from a crash dump in 2021, but we have not found a crash dump containing the impacted key material" [@msrc-key-acquisition; @msrc-key-acquisition-archive]. The artifact (crash dump containing the key) was not found. The general shape of the hypothesis -- operational error plus compromised engineering account -- is retained as the leading hypothesis (see the immediately-following PullQuote for Microsoft's verbatim framing of what survives the retraction), not as a confirmed mechanism.

Three weeks after that retraction, the Cyber Safety Review Board published its report. The CSRB's finality on the question is uncompromising: Microsoft "has been unable to determine how or when Storm-0558 obtained the MSA key" [@csrb-report-2024]. The Board's investigation, which ran for seven months and drew on interviews with Microsoft engineers, the State Department, CISA, and independent reviewers, did not yield a confirmed mechanism. It identified candidate paths -- crash-dump migration, debugging-environment access, a compromised engineering account -- but found no artifact that closed any of them.

The epistemic shape of this finding deserves naming. Three years on, the cloud provider responsible for authenticating billions of users cannot publicly tell its customers how the most security-critical secret in its consumer identity stack was stolen.

That is not a minor footnote. As we will see in Section 7, it shapes Microsoft's entire architectural response: every Secure Future Initiative commitment about hardware-backed key custody, automatic rotation, and confidential signing has to defeat plausible mechanisms because the actual one cannot be enumerated.

Our leading hypothesis remains that operational errors resulted in key material leaving the secure token signing environment that was subsequently accessed in a debugging environment via a compromised engineering account. -- Microsoft Security Response Center, March 12, 2024 update to the September 6, 2023 Storm-0558 retrospective [@msrc-key-acquisition]

4.2 Token forgery

With the private key in hand, forging an OpenID Connect access token is mechanical. The header names the algorithm Microsoft uses (RS256, RSA signature with SHA-256 padding, in this case) and the kid of the 2016 key. The payload claims identify the target user (sub), the target tenant where applicable, the requested audience (Exchange Online's resource URI), and validity timestamps.

The actor signs the header-and-payload with the stolen private key, Base64URL-encodes the three parts, and joins them with periods. The result is a valid JWT, indistinguishable from one Microsoft itself would mint. Why? Because the cryptographic verification any relying party performs is, by construction, "does this signature decrypt with the public key whose kid is named in the header?"

Storm-0558 forged tokens against both the legitimate MSA scope (Outlook.com mailboxes belonging to consumer accounts -- the intended use of the 2016 key) and the illegitimate cross-tier scope (enterprise Exchange Online mailboxes belonging to organizations like the U.S. State Department, which were never the intended audience for an MSA-signed token). The legitimacy of the signature did not change between the two. The difference was on the relying-party side.

4.3 The cross-tier validation flaw

This is the bug. The OWA and Exchange Online code path that received an incoming token, parsed the header, fetched the public key from the converged metadata endpoint, and verified the signature did not, after a successful signature verification, separately enforce that the token's iss claim matched an issuer authorized for enterprise email.

The shared validation library was perfectly capable of performing the issuer check, but only if asked. The OWA/Exchange Online caller did not ask.

A v2.0 MSA token's `iss` claim is `https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0` -- the MSA "consumers" tenant on the shared `login.microsoftonline.com` host, with the well-known consumers tenant GUID [@msa-oidc-discovery]. A v2.0 Entra ID token's `iss` claim is `https://login.microsoftonline.com/{enterprise-tenant-GUID}/v2.0`, with the enterprise customer's own tenant GUID. The cross-tier distinction is tenant-GUID-vs-tenant-GUID *inside the same URL template*, not domain-vs-domain.

These are different issuers, with different signing keys and intended audiences. An enterprise resource like a State Department mailbox should accept only the second form, scoped to the State Department's tenant. Storm-0558's forged tokens presented the first form (the MSA "consumers" iss) for resources that should have accepted only the second. The validator did not notice the mismatch because it never read past the signature verification step.

The fix is one explicit iss/aud check on the relying-party side -- the joint mandate RFC 8725 Sections 3.8 and 3.9 have made mandatory since February 2020 (Section 3.8 covers iss and sub; Section 3.9 covers aud) [@rfc-8725; @rfc-8725-html].

The fix Microsoft eventually shipped is described in its own September 6, 2023 retrospective with the verbatim line "this issue has been corrected using the updated libraries" [@msrc-key-acquisition].

Wiz Research, looking at the same flaw from outside, framed the architectural consequence. The actor's compromised key "could have theoretically used the private key it acquired to forge tokens to authenticate as any user to any affected application that trusts Microsoft OpenID v2.0 mixed audience and personal-accounts certificates" [@wiz-storm0558]. The actual exploitation was scoped to email, but the addressable scope was larger.

The private key an identity provider uses to sign authentication tokens it issues. Whoever holds the signing key can mint tokens cryptographically indistinguishable from those issued by the legitimate provider. The security of the identity system, in the absence of independent issuer/scope/tenant validation on the relying-party side, depends entirely on the custody of this key. The CSRB report describes its compromise as the central enabler of Storm-0558 [@csrb-report-2024]. The check, performed by a JWT relying party after signature verification, that the token's `iss` claim matches a permitted issuer for the requested resource and the `aud` claim matches the resource's identifier. RFC 8725 codifies the combined obligation across two adjacent sub-sections: Section 3.8 ("Validate Issuer and Subject") makes `iss` and `sub` validation mandatory, and Section 3.9 ("Use and Validate Audience") makes `aud` validation mandatory [@rfc-8725; @rfc-8725-html]. Skipping either -- as the OWA/Exchange Online path did before mid-2023 -- collapses the security model to "any signature from any issuer the validator knows about is acceptable for any resource."

The function name GetAccessTokenForResource has been widely repeated across secondary coverage of Storm-0558 as the locus of the validation flaw. The name does not appear in any of the four primary sources: Microsoft's July 14, 2023 analysis, the September 6, 2023 retrospective, the CSRB report PDF, or the Wiz Research post. This article therefore describes the flaw functionally, as Microsoft itself did, without naming the function symbol [@msrc-key-acquisition; @csrb-report-2024; @wiz-storm0558].

The single missing check the OWA path needed to make -- and now does -- is mechanical. In pseudocode, the difference is exactly one if-statement:

{` // Pseudocode. Pre-2023 OWA path did the first two steps and skipped the third.

function verifyEnterpriseToken(jwt, tenantId, resource) { const header = parseJwtHeader(jwt); const payload = parseJwtPayload(jwt);

const issuerJwks = fetchJwks(payload.iss); const key = issuerJwks.find(k => k.kid === header.kid); if (!key) throw new Error('unknown kid');

if (!verifySignature(jwt, key)) throw new Error('bad signature');

// The missing steps. RFC 8725 Sections 3.8 and 3.9 require both. const allowedIssuer = 'https:' + '//login.microsoftonline.com/' + tenantId + '/v2.0'; if (payload.iss !== allowedIssuer) { throw new Error('issuer not authorized for this enterprise tenant'); } if (payload.aud !== resource) { throw new Error('audience does not match resource'); }

return payload; }

// Storm-0558's forged token carried payload.iss = 'https:' + '//login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0' // (the MSA consumers tenant). kid: a 2016 MSA key. Signature: valid. Issuer match: never checked. `}

4.4 Mailbox access and exfiltration

With validated tokens, the actor authenticated to Outlook Web Access and to Exchange Web Services as the target enterprise users. Once authenticated, the activity looked like any other authenticated user session: enumerate folders, fetch messages, read attachments.

Storm-0558 selected high-value targets. The CSRB final tally is, again, approximately 60,000 emails from 10 State Department accounts; 22 enterprise organizations in total; approximately 503 related personal accounts [@csrb-report-2024]. Named individual victims publicly include U.S. Commerce Secretary Gina Raimondo, U.S. Ambassador to China Nicholas Burns, and U.S. House of Representatives accounts including Congressman Don Bacon (R-NE), who confirmed in August 2023 that the FBI had notified him his personal and campaign email accounts were among those compromised [@csrb-report-2024].

The campaign ran during what Microsoft characterized as China Standard Time business hours, with a working-hours heat-map pattern visible in the telemetry [@ms-security-jul14]. The duration was at least six weeks of active access: May 15, 2023 to June 16, 2023 from the attacker's earliest documented activity to the State Department's notification, plus an additional ~20 days until Microsoft's July 5 remediation date.

4.5 The broader blast radius (potential, not exploited)

Wiz Research's independent analysis published in mid-2023 made an argument the world had not yet absorbed. The same 2016 MSA signing key could in principle have signed OpenID v2.0 tokens for many more Microsoft services than just email. The Wiz authors enumerated SharePoint, Teams, OneDrive, and any third-party multi-tenant application supporting "Sign in with Microsoft" with mixed-audience personal-account acceptance [@wiz-storm0558].

The framing they wrote -- "if a signing key for Google, Facebook, Okta or any other major identity provider leaks, the implications are hard to comprehend" -- is the right framing [@wiz-storm0558].

There is no public evidence that Storm-0558 exploited the broader scope. The breach the world saw is the breach Microsoft and CISA found by enumerating one specific service's logs. Whether the broader scope was exploited and not detected is, as we will note in Section 10, an unanswered question.

Six weeks of access. Approximately 60,000 State Department emails. The cloud provider did not notice. So who did notice, and how?

5. Why a Paying Customer, Not Microsoft, Caught It

On June 15, 2023, the State Department SOC analyst who first noticed Storm-0558 was performing routine threat-hunting against Microsoft 365 Purview audit logs. The specific event type that surfaced the anomaly was MailItemsAccessed, an audit record that fires whenever a mailbox item is read or fetched. It captures who read it (UserId), from where (ClientIPAddress), with what application (ClientAppID, AppID), and against which item (InternetMessageId and folder).

The detection technique was a baseline-deviation check. The State Department maintained a list of legitimate (ClientAppID, AppID) pairs that historically read mailboxes belonging to its employees. Storm-0558's forged-token sessions presented AppID values that were not on the list.

Two days later, CISA and the FBI published joint advisory AA23-193A formalizing what the State Department had done into a recommended detection methodology. The verbatim language in the advisory: "In Mid-June 2023, an FCEB agency observed MailItemsAccessed events with an unexpected ClientAppID and AppID in M365 Audit Logs. ... The affected FCEB agency identified suspicious activity by leveraging enhanced logging -- specifically of MailItemsAccessed events -- and an established baseline of normal Outlook activity (e.g., expected AppID). The MailItemsAccessed event enables detection of otherwise difficult to detect adversarial activity" [@aa23-193a; @aa23-193a-pdf].

A Microsoft 365 audit event that records every read or fetch operation against a mailbox item. The event captures the user, source IP, client and application IDs, and the message identifier accessed. Because forged-token sessions necessarily use an `AppID` outside an organization's normal application inventory, `MailItemsAccessed` is the highest-signal event class for detecting mailbox-token abuse [@aa23-193a]. A Microsoft 365 audit-log tier that, pre-July 2023, gated several high-value security event classes (including `MailItemsAccessed`) behind a paid add-on. Most federal civilian agencies and many commercial tenants were on Purview Audit (Standard) and did not collect these events. The State Department had paid for Premium and was therefore in a position to detect Storm-0558 from its own telemetry [@aa23-193a; @ms-blog-jul19-recovered]. flowchart TD A["June 15, 2023: State Department SOC analyst
notices unfamiliar ClientAppID in MailItemsAccessed events"] --> B["June 16, 2023: State Department notifies Microsoft"] B --> C["Microsoft compares kid against published MSA
key rotation history, identifies 2016 key"] C --> D["July 11, 2023: Microsoft public disclosure post"] D --> E["July 12, 2023: CISA and FBI publish AA23-193A"] E --> F["July 19, 2023: Microsoft expands free Purview Audit features"] E --> G["July 27, 2023: Wyden letter to DOJ, FTC, CISA"] G --> H["August 11, 2023: DHS announces CSRB cloud review"]

Microsoft's confirmation step came after the State Department's notification, not before. Once notified, Microsoft compared the kid on the suspicious tokens against its own published MSA key rotation history and found that the kid corresponded to a 2016 key whose certificate had expired April 4, 2021 [@wiz-storm0558; @ms-security-jul14]. The signature was cryptographically valid for the 2016 key. The 2016 key should never have signed an enterprise-tier token. Both halves of that statement were true at the same time, and the second half is what told Microsoft this was a key compromise rather than a stolen-credential issue.

The structural fact about this detection -- the one that puts every other event in this article in its proper context -- is that MailItemsAccessed was, pre-incident, a Purview Audit (Premium) tier feature [@aa23-193a]. The State Department had paid for Premium. Most federal civilian agencies and many commercial tenants had not. If the State Department had been on Purview Audit (Standard), the event class that surfaced Storm-0558 would not have been collected at all, and the breach would have run longer and gone wider before anyone noticed. The CSRB report makes this connection explicit: the structural critique that follows in Section 6 is not about one bug or one missing check. It is about the commercial logging-tier structure of cloud identity, and about who is in a position to detect a CSP-level compromise when the CSP itself is not [@csrb-report-2024].

Note: The cloud provider did not catch the breach. A paying customer did, on routine threat-hunting against an audit log the customer had to pay extra to collect. This is the CSRB's harshest single critique, and it is what motivated Microsoft's policy response on July 19, 2023 -- making key Purview Audit (Premium) features, including MailItemsAccessed, free for FCEB customers and most commercial customers [@ms-blog-jul19-recovered; @cisa-statement-free-logs-fixed; @csrb-report-2024].

The detection methodology the State Department used is reproducible in pseudocode. The logic, after audit-log ingestion into a SIEM, is small.

{` // Pseudocode. Assumes MailItemsAccessed events ingested from M365 Purview audit log. // The State Department's pattern: maintain a small allowlist of legitimate AppIDs.

const allowlistedAppIds = new Set([ // populated from your tenant's historical baseline of legitimate mail clients, // approved third-party connectors, M365 services, and authorized integrations '00000003-0000-0000-c000-000000000000', // Microsoft Graph // ... extend with your tenant's specific approved AppIDs ]);

function analyzeEvent(evt) { if (evt.Operation !== 'MailItemsAccessed') return; if (allowlistedAppIds.has(evt.AppId)) return;

// Forged-token sessions necessarily present an AppID outside the baseline. alert({ severity: 'high', reason: 'MailItemsAccessed from unallowlisted AppID', user: evt.UserId, appId: evt.AppId, clientAppId: evt.ClientAppId, sourceIp: evt.ClientIPAddress, messageId: evt.InternetMessageId }); } `}

The State Department SOC analyst who first identified Storm-0558 has not been publicly named in any primary source. The CSRB report describes the detection at the level of the agency. There is good reason for the anonymity, given the operational profile of someone who is, by chance and skill, the first known human to detect a Chinese state-affiliated forgery of a Microsoft signing key.

Microsoft's policy response was rapid and substantive. On July 19, 2023, the Microsoft Security blog announced the expansion. Purview Audit (Standard) customers would get "more than 30 other types of log data previously only available at the Microsoft Purview Audit (Premium) subscription level," with default retention extended from 90 to 180 days, rolling out beginning September 2023 [@ms-blog-jul19-recovered]. CISA's same-day press release confirmed: "Microsoft customers will now have access to expanded cloud logging capabilities at no additional charge ... these additional logging capabilities will now be available at no extra cost to federal government customers and Microsoft commercial customers beginning in September" [@cisa-statement-free-logs-fixed].

The pricing structure that had made the State Department's detection possible only because the State Department paid extra was, eight days after the joint advisory, made part of the baseline.

That is the operational story. But the political story was just starting. On July 27, 2023, Senator Ron Wyden (D-OR) wrote a four-page letter to three federal agencies asking them to investigate Microsoft. Fifteen days later, the Cyber Safety Review Board announced its third-ever review.

6. The Public Reckoning -- CSRB, Retracted Hypothesis, Congressional Testimony

Senator Wyden's letter, addressed to Attorney General Merrick Garland, FTC Chair Lina Khan, and CISA Director Jen Easterly, opened with a comparison: "Microsoft never took responsibility for its role in the SolarWinds hacking campaign" [@wyden-senate-pr; @wyden-senate-letter-pdf]. The letter then enumerated four specific cybersecurity failures it attributed to Microsoft in the Storm-0558 incident.

Quoting Wyden's own characterization from the Senate press release: "Employing a single encryption key that could be used to forge access to consumer, commercial and government customers' private communications; Microsoft's blog post about the hack suggests it did not store high-value encryption keys in a Hardware Security Module ...; Using an encryption key that was valid for 5 years, and was still accepted by Microsoft's software, even though it had expired in 2021, two years before the hack ...; Neither internal nor external security audits detected the security weaknesses that enabled the hack" [@wyden-senate-pr].

The (d) to (e) jump in the political chronology -- from Wyden's July 27 letter to the August 11 DHS announcement -- is, in Wyden's own words, causal. His August 11 statement reads: "I applaud President Biden and CISA Director Easterly for acting on my request for the board to review this recent espionage campaign, including cybersecurity negligence by Microsoft that enabled it ... Had the board studied the 2020 SolarWinds hack, as President Biden originally directed, its findings might have been able to shore up federal cybersecurity in time to stop hackers from exploiting a similar vulnerability in the most recent incident" [@wyden-senate-statement-aug11]. The Senate office's published causal-chain framing matters because it provides the public-record bridge from a single senator's letter to a federal advisory-board review.

6.1 The CSRB's authority and process

The Cyber Safety Review Board exists because President Biden's Executive Order 14028 of May 12, 2021, "Improving the Nation's Cybersecurity," directed DHS to establish a standing board to conduct after-action reviews of significant cyber incidents [@eo-14028]. Storm-0558 was the Board's third review, after Log4j and Lapsus$ [@csrb-program].

On August 11, 2023, DHS Secretary Alejandro Mayorkas announced the Board would conduct a review of "the malicious targeting of cloud computing environments," with the recent Microsoft Exchange Online intrusion as the central case study and a broader scope covering "issues relating to cloud-based identity and authentication infrastructure affecting applicable CSPs and their customers" [@dhs-csrb-announce-archive]. Robert Silvers, DHS Under Secretary for Policy, chaired. Dmitri Alperovitch served as Acting Deputy Chair for this review [@dhs-csrb-report-release].

A public-private federal advisory board established by Executive Order 14028 (May 12, 2021) and standing up in February 2022 to conduct after-action reviews of significant cyber incidents and recommend improvements. The Board's Storm-0558 review, its third (after Log4j and Lapsus$), was announced August 11, 2023 and reported April 2, 2024 [@eo-14028; @csrb-program; @csrb-report-2024].

6.2 The September 2023 hypothesis and the March 2024 retraction

The chronology that matters here is short and worth pinning down precisely. Microsoft published the crash-dump hypothesis on September 6, 2023 [@msrc-key-acquisition]. Microsoft itself updated that post on March 12, 2024 with the retraction-of-the-artifact paragraph quoted earlier in Section 4.1 [@msrc-key-acquisition]. The CSRB report published April 2, 2024 -- three weeks after Microsoft retracted the artifact -- then documented the resulting state of knowledge (verdict quoted in Section 4.1; CSRB page 17) [@csrb-report-2024].

The order matters. Microsoft retracted the artifact first. The CSRB did not force the retraction; it documented the resulting state of knowledge. That sequence is meaningful because it suggests Microsoft's own forensic work, not external pressure, drove the walking-back of the artifact claim.

6.3 The CSRB's findings

The Board's findings, in its own verbatim language, are direct. The Board's page-ii verbatim -- the preventable / inadequate / requires-an-overhaul language quoted in Section 1's opening PullQuote -- sets the frame; page 17 sharpens it: "the cascade of Microsoft's avoidable errors that allowed this intrusion to succeed" [@csrb-report-2024].

The DHS press release surfaced these findings on the day of publication: "the intrusion by Storm-0558, a hacking group assessed to be affiliated with the People's Republic of China, was preventable. It identified a series of Microsoft operational and strategic decisions that collectively pointed to a corporate culture that deprioritized enterprise security investments and rigorous risk management" [@dhs-csrb-report-release].

The report makes 25 recommendations. Of those, 16 apply to Microsoft (4 specific to Microsoft and 12 to all cloud service providers but accepted by Microsoft per Brad Smith's June 2024 testimony) [@brad-smith-2024-06-13]. The structural critique embedded in the recommendations is that the commercial logging-tier structure of cloud identity is itself a security problem, because it delays detection asymmetrically: richly-resourced customers detect compromise; less-resourced customers do not. The free-Purview-Audit shift Microsoft had announced on July 19, 2023 is, in the CSRB's framing, a necessary but not sufficient condition for cloud-identity log access to stop being a per-customer commercial decision.

6.4 Brad Smith's June 13, 2024 testimony

The House Committee on Homeland Security titled its June 13, 2024 hearing "A Cascade of Security Failures: Assessing Microsoft Corporation's Cybersecurity Shortfalls and the Implications for Homeland Security" [@homeland-hearing]. The plural "Failures" was a deliberate framing choice. By the time of the hearing, Microsoft had also publicly disclosed a separate January 2024 intrusion by Midnight Blizzard (the Russian SVR; the same actor as SolarWinds), and the hearing's scope spanned both incidents. Brad Smith, Microsoft's Vice Chair and President, was the witness.

Smith's written and oral testimony opened with the soundbite that defined the hearing's coverage (quoted in the PullQuote below). Smith confirmed Microsoft's acceptance of all 16 applicable CSRB recommendations, identified 18 additional internal objectives beyond the CSRB's scope, and announced that Senior Leadership Team compensation would be tied in part to progress on the Secure Future Initiative [@brad-smith-2024-06-13; @sfi-may-2024].

Microsoft accepts responsibility for each and every one of the issues cited in the CSRB's report. Without equivocation or hesitation. And without any sense of defensiveness. -- Brad Smith, Vice Chair and President of Microsoft, written testimony to the House Committee on Homeland Security, June 13, 2024 [@brad-smith-2024-06-13; @smith-testimony-pdf]

The hearing's plural framing -- "Failures" -- mattered. On January 19, 2024, Microsoft disclosed a separate Midnight Blizzard intrusion that had begun in late November 2023 (approximately four weeks after the November 2, 2023 launch of the Secure Future Initiative) via a password spray against a legacy non-production test tenant, and that exfiltrated email from members of Microsoft's senior leadership team [@msrc-midnight-blizzard-jan-archive]. The March 8, 2024 update added that Midnight Blizzard had reached Microsoft source code repositories and ramped February password sprays to ten times the January volume [@msrc-midnight-blizzard-mar-archive]. By the June hearing, Microsoft was carrying both incidents into the same line of questioning.

Microsoft accepted responsibility. The CSRB asked for an architectural overhaul. The next question is what Microsoft actually built.

7. The Architectural Response -- SFI and the Identity-Plane Re-Architecture

The Secure Future Initiative (SFI) is the corporate vehicle through which Microsoft's post-Storm-0558 architectural changes are reported. The remarkable property of the SFI commitments, viewed against the pre-incident architecture described in Section 3, is that they are surgically targeted: each of the four ways the pre-incident MSA system failed maps to one explicit commitment.

7.1 SFI: launch, expansion, motivation arc

Brad Smith launched SFI on November 2, 2023, with three pillars focused on AI-based cyber defenses, fundamental software engineering advances, and stronger international cyber norms [@sfi-launch-nov-2023]. Charlie Bell expanded it on May 3, 2024 into six pillars: protect identities and secrets; protect tenants and isolate production systems; protect networks; protect engineering systems; monitor and detect threats; accelerate response and remediation [@sfi-may-2024].

Pillar 1's verbatim commitment is the one that maps onto Storm-0558 most directly: "Protect identity infrastructure signing and platform keys with rapid and automatic rotation with hardware storage and protection (for example, hardware security module (HSM) and confidential compute)" and "Adopt more fine-grained partitioning of identity signing keys and platform keys" [@sfi-may-2024].

The motivation arc Smith described in his June 13, 2024 testimony connects the dots. Storm-0558 led to the November 2023 launch. The January 2024 Midnight Blizzard intrusion led to the May 2024 six-pillar expansion. The April 2024 CSRB report led to the integration of CSRB recommendations into SFI. The June 2024 hearing led to SLT compensation being tied to SFI progress [@brad-smith-2024-06-13; @sfi-may-2024].

A multi-year Microsoft corporate program announced November 2, 2023 by Brad Smith, expanded May 3, 2024 by Charlie Bell into six pillars, and reported on quarterly. SFI is the explicit corporate vehicle through which Microsoft commits to and reports progress on the architectural changes recommended by the CSRB after Storm-0558. Its identity-and-secrets pillar names HSM custody, automatic rotation, fine-grained key partitioning, and confidential-compute hosting of signing operations as concrete deliverables [@sfi-launch-nov-2023; @sfi-may-2024].

7.2 HSM-bound key custody plus automatic rotation

This closes the first two ways the pre-incident architecture failed: the software-stored key and the unrotated seven-year-old key. Microsoft's September 2024 SFI progress report's verbatim claim: "We completed updates to Microsoft Entra ID and Microsoft Account (MSA) for our public and United States government clouds to generate, store, and automatically rotate access token signing keys using the Azure Managed Hardware Security Module (HSM) service" [@sfi-sept-2024].

Azure Managed HSM is FIPS 140-3 Level 3, built on the Marvell LiquidSecurity platform, with a multi-partition topology that allows per-tenant key isolation [@azure-managed-hsm].

A tamper-resistant cryptographic device that generates and stores private keys inside a hardware boundary and exposes only signing or decryption operations to its caller. Keys generated inside an HSM cannot be exported -- the device performs the signature itself, returning only the signed output. NIST FIPS 140-3 (published March 22, 2019) defines the certification regime; Level 3 adds tamper-detection and identity-based authentication requirements [@fips-140-3; @azure-managed-hsm].

A separate Microsoft on-server primitive, Azure Integrated HSM, is explicitly framed as a Storm-0558 mitigation. Its overview page reads: "Reduce network round-trips to Azure Key Vault or Managed HSM by performing cryptographic operations locally on the same node as the Virtual Machine ... Protect against memory and crash-dump attacks" within "a FIPS 140-3 Level 3 HSM boundary" on AMD D Series v7 and AMD E Series v7 servers [@azure-integrated-hsm].

The phrase "memory and crash-dump attacks" in the same paragraph as "FIPS 140-3 Level 3" is, in context, an explicit acknowledgement of the threat model Storm-0558 spent eighteen months making famous.

7.3 Signing operations inside Confidential Computing TEEs

This closes the residual that HSM custody alone leaves open: in-use observation by a privileged host operator or administrator. The HSM keeps the key from being extracted at rest. But the signing service that asks the HSM to produce a signature still runs somewhere, in some virtual machine, on a host with operators. Confidential Computing closes that gap by running the signing service inside a Trusted Execution Environment whose memory and CPU state are encrypted with hardware-derived keys that not even the host operator can inspect.

Microsoft's April 2025 SFI report is direct about the change: "we've applied new defense-in-depth protections in response to our Red Team research and assessments, migrated the MSA signing service to Azure confidential VMs, and are migrating Entra ID signing service to the same. Each of these improvements help mitigate the attack vectors that we suspect the actor used in the 2023 Storm-0558 attack on Microsoft" [@sfi-april-2025]. The underlying TEE primitives are AMD SEV-SNP and Intel TDX, implemented in Azure's DCasv5/ECasv5 and DCesv6/ECesv6 confidential-VM SKU families [@azure-conf-compute]. The April 2025 timing was contemporaneous coverage: The Hacker News reported on the same April 21, 2025 progress post the day after [@hackernews-msa-confcompute].

A class of hardware-backed isolation primitives in which a virtual machine's memory and CPU state are encrypted with keys derived from the CPU itself, so that even a privileged host operator with full hypervisor access cannot read the workload's memory in cleartext. AMD's implementation is SEV-SNP (Secure Encrypted Virtualization, Secure Nested Paging); Intel's is TDX (Trust Domain Extensions). Azure exposes both through its DCasv5/ECasv5 and DCesv6/ECesv6 confidential-VM SKU families [@azure-conf-compute].

7.4 Tenant-issuer separation enforced in hardened validation libraries

This closes the third pre-incident failure mode: the cross-tier validation flaw. RFC 8725 Sections 3.8 and 3.9 are the canonical IETF Best Current Practice for the combined iss/aud mandate and have been since February 2020 (Section 3.8 covers issuer and subject; Section 3.9 covers audience) [@rfc-8725; @rfc-8725-html].

The Microsoft-internal response was to consolidate JWT validation across services into a single hardened SDK that enforces the iss/aud check at the library level rather than leaving it to each caller. The quantified rollout numbers from successive SFI progress reports are concrete: "more than 73% of tokens issued by Microsoft Entra ID for Microsoft owned applications" were under hardened-SDK validation by September 2024 [@sfi-sept-2024], rising to "90% of identity tokens from Microsoft Entra ID for Microsoft apps are validated by one consistent and hardened identity Software Development Kit (SDK)" by April 2025 [@sfi-april-2025].

7.5 Logging as a commodity, not a premium

This closes the fourth failure mode: the paid-tier-only audit logging that delayed customer detection. The July 19, 2023 announcement made MailItemsAccessed and 30+ other event classes free for FCEB and most commercial customers [@ms-blog-jul19-recovered; @cisa-statement-free-logs-fixed].

The April 2025 SFI report added a further commitment: "two years of internal security-log retention" [@sfi-april-2025]. This addresses the secondary issue that even when logs are collected, retention windows must outlast typical adversary dwell times.

The four failure modes map to four commitments. Table form makes the alignment unambiguous.

Pre-incident failure mode (Section 3)	SFI commitment that closes it	Source
Software-resident, never-rotated 2016 MSA signing key	Azure Managed HSM custody with automatic rotation for MSA and Entra ID (September 2024)	[@sfi-sept-2024; @azure-managed-hsm]
Privileged host-side observation of in-use signing operations	MSA signing service in Azure Confidential VMs (April 2025); Entra ID signing service in migration	[@sfi-april-2025; @azure-conf-compute]
Cross-tier validation: OWA/Exchange Online did not enforce iss/aud	Hardened identity SDK validating 90% of Entra ID tokens for Microsoft apps (April 2025)	[@sfi-april-2025; @rfc-8725]
Paid-tier-only audit logging delayed customer detection	Free MailItemsAccessed and 30+ event classes from September 2023; 180-day default retention; 2-year internal retention (April 2025)	[@ms-blog-jul19-recovered; @cisa-statement-free-logs-fixed; @sfi-april-2025]

Key idea: Each defensive generation in Microsoft's Secure Future Initiative targets exactly one of the four ways the pre-incident MSA architecture failed. The chain is correctable, not just remediable: Microsoft can name which commitment closes which failure mode. What it still cannot name is how the 2016 key itself was stolen.

flowchart TD A["Token request from MSA-authenticated client"] --> B["MSA signing service in Azure Confidential VM
(SEV-SNP or TDX)"] B --> C["Attestation document from Confidential VM"] C --> D["Azure Managed HSM
(FIPS 140-3 Level 3)"] D -->|"sign with MSA key, rotated automatically"| B B --> E["Signed token to relying party"] E --> F["Hardened identity SDK validates iss, aud, kid, tenant"] F --> G["Resource access granted"]

The architectural response addresses each of the four failure modes one-for-one. But how does this stack against what other major cloud providers publicly document?

8. How Other Cloud Providers Custody Signing Keys

The Storm-0558 attack class is generic. Any identity provider that signs tokens can in principle have its signing key stolen. The honest cross-provider comparison is therefore not "which provider is most secure" -- the public evidence does not support a defensible ranking. It is instead "which architectural property each provider publicly attests to having" for the keys behind its own production identity tokens.

The asymmetry of the table below is itself informative. Microsoft, after Storm-0558, has the most explicit public commitments precisely because it had the most public incident.

Property	Microsoft (post-SFI)	AWS (IAM Identity Center, Cognito)	Google (Workspace, Cloud Identity)	Okta
HSM custody for production IdP signing keys	Yes -- Azure Managed HSM, FIPS 140-3 Level 3 [@sfi-sept-2024; @azure-managed-hsm]	Not publicly disclosed for IdP keys; CloudHSM is a customer primitive [@aws-cloudhsm; @aws-iam-idc-security]	Not publicly disclosed for IdP keys; Cloud HSM is a customer primitive [@gcp-cloud-hsm]	Not publicly disclosed at this granularity
Confidential Compute for signing operations	Yes -- MSA on Azure Confidential VMs (Apr 2025); Entra ID in migration [@sfi-april-2025; @azure-conf-compute]	Nitro Enclaves available as customer primitive; not publicly disclosed for IdP keys [@aws-nitro-enclaves; @aws-nitro-whitepaper]	Confidential Computing available as customer primitive; not publicly disclosed for IdP keys [@gcp-confidential-computing]	Not publicly disclosed
Automatic rotation of IdP signing keys	Yes -- MSA and Entra ID automatic rotation in Azure Managed HSM [@sfi-sept-2024]	AWS KMS default 365-day rotation for KMS keys; IdP rotation cadence not publicly disclosed [@aws-kms-rotation]	Cloud KMS rotation customer-controllable; Google-owned-and-managed model is opaque to customers [@gcp-cloud-hsm]; Workspace SAML cert rotation is admin-driven [@gcp-workspace-saml-cert-fixed]	Not publicly disclosed
Tenant/issuer separation enforced in SDK	Hardened identity SDK validating 90% of Entra ID Microsoft-app tokens (Apr 2025) [@sfi-april-2025; @rfc-8725]	aws-jwt-verify library enforces iss/aud for Cognito tokens [@aws-jwt-verify; @aws-cognito-jwt]	Tink library architecture supports key-set discipline [@gcp-tink]	Not publicly disclosed
Free customer audit logging	MailItemsAccessed plus 30+ event classes free since Sep 2023; 2-year internal retention [@ms-blog-jul19-recovered; @sfi-april-2025]	Standard CloudTrail; per-service audit varies	Workspace audit log; Cloud Audit Logs	System Log; baseline included
Public IdP-signing-key-class incident disclosure	Yes -- Storm-0558 (Jul 2023) and CSRB report (Apr 2024) [@csrb-report-2024]	None in 2023-2026 security bulletins surveyed [@aws-security-bulletins]	None in 2023-2026 security bulletins surveyed [@gcp-security-bulletins]	October 2023 support-system breach; HAR-file session tokens; no IdP-signing-key compromise [@okta-rca-nov3; @okta-recommended-actions]
Customer detected before vendor notified	Yes -- State Department detected Jun 15, 2023, notified Microsoft Jun 16, 2023 [@csrb-report-2024]	--	--	Yes -- Cloudflare detected Oct 18, 2023, contacted Okta before vendor notification [@cloudflare-okta-oct2023]

The right reading of the empty cells in this table is not "AWS and Google are safer than Microsoft." It is "AWS and Google have not publicly disclosed an incident that would force this level of architectural commitment, so we do not know." The Wiz Research framing applies cross-provider: "if a signing key for Google, Facebook, Okta or any other major identity provider leaks, the implications are hard to comprehend" [@wiz-storm0558]. Absence of public disclosure is not absence of risk; it is absence of forced disclosure. Microsoft's transparency, post-CSRB, is the comparison standard not because Microsoft is uniquely vulnerable but because Microsoft has uniquely published.

The Okta October 2023 incident is worth knowing about as a cross-vendor data point precisely because of the structural parallel. On October 18, 2023, Cloudflare detected attacker activity that traced back to Okta and contacted Okta before Okta had notified Cloudflare. BeyondTrust had notified Okta on October 2; the attacker still had access until October 18. Okta's November 3 RCA traced the root cause to a service-account credential stored in an Okta employee's personal Google account [@okta-rca-nov3; @okta-recommended-actions; @cloudflare-okta-oct2023]. Different attack class (support-system access, HAR-file session tokens, not IdP signing keys), but the same vendor-detected-by-customer detection inversion the Storm-0558 story made famous.

For a CISO evaluating any IdP vendor, the four operational questions mapped to the four pre-incident failure modes in Section 3 give a structured RFP. Where is the signing key custodied, and what FIPS certification does the HSM hold? What is the rotation cadence, and is rotation automated? Does the vendor's validation SDK enforce iss/aud separation by default, or does it leave the check to the caller? What audit log events are available to free-tier customers, with what retention?

CSA's Cloud Controls Matrix (CEK and IAM domains) and FedRAMP High SC-12 and IA-5 controls together cover most of these in standardized form, but the CAIQ answers are vendor-self-attested [@csa-ccm; @fedramp].

9. Theoretical Limits

There is one place where the architectural improvements of Section 7 stop. The Storm-0558 threat class lives downstream of a cryptographic identity, and there are limits cryptography itself imposes on what any architecture can do.

9.1 The core asymmetry

Under the standard cryptographic security notion of existential unforgeability under chosen-message attack -- EUF-CMA, first formalized by Goldwasser, Micali, and Rivest in 1988 [@goldwasser-micali-rivest-1988] -- a signature produced by a private signing key sk on a message m is, to any holder of the corresponding verification key vk, indistinguishable from one produced by the legitimate signer. This is not a deployment weakness. It is the definition of "signature." If the verifier could distinguish, the scheme would fail the security property. Formally [@goldwasser-micali-rivest-1988; @boneh-shoup-acc]:

$$\text{EUF-CMA: } \forall \text{ PPT adversary } \mathcal{A}, ; \Pr[\mathcal{A}^{\text{Sign}{sk}(\cdot)}(vk) \to (m^, \sigma^) \text{ with } \text{Vrfy}{vk}(m^, \sigma^) = 1 \land m^* \notin Q] \leq \text{negl}(\lambda)$$

where $Q$ is the set of messages the adversary queried to the signing oracle. The adversary's only path to forging a verifying signature on a fresh message is to learn sk. Once it has sk, every signature it produces is, by construction, valid.

EUF-CMA, *existential unforgeability under chosen-message attack*, is the standard security definition for digital signature schemes. The notion was formalized by Goldwasser, Micali, and Rivest in their 1988 *SIAM Journal on Computing* paper "A Digital Signature Scheme Secure Against Adaptive Chosen-Message Attacks" [@goldwasser-micali-rivest-1988]; the canonical modern openly-accessible textbook treatment is Boneh-Shoup's *A Graduate Course in Applied Cryptography*, Chapter 13, which presents the game-based definition used throughout this section [@boneh-shoup-acc]. Informally: an adversary with access to a signing oracle cannot produce a valid signature on a message it has not previously queried, except with negligible probability. The stronger sibling, sEUF-CMA (strong EUF-CMA), additionally forbids producing a new signature on a *previously-queried* message. Both notions imply that, once the private signing key is leaked, the legitimate signer can no longer be distinguished from the holder of the key by any signature-verifying party. This is what makes signing-key theft so consequential -- and is precisely the assumption that the relying-party-side `iss`/`aud` enforcement of RFC 8725 Sections 3.8 and 3.9 is designed to compensate for when validation, not cryptography, is the only remaining line of defense [@rfc-8725].

The consequence for defenders is that all defensive advantage against signing-key-forgery attacks lives outside cryptographic verification. The seven methods catalogued in Section 7 -- HSM custody, Confidential Compute, automatic rotation, tenant/issuer separation, free audit logging, customer-verifiable attestation (mostly absent at major-CSP scale), and detection by kid/issuer drift -- are exhaustive over the four levers a defender has against a key whose theft is, after the fact, indistinguishable from legitimate use.

9.2 The CSP-monoculture residual

When the identity provider is a multi-tenant cloud service provider, the customer cannot independently audit the provider's key custody. The customer can demand SOC 2 attestations, ISO certifications, and CSA CAIQ answers. Each of these is vendor-self-attested. None is a per-operation cryptographic proof that the signing key the provider used to sign a given token is the one custodied as advertised.

Customer-side prevention of a CSP-side custody failure is impossible by construction. Customer-side detection (the methods in Section 11) is possible. The CSRB called this systemic risk out explicitly in its discussion of cloud-identity infrastructure [@csrb-report-2024].

Key idea: Customer-side prevention of a CSP-side custody failure is impossible by construction. Customer-side detection is possible. Prevention sits entirely on the CSP side. This is the asymmetry the Storm-0558 incident made visible.

9.3 The Microsoft-as-Storm-0558-victim recursion

There is a recursive aspect to Microsoft's position that is worth naming honestly. Microsoft sells controls -- HSM custody, Confidential Compute, hardened SDKs, audit logging -- intended to defend against the attack class Microsoft itself was the highest-profile victim of. Brad Smith's "without equivocation" framing acknowledged the recursion implicitly. The CSRB's framing was harsher: a corporate culture that "deprioritized enterprise security investments and rigorous risk management" was, in the Board's view, what allowed the recursion to obtain [@csrb-report-2024; @dhs-csrb-report-release].

9.4 The upper bound

The aggregate of HSM custody, Confidential Computing, automatic rotation, and tenant/issuer separation raises the attacker's required compromise from "find a key in a debugging artifact" to "simultaneously compromise the Confidential VM build pipeline, do so within the rotation window, and bypass the HSM access control or extract a per-key signing oracle." Each is individually possible. Jointly they are several orders of magnitude harder than the pre-Storm-0558 baseline. This is not a theoretical proof of security; it is empirical defense in depth.

Imagine the cleanest possible customer-side defense. The customer subscribes only to providers that publish FIPS 140-3 Level 3 certifications, audit reports, and CAIQ answers. The customer pins acceptable issuers in their relying-party validators. The customer monitors for `kid` drift in tokens. Each of these reduces the *detection* latency for a CSP-side compromise. None of them reduces the *probability* that the CSP's signing key gets stolen tomorrow. Probability reduction at the source sits entirely on the CSP side, because the signing key by construction lives there.

Defense in depth defeats plausible paths. Whether it defeats the actual path is unknown -- because, three years on, the actual path is still unknown.

10. Open Problems

Six open problems remain after three years, in descending order of architectural consequence.

OP1 -- The mechanism gap. Microsoft still does not publicly know how the 2016 MSA signing key was stolen. The methods of Section 7 defeat plausible paths, but the actual path is undocumented. Until the actual mechanism is recovered (if it ever is), Microsoft is in the position of having raised the bar against the categories of attack it suspects, without being able to confirm that the bar it raised is the one the attacker cleared [@csrb-report-2024; @msrc-key-acquisition].

OP2 -- The broader-blast-radius question. Wiz Research showed the same key could in principle have signed tokens for SharePoint, Teams, OneDrive, and many third-party "Sign in with Microsoft" applications. Whether the broader scope was exploited and went undetected against telemetry that never existed is unanswered [@wiz-storm0558].

OP3 -- CSP regulation as critical infrastructure. The CSRB report framed cloud-identity-provider regulation as an open U.S. policy question. The Board recommended treating identity infrastructure as critical infrastructure subject to mandatory disclosure and minimum security baselines. Implementation across Congress, the executive branch, and sector-specific regulators is incomplete [@csrb-report-2024].

OP4 -- Cross-provider unrotated-signing-key risk. No major non-Microsoft IdP publicly discloses signing-key rotation cadence for its production tokens. Microsoft's transparency post-CSRB is, at present, the publication standard; AWS's, Google's, and Okta's positions are inferred from product documentation rather than disclosed in the form Microsoft now uses [@aws-iam-idc-security; @gcp-cloud-hsm].

OP5 -- Threshold or multi-party signing for production IdP signing keys. Practical cryptographic protocols exist. The canonical Schnorr-class construction is FROST -- "Flexible Round-Optimized Schnorr Threshold Signatures" -- introduced by Chelsea Komlo and Ian Goldberg at SAC 2020 [@frost-springer-sac-2020] and standardized as IRTF/CFRG RFC 9591 in June 2024 (a two-round protocol with five normative ciphersuites covering Ed25519, ristretto255, Ed448, P-256, and secp256k1) [@rfc-9591-frost].

For ECDSA, Yehuda Lindell and Ariel Nof's CCS 2018 paper described what its abstract called "the first truly practical full threshold ECDSA signing protocol that has both fast signing and fast key distribution" [@lindell-nof-cris]. The DKLs line (Doerner, Kondi, Lee, shelat) extended the work, with the May 2023 update "Threshold ECDSA in Three Rounds" the current standard reference, accompanied by named third-party production implementations from Coinbase, Silence Laboratories, Taurus Group, and BlockDaemon [@dkls-info].

No major cloud service provider has publicly deployed threshold signing for production IdP keys at the scale where compromise of a single signing oracle still ends the conversation. This is the largest unrealized research-to-practice gap in the entire stack.

OP6 -- Customer-verifiable attestation of IdP key custody. No standardized cryptographic primitive analogous to Certificate Transparency exists for IdP signing-key state. The design pattern was specified by Ben Laurie, Adam Langley, and Emilia Kasper (all of Google) in RFC 6962 in June 2013 -- a Merkle-tree-backed append-only log of TLS certificate issuance that lets any customer cryptographically detect that a certificate authority issued a certificate for their domain that they did not request [@rfc-6962-ct]. There is no equivalent primitive that lets a customer cryptographically detect that a token issuer signed a token naming them as sub that they (or their identity provider) did not request. This is the architectural ceiling of customer-side defense.

OP5 and OP6 both have rich primary-source literatures the article only gestures at. For OP5, follow the original FROST paper [@frost-springer-sac-2020] for the security proof reducing to discrete log via the Bellare-Neven Generalized Forking Lemma, the corresponding IRTF specification [@rfc-9591-frost] for the deployable ciphersuites, Lindell-Nof's CCS 2018 paper [@lindell-nof-cris] for the threshold-ECDSA foundation, and the DKLs project page [@dkls-info] for the most recent three-round construction. For OP6, RFC 6962 [@rfc-6962-ct] specifies the Merkle-tree-backed append-only log structure (the Signed Certificate Timestamp, the Merkle Audit Path, and the Merkle Consistency Proof) that any future IdP-key-custody-transparency protocol would build on.

Note: OP1, OP5, and OP6 are research-grade open questions in cryptographic systems design. OP2, OP3, and OP4 are policy and disclosure questions, addressable through regulation or industry-coordinated transparency norms. None has a published, deployed answer.

Three research-grade gaps, three policy-grade gaps. The defender, meanwhile, has to ship something on Monday. What should that something be?

11. What a Defender Should Do Today

The practical guidance splits along three audiences: M365 customers operating the consumer side of this incident's geometry, builders of multi-tenant SaaS that signs JWTs of their own, and CISOs evaluating cloud identity vendors.

11.1 For Microsoft 365 customers

First, confirm Purview Audit is enabled at the highest tier your SKU permits, that MailItemsAccessed is being collected, and that the events are being forwarded to a SIEM with retention of at least 180 days. The features previously gated on Premium have been free for FCEB and most commercial customers since the September 2023 rollout [@ms-blog-jul19-recovered; @cisa-statement-free-logs-fixed].

Second, maintain an inventory of legitimate (AppID, ClientAppID) pairs that historically read mailboxes in your tenant, and alert on any deviation. The State Department detection is reproducible only if you have collected the events to detect with.

Note: 1. Purview Audit at the highest tier your SKU permits, with MailItemsAccessed collection enabled. 2. SIEM forwarding with at least 180 days of retention (Microsoft's new default), preferably longer. 3. A maintained baseline of legitimate (AppID, ClientAppID) pairs for mailbox access. 4. Alerts on cross-issuer use (an enterprise resource accessed by a token from a consumer or unexpected iss). 5. Routine threat-hunting against MailItemsAccessed events filtered by anomalous source IPs, working-hours patterns, and bulk-fetch behavior consistent with exfiltration [@aa23-193a].

A baseline-deviation rule, expressed compactly:

{` // Pseudocode. Run against ingested JWT validation events from your SIEM. // 'observedKids' is the set of kid values your relying parties have processed. // 'currentJwksKids' is fetched live from the issuer's JWKS endpoint.

async function checkKidDrift(issuer, observedKids) { const jwks = await fetch(issuer + '/.well-known/openid-configuration') .then(r => r.json()) .then(cfg => fetch(cfg.jwks_uri)) .then(r => r.json());

const currentKids = new Set(jwks.keys.map(k => k.kid));

for (const kid of observedKids) { if (!currentKids.has(kid)) { alert({ severity: 'medium', reason: 'kid not in current issuer JWKS', issuer, kid, note: 'Either an expired/retired key being replayed, or a forged token signed by a kid the issuer no longer publishes. Both warrant investigation.' }); } } } `}

11.2 For builders of multi-tenant SaaS that signs JWTs

If you sign JWTs yourself, you are operating an identity provider, and the Storm-0558 lessons apply to you directly. The checklist is six items.

HSM custody for signing keys (M1). Generate signing keys inside an HSM with exportable=False. The HSM signs; the application asks. The key never leaves.
Automatic rotation (M3). Rotate signing keys on a cadence measured in days to weeks. Publish the new kid in your JWKS before signing with it; deprecate the old kid only after relying parties have had time to refresh their JWKS caches.
Issuer and audience enforcement (M4). Implement the combined iss and aud validation mandate RFC 8725 codifies in Sections 3.8 and 3.9, and test it with adversarial cross-tenant tokens. Write a test that forges a token from your tenant A and verifies that your tenant B's validator rejects it [@rfc-8725; @rfc-8725-html].
kid drift monitoring (M7). Alert on JWT validation events whose kid is not currently published in your issuer's JWKS. A forged token signed with a retired or unpublished kid will surface here.
JWKS cache invalidation discipline. Relying parties cache JWKS aggressively. Coordinate rotation with your largest relying parties; document the cache TTL you expect them to honor. OpenID Connect Discovery 1.0 specifies the JWKS discovery pattern but leaves cache TTL as a deployment choice; the publication of that contract is yours to make [@oidc-discovery]. Storm-0558's lesson is that an unrotated key is a permanent attack surface; a poorly-coordinated rotation is a permanent operational outage.
An on-call runbook for rotation failure. If automatic rotation fails, what is the page severity? Who is paged? How is manual rotation performed? Microsoft's 2021 pause of MSA manual rotation (after a manual-rotation-related outage) is the cautionary tale; the runbook is the prevention [@csrb-report-2024].

For higher-value deployments, add Confidential Compute (M2) -- run the signing service inside an attested TEE so that even host operators cannot read the in-use key. The threshold of "higher-value" is whatever value of "your customer's most sensitive resource accessed by a forged token" makes the in-use observation residual worth closing.

Note: HSM custody plus automatic rotation plus RFC 8725 Sections 3.8 and 3.9 enforcement plus kid drift monitoring plus rotation runbook. Add Confidential Compute for the in-use observation residual on high-value paths. Test cross-tenant token rejection adversarially; do not trust your validation library defaults [@rfc-8725; @rfc-8725-html; @sfi-sept-2024].

11.3 For CISOs evaluating a cloud IdP

The four RFP questions, mapped to the four pre-incident failure modes Section 3 catalogued:

(a) Where is the signing key custodied, and what FIPS certification does the HSM hold? (b) What is the rotation cadence for the IdP signing keys, and is rotation automated end-to-end? (c) Does the validation SDK enforce iss/aud separation by default, or does it leave the check to the caller? (d) What audit log events are available to free-tier customers, with what retention, and which events are gated behind paid tiers?

Map the answers to CSA CCM CEK and IAM domains and FedRAMP High SC-12 and IA-5 controls for cross-vendor normalization [@csa-ccm; @fedramp].

Ask the vendor: "If your production IdP signing key were stolen today, by what telemetry would you detect it, and within what time? What public-disclosure timeline would you commit to?" The answer reveals more about the vendor's posture than the answers to the four primary questions, because it forces the vendor to talk about a scenario their marketing material does not.

Key idea: Defense in depth defeats the plausible attack mechanisms. Whether it defeats the actual attack mechanism is unknown because, in the highest-stakes documented case, the actual mechanism is still unknown. The defender's posture is therefore "raise the floor against everything I can imagine," not "patch the specific bug." Storm-0558's enduring lesson is what it means to architect under that constraint.

The seven SOTA methods raise the floor against plausible mechanisms. The customer can demand documentation, alert on deviations, pay for the audit tier they actually need, and vote with procurement dollars for vendors whose disclosure posture matches Microsoft's post-CSRB stance. Prevention against a CSP-side custody failure remains, as Section 9 noted, on the CSP side by construction.

12. FAQ and Study Guide

No. That was Microsoft's September 6, 2023 working hypothesis. Microsoft itself partially retracted it on March 12, 2024 (see Section 4.1 for the full retraction text in the Callout). The Cyber Safety Review Board report on April 2, 2024 then concluded definitively that Microsoft "has been unable to determine how or when Storm-0558 obtained the MSA key" [@msrc-key-acquisition; @csrb-report-2024]. No. The U.S. State Department detected the breach on June 15, 2023, by reviewing `MailItemsAccessed` events in Microsoft 365 Purview audit logs against a maintained baseline of legitimate application IDs. The State Department notified Microsoft on June 16, 2023. Microsoft then confirmed the forgery by comparing the suspicious tokens' `kid` against its own published MSA key rotation history [@csrb-report-2024; @ms-security-jul14]. Microsoft's preliminary July 2023 disclosure said "approximately 25" [@msrc-storm0558-jul11]. The CSRB's April 2024 final tally is 22 enterprise organizations and approximately 503 related personal accounts, with approximately 60,000 emails exfiltrated from 10 U.S. State Department accounts alone [@csrb-report-2024]. The attack pattern -- steal an identity provider's signing key, mint forged tokens, present them to relying parties -- is generic and has prior public examples (Reiner's 2017 Golden SAML disclosure; the Russian SVR's 2020 Sunburst weaponization). What is Microsoft-specific is the *cross-tier* consumer/enterprise validation flaw and the unrotated 2016 key. No other major identity provider has publicly disclosed an analogous IdP-signing-key-class incident in the 2023-2026 window, but absence of public disclosure is not absence of risk [@reiner-golden-saml; @aa20-352a; @wiz-storm0558]. The Secure Future Initiative (SFI). Identity signing keys for both MSA and Entra ID are now generated, stored, and automatically rotated in Azure Managed HSM (FIPS 140-3 Level 3) as of the September 2024 progress report. The MSA signing service runs inside Azure Confidential VMs as of April 2025, with Entra ID's signing service migrating to the same. 90% of Entra ID tokens for Microsoft apps are validated by one consistent hardened identity SDK that enforces `iss`/`aud` separation. And `MailItemsAccessed` plus 30+ Purview audit event classes have been free for FCEB and most commercial customers since the September 2023 rollout, with default retention now 180 days and internal retention extended to two years [@sfi-sept-2024; @sfi-april-2025; @ms-blog-jul19-recovered]. Yes, in principle. Wiz Research's independent analysis demonstrated the compromised key could have signed tokens for any application using Microsoft's converged OpenID v2.0 endpoint that accepts personal-account authentication -- SharePoint, Teams, OneDrive, and a long tail of third-party "Sign in with Microsoft" applications. There is no public evidence the broader scope was actually exploited; the publicly documented victims are scoped to Exchange Online and Outlook. Whether broader exploitation occurred and was simply not detected against telemetry that did not exist remains an open question [@wiz-storm0558]. Because it inverts a default assumption. Cloud providers, in their marketing material, are the parties responsible for monitoring their own identity infrastructure. In Storm-0558, the cloud provider did not. A paying customer with a paid-tier audit log saw the anomaly first. The CSRB's harshest single critique is structural: the commercial logging-tier structure of cloud identity asymmetrically delays detection in favor of well-resourced customers, and the policy response (free Purview Audit features) is a partial but necessary correction [@csrb-report-2024; @cisa-statement-free-logs-fixed].

Rust in the Windows Kernel: A Field Guide to the 2024-2026 Memory-Safety Refit

noreply@paragmali.com (Parag Mali) — Sat, 23 May 2026 00:00:00 GMT

**Rust ships in the Windows kernel today.** The binary is `%SystemRoot%\System32\win32kbase_rs.sys`, first surfaced in Insider Preview Build 25905 on 12 July 2023 and most recently in the news through Check Point Research's May 2025 "Denial of Fuzzing" disclosure. The realistic ten-year trajectory is **not** a Windows rewrite. It is "memory-safe by default for newly written code" plus targeted rewrites of high-blast-radius modules, with the unsafe-FFI boundary as the irreducible audit frontier. This article is a primary-sourced field guide to what actually shipped from BlueHat IL 2019 through Windows 11 24H2 in 2026, what did not, and what the next decade looks like.

1. The Blue Screen That Wasn't a Bug

On 28 May 2025, Microsoft shipped KB5058499 to patch a kernel bug in Windows 11 24H2 [@kb5058499]. The bug was an out-of-bounds array access in a Rust function called region_from_path_mut() inside the binary %SystemRoot%\System32\win32kbase_rs.sys [@cybersecuritynews]. Rust correctly detected the access. Because the detection fired at high IRQL inside a kernel binary compiled with panic = "abort", the response was a system-wide blue screen [@checkpoint-dof].

Read that again. Rust. In ntoskrnl's neighbourhood. In production. Detecting a memory-safety violation. Panicking. Bugchecking the box.

The class of programming error -- buffer overflow, use-after-free, type confusion, integer overflow, double-free, uninitialised read -- where unsafe memory access leads to undefined behaviour. For two decades the Microsoft Security Response Center has reported that roughly seventy percent of Microsoft's CVE-assigned vulnerabilities come from this class. The first Windows kernel binary written in Rust. It contains the Win32k GDI region and shape engine, and after 2025 includes portions of the EMF and EMF+ metafile parsing path. The `_rs` suffix is Microsoft's internal convention for Rust-implemented kernel binaries. You can verify the file exists on any modern Windows 11 install by checking `%SystemRoot%\System32\win32kbase_rs.sys`.The first public ship was Windows 11 Canary-channel Insider Preview Build 25905 on 12 July 2023. The Windows Insider blog called out the change explicitly: "This preview shipped with an early implementation of critical kernel features in safe Rust" [@insider-25905].

The Check Point Research write-up tells the story tightly [@checkpoint-dof]. A handcrafted Enhanced Metafile Format Plus (EMF+) record -- specifically an EmfPlusDrawBeziers shape with a mismatched point count -- arrives at the kernel by way of a normal-looking NtGdiSelectClipPath syscall. The metafile parser hands the malformed point array to region_from_path_mut(), the Rust function that converts a Bezier path into a clipping region. Indexing into the array, Rust observes the index is out of bounds. Safe Rust's bounds check fires. core::panicking::panic_bounds_check runs. And because the binary lives in kernel mode, the panic does not unwind: it aborts [@esecurityplanet]. The bugcheck code is SYSTEM_SERVICE_EXCEPTION [@cybersecuritynews].

The Windows kernel's per-CPU priority level, ranging from PASSIVE_LEVEL up through DIRQL. At IRQL ≥ DISPATCH_LEVEL the scheduler cannot run, paged memory cannot be touched, and almost no recovery path is available. A panic at high IRQL has nowhere to go except the system-wide bugcheck. The Rust compilation profile setting that converts any runtime panic into an immediate process abort rather than stack unwinding. It is mandatory for `no_std` kernel binaries because there is no unwinder, no `std::panic::catch_unwind`, and no way to clean up locks, allocations, or interrupt state held at the point of panic.

Microsoft classified the issue as a moderate-severity denial of service. The patch tightened the bounds check upstream, kept the Rust panic as the last-resort backstop, and shipped on. There is no CVE-2025 RCE here, no privilege escalation, no infoleak: this Rust panic was the security boundary doing exactly what it was designed to do, and the price was a controlled BSOD rather than a memory-corruption primitive in attacker hands [@checkpoint-dof].

That single bug carries two non-obvious claims that the rest of the article will unpack. First, this is the largest language-level memory-safety refit in NT's roughly thirty-three-year history, distinct in kind from /GS stack cookies, Address Space Layout Randomization (ASLR), Control Flow Guard (CFG), Hypervisor-protected Code Integrity (HVCI), or Intel Control-flow Enforcement Technology (CET). All of those are mitigations that raise the cost of exploiting a memory-safety bug. Rust eliminates the bug class in the modules it covers. That is a different kind of fix.

Second, the realistic ten-year shape is "memory-safe by default for new code," not "rewrite Windows." Microsoft's distinguished engineer Galen Hunt got in trouble in December 2025 for a LinkedIn post about an internal "1 engineer, 1 month, 1 million lines of code" research target [@register-2025-12-24]. Frank X. Shaw, head of Microsoft's communications, confirmed within days that the company has no plan to rewrite Windows 11 using AI [@windowslatest-galen; @infoworld-not-rewriting]. The trajectory is policy, not project.

So: Rust in the Windows kernel. Real binary, real BSOD, real patch, real timeline. How did we get here, and why is a Rust-detected memory-safety violation still a system-wide crash?

2. The 70-Percent Number and Why Mitigations Plateaued

In early February 2019, in Tel Aviv, Matt Miller stood up at BlueHat IL and asked the question that anchored the next seven years of Microsoft's security strategy. After two decades of Microsoft Security Response Center (MSRC) triage, what fraction of vulnerabilities are still memory-safety bugs? His answer, drawn from a decade of CVE data: about seventy percent [@miller-bluehat-2019; @infoq-mitigating].

The number was not new in 2019. The MSRC's own July 2019 essay re-stated it in plain prose: "approximately 70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" [@msrc-proactive-2019]. It had not moved in a decade despite /GS stack cookies, Data Execution Prevention (DEP), ASLR, CFG, Hypervisor-protected Code Integrity, and Intel CET [@msrc-safer-2019]. Mark Russinovich repeated the number at RustConf 2025 in Seattle: "about 70% over the past two decades" [@newstack-russinovich].

A note on attribution. The originating talk was Miller's, not David Weston's. The press cycle following Weston's 2023 BlueHat IL announcement often credited him with the 70% figure. Weston and Russinovich operationalised it; Miller and the MSRC published it. The deck is in the microsoft/MSRC-Security-Research repository on GitHub under the 2019_02_BlueHatIL directory; you can read it today [@miller-bluehat-2019].Miller was MSRC's Partner Security Software Engineer at the time of the talk. He has since moved on, but Microsoft kept the BlueHat IL 2019 deck in the public security-research repo as a primary artefact for the figure.

Note: The 70% figure was roughly the same in 2009 as in 2019. The mitigations stack had absorbed two decades of compiler, OS, and hardware investment without moving the curve. That is why the question shifted from "how do we make exploitation harder" to "how do we eliminate the bug class itself."

To see why the curve stayed flat, walk the supersession history. Each generation of mitigation closed a specific exploitation primitive. None closed a bug class.

/GS (Visual Studio .NET 2002/2003) inserted a per-function stack canary to detect linear stack-buffer overruns that overwrote a saved return address [@learn-gs]. It defended only the prologue-epilogue window of stack frames. Heap overflows, non-adjacent stack writes, type confusion, and info-leak-then-corrupt all walked around it.

DEP / NX (Windows XP Service Pack 2, 2004) marked data pages non-executable so attackers could not jump into a buffer they had written [@learn-dep]. Hovav Shacham's 2007 paper on Return-Oriented Programming showed how to compose Turing-complete payloads from existing executable code without ever introducing a new instruction [@shacham-rop-2007]. DEP raised exploit cost. It did not close the bug class.

ASLR (Windows Vista, 2006) randomised module, heap, and stack base addresses so attackers could not pre-compute jump targets [@learn-aslr]. The defeat was a single information-disclosure primitive away. Every modern Windows exploit chain begins with an infoleak.

CFG (Windows 8.1, 2014) restricted indirect calls to a per-binary set of valid call targets [@learn-cfg]. XFG (announced at BlueHat Shanghai 2019, /guard:xfg compiler support shipped in MSVC in 2020, available in Windows 11 from 2021 as an opt-in compile-time flag, not enabled by default for third-party binaries) tightened that to type-signed indirect call sites [@quarkslab-xfg; @mcgarr-examining-xfg]. CET shadow stack (broadly shipping in Windows 11 in 2021) sealed the return-address half of the same family on hardware that supports it [@msft-cet-shadow]. All three are forms of Control-Flow Integrity, and all three by construction defend the control-flow graph only.

The family of compile-time and hardware mitigations -- including CFG, XFG, and CET shadow stack -- that restricts indirect control transfers (jumps, calls, returns) to a per-binary set of valid targets. CFI is, by construction, blind to attacks that corrupt program data without changing the control-flow graph. A class of exploitation in which an attacker corrupts program *data* without changing the control-flow graph. Hu et al. proved at IEEE Symposium on Security and Privacy 2016 that DOP is Turing-complete -- meaning an attacker who can corrupt the right pieces of data can compute arbitrary functions while the protected program faithfully follows its original control flow [@hu-dop-2016].

That theorem is the structural ceiling. If DOP can express arbitrary computation while the program's control-flow graph remains unviolated, then no amount of CFI can close the bug class. Every CFI variant could be implemented perfectly tomorrow and the 70% figure would still not move. The MSRC's July 2019 "We need a safer systems programming language" essay said the quiet part aloud: "no matter the amount of mitigations put in place, it is near impossible to write memory-safe code using traditional systems-level programming languages at scale" [@msrc-safer-2019].

The MSRC essay -- written by Matt Miller's team in the same July 2019 cycle as the BlueHat IL talk -- ends with a striking concession: "rather than providing guidance and tools for addressing flaws, we should strive to prevent the developer from introducing the flaws in the first place" [@msrc-safer-2019]. That sentence is the strategic pivot. After two decades of *mitigation* investment, Microsoft publicly accepted that mitigations could not solve the problem alone. The only structural fixes are at the language layer (eliminate the unsafe primitives) or the hardware layer (enforce safety at every dereference). Hu et al.'s DOP theorem was the formal moment "mitigations are necessary but not sufficient" stopped being a slogan and became math.

The supersession trace is compact enough to fit in one table.

Generation	Mitigation	Year	Closes	Defeated by	Residual bug class
G1	`/GS` stack canary	2002/2003	Linear stack overruns past return address	Heap overflows, non-adjacent writes, infoleaks	Memory corruption (all classes except narrow stack)
G2	DEP / NX	2004	Code injection into data pages	ROP (Shacham 2007)	Memory corruption (control transferred to existing code)
G3	ASLR	2006	Pre-computed gadget addresses	Information-disclosure primitives	Memory corruption (after infoleak)
G4	CFG (default) / XFG (opt-in)	2014 / 2021	Arbitrary indirect call targets	Data-oriented programming (Hu 2016)	Data-only memory corruption
G4	CET shadow stack	2021	Return-address rewrites	DOP, non-return CFI bypass	Data-only memory corruption
G5	HVCI, Driver Verifier, WDAC	2015+	Unsigned/unverified driver code	Memory corruption in signed drivers	Memory corruption in trusted code
G6	Rust in the Windows kernel	2023+	The bug class itself, in covered modules	Bugs in `unsafe` blocks; panic-as-BSOD	Logic bugs, FFI invariant violations, DoS via panic

The cross-vendor data agrees. Chromium's own engineering reports peg roughly 70% of high-severity browser bugs as memory safety. Google's Android security team published in September 2024 that memory-safety vulnerabilities in Android dropped from 76% of total in 2019 to 24% in 2024 -- not by rewriting existing C and C++, but by writing new code in Rust [@google-android-2024]. The structural fix shows up in the data when it ships.

Key idea: Mitigations bound the cost of exploitation. Only a memory-safe language or capability hardware bounds the size of the bug class itself. After two decades, the 70% figure had not moved. The structural answer was no longer optional.

If the structural fix had to come from the language layer, why did Microsoft choose Rust -- and not the safer-systems-language it had been researching since 2006?

flowchart LR GS["/GS stack cookie
2002 / 2003"] --> DEP["DEP / NX
2004"] DEP --> ASLR["ASLR
2006"] ASLR --> CFG["CFG / XFG
2014 / 2021"] CFG --> CET["CET shadow stack
2021"] CFG --> HVCI["HVCI + WDAC
2015+"] CET --> Rust["win32kbase_rs.sys
Rust in kernel
2023"] HVCI --> Rust ASLR -.->|"defeated by infoleaks"| Bypass1["arbitrary primitives"] CFG -.->|"defeated by DOP, Hu 2016"| Bypass2["data-only attacks"] Rust ==>|"closes the bug class
in covered modules"| Win["memory-safe by default
for new code"]

3. Verona, windows-rs, and the Long Approach

Microsoft's first publicly-named safer-systems-language experiment was not Rust. It was Singularity, the Microsoft Research operating system Galen Hunt and Jim Larus described in ACM SIGOPS Operating Systems Review in April 2007 [@singularity]. Singularity was built in Sing#, a dialect of C# extended with software-isolated processes, contract-based channels, and manifest-based programs that the OS verified at install time. The idea was the same as Rust's: prove memory safety at the language level so the runtime cost of process isolation becomes negligible. Singularity worked. It also stayed in the lab.

A decade later, in 2019, Microsoft Research open-sourced Project Verona at github.com/microsoft/verona, a collaboration with Imperial College London and Uppsala University [@verona-github; @verona-msr]. Verona explores concurrent ownership in regions: where Rust's borrow checker tracks one owner per object, Verona lets multiple objects share a single region-level ownership lifetime, simplifying some concurrent patterns at the cost of additional runtime structure.Verona's region-based concurrent ownership lets multiple objects share a single ownership lifetime. The academic publications appear at OOPSLA and PLDI. The repository README is explicit that the project is "not ready to be used outside of research." Verona remains alive as research. It has not been productised.

So why did Rust win against two memory-safe languages of Microsoft's own design?

The answer is adoption. Singularity and Verona were technically interesting; the community around them was Microsoft Research. Rust came with crates.io, a stable compiler, a community of working programmers, a foreign-function-interface story, and -- as of January 2020 -- official Microsoft-maintained bindings. Microsoft Research kept its own safe-systems-language line for the questions Rust does not answer, and Microsoft the platform vendor met developers where they already were.

The pivot to Rust shows up in three threads.

Thread A -- the user-mode bindings. In January 2020, Microsoft published microsoft/windows-rs on GitHub, a set of idiomatic Rust bindings to the entire Win32, Windows Runtime, and Component Object Model surface generated on the fly from Windows-metadata projections. The README is exact: "the windows and windows-sys crates let you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API" [@windows-rs-github]. The crate is strictly user-mode. The kernel bindings come later, in a different repository.The premise paragraph that originally framed this article conflated windows-rs with the kernel bindings. They are different repositories: microsoft/windows-rs is user-mode (Win32, WinRT, COM); microsoft/windows-drivers-rs is the kernel and driver bindings. We will look at the latter in section 4.3.

Thread B -- the institutional commitment. On 8 February 2021, Microsoft joined the Rust Foundation as a founding (Platinum) member, and announced it was forming an in-house Rust team to contribute compiler and tooling work [@msft-rust-foundation]. The same year, Microsoft began funding Ralf Jung's verification line at the Max Planck Institute for Software Systems -- the MIRI interpreter, the RustBelt proofs -- both of which give the formal teeth that distinguish "Rust is safer" from "Rust is provably safe in a specific sense."

Thread C -- the academic foundation. In April 2021, Jung, Jourdan, Krebbers, and Dreyer published "Safe Systems Programming in Rust" in Communications of the ACM [@cacm-jung-2021]. The paper builds on their RustBelt result at POPL 2018, which constructed the first formal, machine-checked safety proof for a realistic subset of Rust [@rustbelt-popl-2018; @rustbelt-popl-page]. The RustBelt theorem has a property no informal language design has: it is extensible. The project page states the result precisely: "for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy" [@rustbelt-popl-page]. In plain language: safe Rust is type-sound by construction, and every unsafe block can be discharged separately by a per-library proof obligation.

That property -- a discharged proof obligation per unsafe block -- is the engineering hook that makes Rust-in-kernel tractable. The kernel is full of unsafe. There is no way around that fact; the kernel is the trusted base, the layer that touches raw pointers and hardware. But if every unsafe block has a local, statable proof obligation, then the engineering question shrinks from "is the language safe?" to "is the audit of these specific blocks correct?" That is a question reviewers can answer.

Singularity / Sing# and Verona are not the only Microsoft-adjacent safer-systems-language threads. The Cyclone project (AT&T / Cornell, mid-2000s) added region-based memory management to C; the Spec# / Code Contracts line (Microsoft Research, late 2000s) attached pre- and post-conditions to .NET methods. All three were technically attractive. None achieved industrial-scale adoption. The lesson Microsoft drew from those efforts -- visible in the windows-rs investment -- is that the surrounding toolchain and community trump language design. Rust came with crates.io and a working community; the Microsoft Research languages did not.

By early 2023 the four ingredients were in place: a user-mode-scale Rust footprint at Microsoft, executive commitment via the Foundation, a verification story with RustBelt-grade formal teeth, and a working windows-rs for the user-mode call sites. The pieces existed.

What did it take to put Rust inside the kernel itself?

4. Three Generations of Microsoft's Rust-in-Windows Effort

The 2019-to-2026 story falls naturally into three generations. Each one solves the problem the previous one identified.

flowchart TD subgraph G1["Generation 1 -- 2019 to early 2023: Prerequisites"] A1["Miller BlueHat IL 2019
(70 percent figure)"] A2["MSRC safer-systems essay
(July 2019)"] A3["windows-rs
(January 2020)"] A4["Rust Foundation founding
(February 2021)"] A5["Secure Future Initiative
(November 2023)"] end subgraph G2["Generation 2 -- March to July 2023: First ship"] B1["Weston BlueHat IL 2023
(March 29 to 30)"] B2["DWriteCore in user-mode Rust
(152K LOC)"] B3["win32kbase_rs.sys in kernel Rust
(36K LOC, behind flag)"] B4["Insider Build 25905
(July 12, 2023)"] end subgraph G3["Generation 3 -- 2024 to 2026: Expansion and toolchain"] C1["windows-drivers-rs public
(2024)"] C2["EMF parser in win32kbase_rs
(by May 2025)"] C3["Surface Rust drivers ship
(July 2025)"] C4["Russinovich RustConf 2025
(September 2 to 5, Seattle)"] C5["cargo-wdk on crates.io
(November 2025)"] end G1 --> G2 G2 --> G3

4.1 Generation 1 (2019 to early 2023): the prerequisites

Generation 1 was preparation. Four things had to land before Rust could ship in the kernel itself: Microsoft running Rust at user-mode scale internally; a working no_std kernel target (the Rust compilation profile that strips the standard library's OS-services assumptions so a binary can run in kernel context); a verification story credible enough for executive sign-off; and that sign-off itself.

The chronology is clean. January 2020: windows-rs ships [@windows-rs-github]. February 2021: Microsoft joins the Rust Foundation as a founding member [@msft-rust-foundation]. 2019 through 2022: Project Verona and Singularity supply the academic foundations and the in-house safer-systems-language credibility [@verona-github; @singularity]. April 2021: the Jung et al. Safe Systems Programming in Rust paper in CACM gives the public-facing formal warrant [@cacm-jung-2021]. November 2, 2023: Brad Smith and Charlie Bell launch the Secure Future Initiative (SFI), a company-wide commitment that explicitly names memory-safety-language adoption as a software-engineering pillar [@sfi-onissues; @sfi-secblog]. The March 6, 2024 update on SFI confirms the engineering follow-through after the Storm-0558 and Midnight Blizzard incidents [@sfi-march24].

The limitation of Generation 1 is in the name. Prerequisites. No Rust had shipped in the Windows kernel yet. DWriteCore was in user mode. windows-rs was in user mode. Verona was research. The next generation had to fire the actual gun.

4.2 Generation 2 (March to July 2023): the first ship

On 29 and 30 March 2023 in Tel Aviv, David "dwizzle" Weston, then Vice President of Enterprise and OS Security at Microsoft, took the BlueHat IL stage and announced two distinct Rust ports.BlueHat IL 2023 was held in Tel Aviv on 29 to 30 March 2023; the dominant English-language press coverage broke same-day on 27 April 2023 when an embargo lifted. The article uses 27 April 2023 throughout when the date in question is the public record rather than the talk itself. The Register's same-day write-up has the canonical quote set and used Weston's earlier "Director" title [@register-2023-04-27]. The article keeps the two ports strictly separate because conflating them is the most common error in the secondary coverage.

The first port was DWriteCore, the text-rendering and shaping engine that ships through the Windows App SDK. The Register's same-day coverage carried the line-of-code and performance numbers from Weston's deck -- we return to the exact counts in §6.2 -- but the load-bearing point at BlueHat IL 2023 was that DWriteCore is strictly user-mode code, not in the kernel [@register-2023-04-27].

The second port was the one that the article you are reading is mostly about: win32kbase_rs.sys, a kernel binary containing the Win32k GDI region and shape engine -- about 36,000 lines of Rust, behind a feature flag, with at least one syscall in the Windows kernel implemented in Rust [@register-2023-04-27]. Weston's verbatim line is the moment that mattered.

There's actually a SysCall in the Windows kernel now that is implemented in Rust. -- David Weston, BlueHat IL 2023 [@register-2023-04-27].

The first reader-verifiable artefact of that ship came on 12 July 2023. Windows 11 Canary-channel Insider Preview Build 25905 dropped, and the Windows Insider blog called out the change: "Rust in the Windows Kernel ... win32kbase_rs.sys contains a new implementation of GDI region" [@insider-25905]. From that moment forward, any reader with a recent Windows 11 Insider build could open Explorer at C:\Windows\System32, sort by name, and find win32kbase_rs.sys on disk. Generation 2 was a proof of existence. The binary was real. The syscall path it implemented was real. Some pieces ran behind a feature flag, but the cement had set.

The limitation of Generation 2 was that the toolchain was Microsoft-internal. External driver authors could not reproduce the build pipeline; the no_std kernel target had not been upstreamed to rust-lang/rust; the allocator shim that adapted GlobalAlloc onto ExAllocatePool2 lived in a private repository. Generation 3 had to address the third-party adoption question.

4.3 Generation 3 (2024 to mid-2026): expansion and toolchain rollout

Generation 3 has four threads running in parallel.

Thread 1: the public driver-development crate suite. Microsoft published microsoft/windows-drivers-rs -- the public repository of Rust crates for Windows driver development [@windows-drivers-rs; @heise-rust]. The repository contains six crates (wdk, wdk-sys, wdk-alloc, wdk-build, wdk-panic, wdk-macros) plus the cargo-wdk Cargo subcommand that wraps link.exe, inf2cat, signtool, and friends into a coherent Rust build. A companion sample repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples [@windows-rust-samples]. The README of windows-drivers-rs is candid: the project is "still in early stages of development and is not yet recommended for production use" [@windows-drivers-rs]. It also pins LLVM 17 explicitly, because LLVM 18 introduced an ARM64 bindgen bug that breaks WDK header binding generation [@windows-drivers-rs].The windows-drivers-rs README specifically pins LLVM 17 because LLVM 18 has a bug that causes bindings to fail to generate for ARM64. The fix is expected in LLVM 19. This is the kind of detail that distinguishes a developer-preview toolchain from a production one.

Thread 2: the 2025 in-kernel Rust expansion. Between the 2023 ship and the May 2025 Check Point disclosure, the Rust footprint inside win32kbase_rs.sys grew. The growth surface that became publicly known is the Enhanced Metafile Format (EMF / EMF+) parsing path -- the code that converts a path of Bezier curves into a clipping region [@checkpoint-dof; @cybersecuritynews]. The Check Point disclosure documents region_from_path_mut() as Rust; the KB5058499 patch hardened the call site upstream of the Rust panic [@kb5058499; @esecurityplanet].The original article-focus paragraph speculated that the 2025 in-kernel expansion was the Win32k DirectDraw stack. No first-party Microsoft material identifies a DirectDraw Rust port. The publicly documented 2025 expansion is in the EMF / EMF+ metafile parser inside win32kbase_rs.sys. We follow the public record.

Thread 3: the first in-box Rust drivers. In July 2025, Microsoft's Surface team confirmed that several new Copilot+ Surface PCs ship with drivers written in Rust [@winbuzzer-surface; @thurrott-rust]. Microsoft's Melvin Wang wrote on the Windows Driver Development blog that "the Surface team has contributed further to the open-source windows-drivers-rs repository for driver development and shipped Surface drivers written in Rust" [@thurrott-rust]. By September 2025, The Register reported that no production third-party Rust driver had yet shipped through Windows Hardware Compatibility Program (WHCP) certification: CodeQL supports Rust in public preview at version 2.22.1, but only version 2.21.4 is "validated for use with WHCP" [@register-2025-09-04]. The certification path is being assembled in public.

Thread 4: the executive narrative. On 2 to 5 September 2025, Mark Russinovich -- Azure CTO, Deputy CISO, and Technical Fellow -- delivered the RustConf 2025 keynote in Seattle, titled "From Blue Screens to Orange Crabs: Microsoft's Rusty Revolution" [@rustconf-2025-prog; @newstack-russinovich; @itpro-rust]. The keynote made three claims that matter for this article. First, Rust is "mandated for new Azure components that handle untrusted input." Second, Microsoft is using Rust across "kernel components, a cryptography library (rustls-symcrypt), and ancillary components (DirectWrite)" plus Project Mu firmware, Caliptra, the Azure Integrated HSM, OpenVMM, and Hyperlight [@infoq-russinovich]. Third, the Check Point bug is success, not failure: a Rust panic that crashes the box is operationally better than a memory-corruption primitive that escalates privilege [@newstack-russinovich].The InfoQ piece that covers Russinovich's named-project list is dated May 2025 and is actually about his Rust Nation UK talk earlier that year, not RustConf 2025. The substantive content overlaps, but the venue is not the same. For RustConf 2025 itself, the primary references are the Rust Foundation program page and The New Stack's same-week summary [@rustconf-2025-prog; @newstack-russinovich].

One more thread to acknowledge: on 24 December 2025, a LinkedIn post by Microsoft distinguished engineer Galen Hunt triggered a press cycle around an internal "1 engineer, 1 month, 1 million lines of code" research target [@register-2025-12-24]. The picture was corrected within days by Hunt's own clarification and Frank X. Shaw's denial that Microsoft has any plan to rewrite Windows 11 using AI [@infoworld-not-rewriting; @windowslatest-galen]. The §9 Aside walks the story in full.

Three generations in, the toolchain is public, the binaries ship, the executive commitment is on the record, the certification path is being assembled, and the press has been corrected twice on the difference between research and roadmap. The pieces are in place. What is the insight that makes Rust-in-kernel tractable as an engineering policy?

5. Memory-Safe by Default for New Code + the Unsafe-FFI Boundary

The structural insight that emerged from Generations 2 and 3 is one Russinovich named explicitly at RustConf 2025: Rust adoption inside an existing C / C++ kernel of roughly thirty million lines -- a widely-cited engineering estimate; Microsoft has not published an exact figure -- is a policy decision, not a rewrite project [@newstack-russinovich]. The policy has two clauses. For new code, default to Rust. For existing code, rewrite the high-blast-radius surfaces -- the GDI region engine, the EMF parser -- but not the rest. Russinovich's framing at the keynote: Rust is "mandated for new Azure components that handle untrusted input" [@infoq-russinovich].

The new-code policy is empirically validated. The Android security team's September 2024 publication tracks the share of memory-safety vulnerabilities in Android over five years [@google-android-2024]. The headline curve looks like this.

Year	Memory-safety share of vulnerabilities
2019	~76%
2024	~24%

The drop did not come from rewriting existing C and C++. It came from writing new code in Rust while letting the older code stop being modified. Vulnerabilities in any specific code module decay exponentially as that module stops changing, because (a) bugs that were going to be discovered get patched, and (b) new bugs are introduced primarily by new code [@google-android-2024]. Stop adding C, and the long-run share of memory-safety CVEs falls without anybody rewriting anything. That is the empirical anchor for the "memory-safe by default for new code" policy.

The policy alone is not enough. The mechanism that makes it executable is the unsafe-FFI boundary: a narrow, typed, auditable seam where safe Rust meets the C kernel it has to talk to.

A Rust crate attribute (`#![no_std]`) that opts out of linking the Rust standard library. The crate keeps `core` (and optionally `alloc`), and gets nothing else for free. Required for kernel binaries because the standard library assumes OS services -- file descriptors, threads, dynamic memory through libc -- that the kernel itself is in the business of providing. The Rust standard-library trait that defines the global memory allocator. In kernel Rust, the trait is implemented by `wdk-alloc` to call `ExAllocatePool2` (allocate) and `ExFreePoolWithTag` (free) -- the NT pool allocator entry points that drivers have used since the late 1990s. The mechanism a programming language uses to call functions written in another language across an Application Binary Interface (ABI). In kernel Rust, FFI to C kernel headers is generated mechanically by `bindgen` from WDK headers; every call site that crosses the boundary is wrapped in `unsafe`. A region of Rust code where the compiler relaxes its safety invariants and the programmer accepts responsibility for upholding them. Inside `unsafe`, raw pointers may be dereferenced, mutable static state may be touched, and FFI calls may be made. The safety guarantee of any Rust system is exactly as strong as the human audit of these blocks.

Every Rust kernel module has three unsafe layers, and the audit of those three layers is the safety story.

Layer 1: the allocator shim. The kernel has no malloc. It has ExAllocatePool2, which takes a pool type, a size, and a four-character tag, and returns memory from one of the NT pool managers. Rust's Box<T>, Vec<T>, String, and Arc<T> all expect a GlobalAlloc implementation underneath. wdk-alloc is the bridge: it implements GlobalAlloc over ExAllocatePool2 / ExFreePoolWithTag, with unsafe blocks at every FFI call [@windows-drivers-rs]. If the allocator shim is wrong -- if it forgets to zero memory, mismatches a tag, or returns a misaligned pointer -- every safe Rust collection above it is suddenly not safe.

Layer 2: the FFI surface. Bindgen generates extern "system" declarations from the WDK headers, turning each C function signature into a Rust prototype with unsafe semantics [@windows-drivers-rs]. Every cross-language call is an unsafe block in the Rust caller. The audit obligation here is: did bindgen translate the C signature faithfully? Is the calling convention right? Are pointer ownership and lifetime invariants in the C function's documentation actually upheld in the Rust caller? Bindgen is mechanical; the audit is not.

Layer 3: the pointer-arithmetic wrappers. Where Rust must observe raw C structs -- IRP, KAPC, FAST_IO_DISPATCH, and the various Win32k-internal layouts -- the boundary code wraps each struct in a typed Rust newtype that asserts the invariants the C code expects, before any non-unsafe Rust code touches it. A common pattern is the RegionImpl<'a> family of wrappers: a Rust struct that holds a raw pointer plus a lifetime parameter, with all public methods written in safe Rust and a small number of private unsafe methods that do the actual dereferencing.

flowchart TD subgraph Safe["Safe Rust"] SR["Rust kernel module
(safe code, ~90% of LOC)"] end subgraph Unsafe["Three unsafe layers"] U1["Allocator shim
wdk-alloc on ExAllocatePool2"] U2["FFI surface
bindgen extern system decls"] U3["Pointer-arithmetic wrappers
IRP, KAPC, FAST_IO_DISPATCH"] end subgraph C["C kernel"] NT["ntoskrnl, win32k, hal"] end SR --> U1 SR --> U2 SR --> U3 U1 --> NT U2 --> NT U3 --> NT

The picture is small. A typical Rust kernel module has a few hundred FFI call sites, all typed, all auditable, with the conventional Rust community discipline that every unsafe block carries a SAFETY: comment justifying the invariants the human author claims to uphold.The Rust community convention is that every unsafe block carries a SAFETY: comment justifying the invariants the human author guarantees. Microsoft's internal review guidance reinforces this for kernel code, and the windows-drivers-rs samples follow the pattern consistently. The safety guarantee of the whole module is exactly as strong as the audit of those few hundred sites. Not magic. Not a free lunch. A finite, reviewable boundary.

The windows-drivers-rs README acknowledges this without euphemism. Microsoft's Nate Deisinger captured the position in the November 2025 Windows Driver Development blog post:

Drivers using these crates still need to make use of unsafe blocks for interacting with the Windows operating system, removing some of the benefits of Rust. -- Nate Deisinger, *Towards Rust in Windows Drivers* [@techcommunity-rust-drivers].

That is the load-bearing acknowledgement. Rust does not magically make the C kernel disappear. It pushes the audit frontier to a narrow, typed, fuzz-able boundary. The wins compound there: type checking catches whole bug families before they ever reach review, fuzzing concentrates on a few hundred sites rather than a million, and the rest of the Rust code -- the other 90% -- gets the full benefit of the safety guarantee with no per-call-site audit burden.

Key idea: Rust in the Windows kernel is not magic. It is a finite, typed, fuzzable, reviewable boundary between safe Rust and unsafe C interop. The safety guarantee of any module is exactly as strong as the audit of that boundary -- which is exactly what makes it engineering policy rather than a wishful slogan.

That is the strategy in the abstract. What does it actually look like on disk in Windows 11 24H2 in May 2026?

6. What Actually Ships in Windows 11 24H2 in 2026

This section is an inventory of artefacts you can verify yourself: files on disk, GitHub repositories, KB articles, conference keynotes. Six subsections, each with receipts.

6.1 `win32kbase_rs.sys` -- the in-kernel GDI region and shape engine

File location: %SystemRoot%\System32\win32kbase_rs.sys. Reader-verifiable on any Windows 11 24H2 install. This is the binary the article opened on.

Original scope at the April 2023 announcement: the Win32k GDI region and shape engine, about 36,000 lines of Rust, behind a feature flag, with at least one syscall in the Windows kernel implemented in Rust [@register-2023-04-27]. By July 2023 the binary was visible in Canary Insider Preview Build 25905 with the GDI region implementation called out by name in the Windows Insider blog [@insider-25905].

The 2025 expansion surface is the Enhanced Metafile Format / EMF+ metafile-parsing path. The Check Point Research disclosure -- whose call flow §1 walks through in prose and the diagram below replays -- documents the bug; KB5058499, dated 28 May 2025, hardens the bounds check upstream and ships as a preview update for OS Build 26100.4202 [@checkpoint-dof; @kb5058499].

sequenceDiagram participant App as Untrusted process participant K as Win32k C dispatcher participant R as win32kbase_rs.sys (Rust) participant Panic as core::panicking App->>K: NtGdiSelectClipPath (malformed EMF+ metafile) K->>R: parse EmfPlusDrawBeziers record R->>R: build path with mismatched point count R->>R: region_from_path_mut() indexes out of bounds R->>Panic: panic_bounds_check (safe Rust detects OOB) Panic->>Panic: panic = abort (no unwinder in no_std) Panic-->>K: bugcheck SYSTEM_SERVICE_EXCEPTION K-->>App: machine bluescreens (DoS, not RCE) Note over R,K: Microsoft fixed in KB5058499 on May 28, 2025

The article does not claim a 2026 line-of-code figure for win32kbase_rs.sys. The most recent first-party number is the April 2023 ~36,000 figure quoted to The Register; no first-party Microsoft source has published a refresh. Open Problem P1 in section 9 keeps that an honest open question.Earlier drafts of articles like this one have asserted "over 100,000 lines of in-kernel Rust by 2026." That number is not in the primary record. The empirical claim we can make is that the binary exists, the GDI region engine is in Rust, the EMF parser is partly in Rust, and the binary is observably larger and more functional in 2026 than the 2023 ship -- but the actual line count is unpublished.

6.2 DWriteCore -- user-mode Rust in the Windows App SDK

DWriteCore is the standalone, distributable text-rendering and OpenType-shaping engine that ships through the Windows App SDK. At the April 2023 BlueHat IL announcement Weston quoted about 152,000 lines of Rust plus about 96,000 lines of C++, with a 5 to 15% performance improvement on selected OpenType shaping paths [@register-2023-04-27]. Russinovich at RustConf 2025 framed the team size and timeline: "Two Microsoft developers did it in six months -- 154,000 lines of code" [@newstack-russinovich]. DWriteCore is strictly user mode. The distribution channel is Windows App SDK 1.2 and above, not Windows 11 22H2/23H2 system updates. It is the user-mode counterpart to the kernel-mode win32kbase_rs.sys, not the same thing.

6.3 The `windows-drivers-rs` crate suite

The driver-development face of Microsoft's Rust effort is microsoft/windows-drivers-rs [@windows-drivers-rs]. The repository contains six crates:

wdk -- safe wrappers over the Windows Driver Kit
wdk-sys -- bindgen-generated raw FFI bindings
wdk-alloc -- the GlobalAlloc shim onto ExAllocatePool2 / ExFreePoolWithTag
wdk-build -- build script infrastructure for Cargo.toml
wdk-panic -- the panic_handler implementation with panic = "abort"
wdk-macros -- procedural macros (driver entry-point, IOCTL routing, etc.)

The cargo-wdk subcommand wraps link.exe, inf2cat, and signtool so cargo build does the right thing in a developer-mode signed driver workflow. November 2025: cargo-wdk became publishable on crates.io [@techcommunity-rust-drivers]. The companion samples repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples for KMDF and UMDF [@windows-rust-samples].

Note: The windows-drivers-rs README is explicit: "still in early stages of development and is not yet recommended for production use" [@windows-drivers-rs]. Treat the crate suite as a developer-preview toolchain. KMDF 1.33-era bindings are on crates.io; WDM and UMDF are possible with wdk-build modification. LLVM 17 is pinned because LLVM 18 has an ARM64 bindgen bug.

6.4 OpenVMM, OpenHCL, and Hyperlight -- the virtualization-side Rust

microsoft/openvmm is a modular, cross-platform Virtual Machine Monitor written in Rust. The README is candid about scope: OpenVMM "can function as a traditional VMM, [but] OpenVMM's development is currently focused on its role in the OpenHCL paravisor" [@openvmm-github; @openvmm-guide]. OpenHCL is the Rust paravisor for AMD SEV-SNP and Intel TDX confidential virtual machines -- a guest-side software component that sits between the hardware-isolated VM and the host, mediating the small set of operations that have to round-trip [@phoronix-openhcl]. Hyperlight is Microsoft's Azure-side micro-VMM for very-low-latency function execution, with cold-start times in the low millisecond range [@newstack-russinovich].

A common confusion: OpenVMM is *not* the production [Hyper-V VSP (Virtualisation Service Provider) front-end](/blog/hyper-v-enlightenments-vmbus-and-the-synthetic-device-model/) that ships inside Windows 11 24H2. OpenVMM is a separate Rust VMM whose primary production deployment in 2026 is as the OpenHCL paravisor for confidential VMs in Azure [@openvmm-github]. The Rust status of the in-Windows Hyper-V VSP front-end has not been publicly announced; we treat it as Open Problem P6 in section 9.

6.5 The first in-box Rust drivers (Surface)

In July 2025, Microsoft's Surface team confirmed that several new Copilot+ Surface PCs ship with drivers written in Rust [@winbuzzer-surface; @thurrott-rust]. The drivers are Microsoft-internal -- shipped under the Surface OEM identity, signed through Microsoft's own driver-signing keys, exempted from the WHCP path that third parties must traverse. The Register, reporting in September 2025, summarised the third-party status: "There is also work underway to use Rust in the Windows kernel itself, some of which shipped in Windows 11 24H2" but no production third-party Rust driver has yet shipped under WHCP, because CodeQL's Rust support is in public preview at version 2.22.1 and the WHCP-validated version is still 2.21.4 [@register-2025-09-04].

6.6 The toolchain itself

The toolchain is the boring foundation that makes everything above possible. The shape, as of mid-2026:

Compiler: a recent stable rustc plus the MSVC linker. No specific minimum version is pinned by the public README; the LLVM dependency through bindgen is what determines the version floor [@windows-drivers-rs].Earlier coverage has speculated about a "rustc 1.72+" minimum version pin for the Microsoft kernel target. We have not found a first-party Microsoft source that pins this exact number. The README pins LLVM 17 (the bindgen LLVM, not the rustc LLVM) and is silent on the rustc minimum version.
Target: a custom no_std kernel target, not upstreamed to rust-lang/rust. Third-party reproducibility is therefore limited.
Bindings: bindgen-generated extern "system" declarations from WDK headers; LLVM 17 pinned because of the LLVM 18 ARM64 bug.
Allocator: wdk-alloc implementing GlobalAlloc over ExAllocatePool2 / ExFreePoolWithTag.
Panic handler: wdk-panic with panic = "abort".
Build orchestration: cargo-wdk plus cargo-make.
Verification: MIRI (where the code is portable enough to interpret), Driver Verifier (always-on inside the kernel test loop), OneFuzz and WinAFL for fuzzing, CodeQL with Rust support in public preview.

Russinovich announced at RustConf 2025 that Microsoft is also working on a "Cargo plugin for MSBuild," which would let MSBuild-driven internal builds invoke cargo cleanly [@newstack-russinovich]. Across Microsoft, Rust shows up in many places beyond Windows: SymCrypt-in-Rust, the Project Mu firmware effort, Azure Caliptra, the Azure Integrated HSM, and components of Azure Data Explorer all use Rust today [@infoq-russinovich]. The cross-context Microsoft Rust footprint is much larger than the in-Windows-kernel footprint alone, which gives the kernel effort upstream pressure to keep evolving.

Microsoft's posture is articulated and shipping. Is this a Microsoft idiosyncrasy or a cross-vendor convergence?

7. Linux, Android, Apple, CHERI: The Cross-Vendor Picture

Microsoft is not alone. The convergence is industry-wide -- with structurally different details per vendor.

Rust for Linux. Under maintainer Miguel Ojeda, Rust support landed in mainline Linux 6.1 in December 2022 [@rust-for-linux]. The "experimental" label was removed in late 2025. In-tree Rust drivers today include the AMCC QT2025 PHY, Android Binder, the ASIX PHY, DRM Panic QR, the Nova GPU driver (a long-term NVIDIA-replacement effort), Null Block, and the Tyr GPU; out-of-mainline-tree work includes the Apple AGX driver shipping on Asahi Linux, NVMe, and PuzzleFS [@rust-for-linux]. The structural difference from Microsoft's path is upstream: Linux forbids bindgen for in-tree drivers. Every Rust binding to a kernel C struct or function must be hand-reviewed and accepted onto LKML. The acceptance criteria are public; the upstream community has been contested -- Wedson Almeida Filho resigned in September 2024 citing non-technical conflicts -- but the project continues under Ojeda and the kernel maintainers' summit has reaffirmed it.

Android. Google's September 2024 "Eliminating Memory Safety Vulnerabilities at the Source" post is the empirical anchor for this article's policy claim [@google-android-2024]. The numbers we summarised in section 5 (76% in 2019 to 24% in 2024) come from this post. The strategy is identical to Microsoft's: write new code in Rust, leave most existing C and C++ alone, observe the long-run share of memory-safety bugs drop as the old code stops being modified. Android is the proof of concept that the new-code policy works at scale.

Apple. No public kernel-Rust commitment. XNU, Darwin, and IOKit remain C, C++, and Swift. The Asahi GPU project -- which lets Apple Silicon Macs boot Linux with full GPU acceleration -- is written in Rust and runs Apple hardware. But that is Rust running on Linux on Apple silicon, not Rust in Apple's own operating system. As of mid-2026, Apple has not publicly announced a Rust-in-kernel program.

CHERI and CHERIoT. The structural alternative to "Rust for new code" is "capability hardware that enforces memory safety on every dereference, including for legacy C and C++." CHERI is the Cambridge and SRI International project that extends conventional instruction set architectures with capability pointers -- tagged, bounded, monotonic references that the hardware checks at every load and store [@cheri-cambridge]. Arm's Morello prototype processor, released in January 2022, is the first commercial-class implementation. CHERIoT is Microsoft's microcontroller adaptation, a CHERI-extended RISC-V profile aimed at embedded and IoT workloads [@cheriot-org]. The CHERIoT RTOS lives at microsoft/cheriot-rtos [@cheriot-rtos-ms]. Structurally CHERI is different from Rust: it does not require a language rewrite, because the hardware enforces spatial and temporal safety on whatever language emits the pointers. Microsoft maintains both lines in parallel -- Rust for general-purpose Windows code, CHERIoT for embedded silicon -- and the two paths are complementary at the platform level.

Project Verona. Still alive as Microsoft Research [@verona-github; @verona-msr]. Publications at OOPSLA and PLDI. Not productising. Region-based concurrent ownership answers a different question from Rust's per-object model. Verona's value to the kernel-Rust effort was the academic credibility it lent the safer-systems-language thread; as a productisation candidate it remains unpursued.

flowchart LR subgraph Windows W1["win32kbase_rs.sys
Rust GDI/EMF"] W2["windows-drivers-rs
preview"] W3["CHERIoT for IoT
MSR plus partners"] W4["HVCI, CFG, CET
mitigations stack"] end subgraph Linux L1["Rust for Linux
mainline since 6.1"] L2["Hand-reviewed bindings
no bindgen in-tree"] end subgraph Android A1["New code in Rust
76 percent to 24 percent"] A2["Existing C / C++
left in place"] end subgraph Apple AP1["XNU in C and C plus plus
no public Rust commitment"] AP2["Asahi GPU in Rust
on Linux"] end subgraph Hardware H1["Arm Morello
CHERI prototype 2022"] H2["CHERIoT silicon"] end W1 --> Common["memory-safe by default
for new code
plus targeted rewrites"] W2 --> Common L1 --> Common A1 --> Common Common --> Defense["defence in depth
with mitigations stack
plus CHERI hardware where available"] W3 --> Defense W4 --> Defense H1 --> Defense H2 --> Defense

The pattern across the table is consistent. Every major operating-system vendor's safest forward path is some combination of (Rust for new code) + (CHERI-class hardware capabilities where the silicon supports them) + (the existing mitigations stack as defence-in-depth). No vendor is rewriting wholesale. The vendors differ on bindgen-versus-hand-written bindings, on in-tree process discipline, on capability-hardware availability, and on the relative weight of the three threads. They agree on the shape.

A compact decision matrix may help architects compare the seven approaches that were considered in the source survey.

Approach	Closes bug class	Worst-case crash	Hardware requirement	Production in Win 11 24H2
Legacy C/C++ with `/GS`, DEP, ASLR, CFG, CET	No (raises cost)	Memory corruption to exploitation	None (CET on Tiger Lake+)	Yes (default)
Rust in-kernel modules	Yes (covered modules)	Rust panic to kernel BSOD	None	Yes (`win32kbase_rs.sys`)
`windows-drivers-rs` for third-party drivers	Yes (per module)	Driver panic to bugcheck	None	Preview only
CHERI / Arm Morello capability hardware	Yes (all pointers, all languages)	Capability fault, process aborted	Yes (Morello, CHERIoT)	No (embedded only)
Verification (MIRI, RustBelt, formal proofs)	Yes (where proofs cover)	Caught at build time	None	Tooling only
OpenVMM / OpenHCL (Rust paravisor)	Yes (paravisor surface)	Paravisor panic in confidential VM	TDX or SEV-SNP CPU	Yes (Azure confidential VMs)
AI-assisted C-to-Rust migration	Aspirational	Per migrated module	None	Research only

The convergence is real. The strategy is articulated. So what cannot Rust-in-kernel do, even when everything goes right?

8. Four Theoretical Limits Rust-in-Kernel Cannot Escape

This section is the corrective. Even when everything goes right, Rust-in-kernel runs into four principled limits.

Limit 1: the unsafe boundary is irreducible. Any Rust module that interoperates with the C kernel must call into it; the FFI is unsafe by construction. The safety guarantee is exactly as strong as the audit of the unsafe blocks. This is not a flaw in Rust; it is a property of any safe-language-in-an-unsafe-substrate adoption. Inside unsafe, Rust does not check what you do; it trusts the human review. The audit therefore has to be load-bearing. The windows-drivers-rs README's statement that "drivers ... still need to make use of unsafe blocks for interacting with the Windows operating system" is the candid admission of this limit [@windows-drivers-rs; @register-2025-09-04].

Limit 2: a Rust panic at high IRQL is a kernel bugcheck. Because panic = "abort" is the only sound policy for no_std kernel binaries, and because at IRQL ≥ DISPATCH_LEVEL the kernel has nowhere to send a panic except the system-wide bugcheck, a correctly-fired Rust safety check in kernel context becomes a BSOD. Check Point's "Denial of Fuzzing" disclosure is dispositive: Rust correctly detected the out-of-bounds access, but the operational response was SYSTEM_SERVICE_EXCEPTION [@checkpoint-dof; @cybersecuritynews]. Rust transforms memory-corruption CVEs into denial-of-service CVEs in the kernel context. It does not eliminate the CVE class.

Russinovich framed this limit as a feature, not a bug, at RustConf 2025:

This we view as a success ... a bug that would have actually resulted in a potential elevation of privilege, as opposed to a blue screen crash. -- Mark Russinovich, RustConf 2025 [@newstack-russinovich].

He is right operationally. A BSOD is far cheaper than a remote code execution. But the CVE class did not vanish; it shifted. The new class is "panic-in-kernel-context, denial of service." That is the bug class that any future Rust-in-kernel security architect has to plan for.

Limit 3: the legacy C and C++ kernel -- roughly thirty million lines on common engineering estimates -- will not be rewritten on any plausible timeline. Even Galen Hunt's "1 engineer, 1 month, 1 million lines of code" research aspiration -- explicitly clarified by Hunt himself as research, not a corporate mandate -- would require sustained multi-decade effort to clear the whole kernel [@register-2025-12-24; @infoworld-not-rewriting; @windowslatest-galen]. Realistically the kernel will keep most of its existing C and C++ for the foreseeable future. The wins come from partial rewrites of high-blast-radius modules plus the new-code policy. Existing modules that do not change do not need to be rewritten to benefit from the new-code policy -- that is the Android empirical observation [@google-android-2024] -- but they remain potential bug-class carriers nonetheless.

Limit 4: Rust + unsafe cannot beat hardware capabilities on every bug class. CHERI and CHERIoT detect spatial and temporal memory-safety violations at every pointer dereference, including across the C and C++ legacy substrate that language-level approaches cannot rewrite [@cheri-cambridge; @cheriot-org].Spatial safety means accesses stay within an object's bounds; temporal safety means accesses do not touch freed objects. CHERI capabilities enforce both at the hardware ISA level for every load and store. The most defensible posture combines Rust for new code with CHERI-class hardware where the silicon supports it. Rust is necessary; on legacy code, it is not sufficient. The CHERIoT line at Microsoft (the microsoft/cheriot-rtos repository [@cheriot-rtos-ms]) is the explicit acknowledgement that Microsoft is investing in both layers because neither alone closes the question.

Key idea: Rust transforms memory-corruption CVEs into denial-of-service CVEs in the kernel context. It does not eliminate the CVE class -- and that is still a major win, but it is the actual win, not the marketing one.

If the policy is sound but the limits are real, what does the next decade actually look like in numbers and named open problems?

9. The 2026 Frontier and the Ten-Year Trajectory

Open problems matter when they are named. The state-of-the-art survey identified eight; each gets a paragraph here.

P1. The public corpus size of in-kernel Rust. The most recent first-party Microsoft figure remains the April 2023 number quoted to The Register: about 36,000 lines of Rust in win32kbase_rs.sys [@register-2023-04-27]. There has been no first-party refresh since. Any 2026 line-of-code claim greater than this -- including the "over 100,000 lines" framing that has circulated in secondary press -- is unsourced. We treat it as an open question.

P2. Upstreaming the no_std kernel target. Microsoft's Rust kernel target is not in rust-lang/rust. Third-party driver developers cannot reproduce the toolchain exactly without internal Microsoft assets. The windows-drivers-rs repository contains the public-facing crates and the cargo-wdk build orchestration, but the underlying compilation target is private [@windows-drivers-rs]. Upstreaming it would let external WHCP-bound driver authors build against the same toolchain as Microsoft's in-box drivers.

P3. WHCP and driver certification. As of September 2025, CodeQL supports Rust at version 2.22.1 (public preview), while only version 2.21.4 is "validated for use with WHCP" [@register-2025-09-04]. No production third-party Rust driver has yet shipped through WHCP. The certification path is being assembled in public; it is not yet open for production third-party submissions.

P4. Panic-as-BSOD mitigation. This is the Check Point bug class -- a correct Rust safety check in kernel context becomes a system-wide bugcheck [@checkpoint-dof]. The options are imperfect. Unwinding instead of aborting is unsound at high IRQL because the unwinder needs to run code that may itself page-fault. IRQL-aware fallbacks (degrade gracefully when at high IRQL, panic when at PASSIVE_LEVEL) are doable but add complexity. More conservative bounds-checking patterns in hot paths can reduce the panic surface but cannot eliminate it. This is an active research and engineering frontier.

P5. Mechanised formal verification of kernel unsafe blocks. RustBelt-grade proofs exist for specific libraries [@rustbelt-popl-page]. Production-scale verification of arbitrary kernel unsafe is open. The proof obligations are statable thanks to the RustBelt framework; discharging them at production scale across an entire driver's worth of unsafe blocks is not yet routine.

P6. The Hyper-V VSP migration. OpenVMM is in flight as the modular cross-platform Rust VMM whose primary deployment in 2026 is the OpenHCL paravisor [@openvmm-github; @phoronix-openhcl]. The in-Windows Hyper-V VSP front-end's Rust status is unannounced. This is the Stage-3 P6 open problem; the article does not assert that the production Hyper-V VSP has been migrated.

P7. AI-assisted migration. Galen Hunt's "1 engineer, 1 month, 1 million lines of code" target is the headline aspiration [@register-2025-12-24]. The methodological dependencies are non-trivial. Code-graph construction has to be accurate. AI translation quality has to be high. Semantic-equivalence preservation has to be checkable. Manual-intervention burden at the unsafe-FFI boundary will be significant. Recent academic work on type-directed C-to-safe-Rust translation -- Compiling C to Safe Rust, Formalized (Fromherz and Protzenko, OOPSLA 2026) -- shows what mechanical, proof-grade translation looks like for restricted subsets [@arxiv-c-to-rust], and that is the direction Russinovich has framed as preferred over LLM-only approaches.

On 24 December 2025, Galen Hunt's LinkedIn post -- *"My goal is to eliminate every line of C and C++ from Microsoft by 2030 ... Our North Star is 1 engineer, 1 month, 1 million lines of code"* -- was reported by *The Register* under the headline "Microsoft wants to replace its entire C and C++ codebase" [@register-2025-12-24]. The press cycle briefly suggested Microsoft was rewriting Windows in Rust. Within days, the picture was corrected. Hunt's own clarification: "My team's project is a research project. We are building tech to make migration from language to language possible. ... [The intent was] to find like-minded engineers, not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint" [@infoworld-not-rewriting]. Microsoft's communications head Frank X. Shaw confirmed to Windows Latest that the company has no plans to rewrite Windows 11 using AI [@windowslatest-galen]. The "1 / 1 / 1M" project is a research aspiration inside the CoreAI group, not a Windows roadmap. Several outlets republished without that correction; the *InfoWorld* and *Windows Latest* pieces are the load-bearing references for the accurate framing.

P8. Ten-year trajectory. Three independent dynamics will determine the shape: Microsoft's conversion rate of existing high-blast-radius modules, the rate at which new code is written in Rust by default, and the empirical Android curve as a reference point [@google-android-2024]. The conclusion is not that the legacy kernel will be rewritten. The conclusion is that the share of memory-safety CVEs in Windows is likely to follow a trajectory shaped like Android's -- a multi-year decline driven by new-code-in-Rust plus targeted rewrites, with the absolute floor set by the residual unsafe audit surface at the FFI boundary and the not-rewritten C and C++ that retains some level of new development.

Quick reference for the questions almost everyone asks comes next. First, what you can do on Monday.

10. Practical Guide

Four audiences. Each gets a subsection.

10.1 For Windows-internals and security researchers

Identifying Rust-implemented kernel binaries is the first step. The Microsoft internal convention is the _rs suffix; the canonical example is %SystemRoot%\System32\win32kbase_rs.sys. The fastest verification:

Note: Open PowerShell on any Windows 11 24H2 machine and run: Get-Item C:\Windows\System32\win32kbase_rs.sys. If the file is present, you are running a Windows with kernel-mode Rust code today.

{// Demonstrates the logic of: Test-Path "\$env:SystemRoot\\System32\\win32kbase_rs.sys" const knownRustKernelBinaries = ["win32kbase_rs.sys"]; // Insider Preview 25905 (July 12, 2023) and later const systemRoot = "C:\\\\Windows"; const found = knownRustKernelBinaries.map(b => systemRoot + "\\\\System32\\\\" + b); for (const path of found) { console.log("Expected: " + path); } console.log("On a real Windows 11 24H2 install, this file is present.");}

Reverse engineering: dumping strings against win32kbase_rs.sys will surface Rust panic markers like panic_bounds_check, core::panicking::panic, and core::result::unwrap_failed -- the names the Rust standard library inserts when bounds checks or Option::unwrap calls misfire [@cybersecuritynews]. The Rust v0 name mangling scheme starts with _R and uses a Punycode-derived encoding for non-ASCII characters [@rust-rfc-2603]; tools that understand the scheme (recent IDA, recent Ghidra, rustfilt) demangle it. Functions like region_from_path_mut will appear in the binary as mangled _R... symbols.

For reproducing Check Point's "Denial of Fuzzing" methodology: the public write-up names WinAFL plus WinAFL-Pet as the orchestration tier, with crafted EMF and EMF+ metafile corpora driving NtGdiSelectClipPath and other Win32k entry points; BugId handles crash triage; MemProcFS handles memory-dump forensics [@checkpoint-dof]. The toolchain is reproducible on a research VM.

The Check Point harness suggests four productive bug-class targets when fuzzing the Rust kernel surface: (1) `panic_bounds_check` firings at array-indexing sites in geometry pipelines; (2) integer-overflow-checked-arithmetic divergences from C++ behaviour (Rust panics on overflow in debug builds, wraps in release -- check your build profile); (3) allocator-out-of-memory at the `wdk-alloc` boundary, where `ExAllocatePool2` can return `NULL` under pressure; (4) mismatches at `unsafe`-block invariants where a Rust safe wrapper trusts an assertion the C kernel does not actually guarantee.

10.2 For Windows driver developers evaluating Rust

The setup recipe for windows-drivers-rs:

Clone microsoft/windows-drivers-rs and microsoft/Windows-rust-driver-samples [@windows-drivers-rs; @windows-rust-samples].
Install a recent stable rustc with the x86_64-pc-windows-msvc toolchain.
Install the Windows Driver Kit (WDK) from Microsoft Learn.
Install LLVM 17. Not LLVM 18 (ARM64 bindgen bug); LLVM 19 is the awaited fix [@windows-drivers-rs].
Install cargo-make.
Enter an eWDK developer prompt so MSBuild and the WDK environment variables are present.
cargo install cargo-wdk (or take the version published on crates.io as of November 2025) [@techcommunity-rust-drivers].

{// The shape of the manifest documented in microsoft/windows-drivers-rs README. const cargoToml = [ "[package]", "name = \\"example-driver\\"", "version = \\"0.1.0\\"", "edition = \\"2021\\"", "", "[lib]", "crate-type = [\\"cdylib\\"]", "", "[profile.dev]", "panic = \\"abort\\"", "lto = true", "", "[profile.release]", "panic = \\"abort\\"", "lto = true", "", "[dependencies]", "wdk = \\"*\\"", "wdk-sys = \\"*\\"", "wdk-alloc = \\"*\\"", "wdk-panic = \\"*\\"", "", "[build-dependencies]", "wdk-build = \\"*\\"", "", "[package.metadata.wdk.driver-model]", "driver-type = \\"KMDF\\"", "kmdf-version-major = 1", "target-kmdf-version-minor = 33" ].join("\\n"); console.log(cargoToml);}

KMDF 1.33-era bindings are on crates.io. WDM and UMDF are possible with wdk-build modification but are not the documented happy path [@windows-drivers-rs]. The WHCP certification path is not yet greenlit for production third-party Rust drivers [@register-2025-09-04]. When not to choose Rust: driver classes with mature, well-fuzzed C and C++ equivalents, small attack surfaces, and broad cross-vendor deployments where churn cost outweighs Rust's safety benefits. The first generation of production third-party Rust drivers will likely be filter drivers, virtual-device drivers, and parsers for untrusted formats -- exactly the surfaces where Microsoft's own first-party Surface drivers have shipped [@winbuzzer-surface; @thurrott-rust].

10.3 For security architects

Strategic frame: treat Rust adoption as a long-term policy lever, not a near-term mitigation. For the next five years, assume the kernel is still 95%+ C and C++. Treat in-kernel Rust as incremental risk reduction at the modules where it lands -- the GDI region engine, the EMF parser, future surfaces around metafile and graphics parsing, possibly virtualization plumbing. Treat the unsafe-FFI boundary as the audit frontier; concentrate fuzzing, code review, and CodeQL-Rust analysis there. Rely on the existing mitigations stack -- HVCI, CFG, XFG, CET, Driver Verifier, WDAC -- as defence-in-depth that Rust does not replace [@learn-cfg; @learn-gs; @learn-dep]. Plan for the panic-as-BSOD class as the new DoS surface, and architect monitoring (event-log mining for SYSTEM_SERVICE_EXCEPTION rates, fleet telemetry for Rust-panic markers) accordingly.

10.4 For security researchers fuzzing the Rust kernel surface

Check Point's methodology is the public reference [@checkpoint-dof]; the productive bug classes and the WinAFL + WinAFL-Pet + BugId + MemProcFS pipeline are described in §10.1 above. Two items are specific to the Rust kernel surface and worth adding here. First, integrate CodeQL's Rust query pack once 2.22.1+ ships in your build pipeline -- only 2.21.4 is WHCP-validated today [@register-2025-09-04]. Second, the empirical companion-CVE pattern: the same Check Point campaign that surfaced "Denial of Fuzzing" also produced several C/C++ GDI vulnerabilities (CVE-2025-30388, CVE-2025-53766, CVE-2025-47984), which suggests there is more to find in the GDI region of Win32k regardless of language [@checkpoint-drawn].

11. Frequently Asked Questions

No. Microsoft's stated policy is "memory-safe by default for newly written code" plus targeted rewrites of high-blast-radius modules. The legacy C and C++ kernel is not being rewritten on any announced timeline. Galen Hunt's "1 engineer, 1 month, 1 million lines of code" framing is a research target inside Microsoft's CoreAI group; Frank X. Shaw, head of Microsoft's communications, confirmed within days of the December 2025 LinkedIn post that the company has no plan to rewrite Windows 11 using AI [@windowslatest-galen; @infoworld-not-rewriting; @register-2025-12-24]. No. Rust eliminates the memory-corruption CVE class *in the modules it covers*. It does not eliminate logic bugs, race conditions, or denial-of-service vulnerabilities. Check Point Research's "Denial of Fuzzing" disclosure -- patched in KB5058499 on 28 May 2025 -- is the dispositive case. Rust correctly detected an out-of-bounds access in `region_from_path_mut()` inside `win32kbase_rs.sys`; because `panic = "abort"` is mandatory in `no_std` kernel binaries, the response was a system-wide BSOD rather than a remote code execution [@checkpoint-dof; @kb5058499]. No. DWriteCore is user-mode code distributed through the Windows App SDK 1.2 and above. The kernel-mode Rust binary is `win32kbase_rs.sys`. The two are often conflated in secondary coverage because David Weston announced both at BlueHat IL 2023 on the same slide deck. DWriteCore is roughly 152,000 lines of Rust plus 96,000 lines of C++; `win32kbase_rs.sys` is the in-kernel piece, originally about 36,000 lines [@register-2023-04-27]. No. The public Microsoft GitHub repository is `microsoft/windows-drivers-rs`. The crate suite contains six crates named `wdk`, `wdk-sys`, `wdk-alloc`, `wdk-build`, `wdk-panic`, and `wdk-macros`. The Cargo subcommand is `cargo-wdk`. There is no "WDR" abbreviation in the official Microsoft naming. The companion samples repository is `microsoft/Windows-rust-driver-samples` [@windows-drivers-rs; @windows-rust-samples]. No. The originating talk was Matt Miller's at BlueHat IL in early February 2019, titled *Trends, Challenges, and Shifts in Software Vulnerability Mitigation*. The deck is in the `microsoft/MSRC-Security-Research` GitHub repository. Weston and Mark Russinovich later operationalised the figure in their own talks. The Microsoft Security Response Center re-stated it in plain prose in two essays in July 2019 [@miller-bluehat-2019; @msrc-proactive-2019; @msrc-safer-2019; @infoq-mitigating]. No. OpenVMM is a separate modular Rust VMM whose primary 2026 production deployment is as the OpenHCL paravisor for AMD SEV-SNP and Intel TDX confidential virtual machines [@openvmm-github; @phoronix-openhcl]. Hyperlight is the Azure-side production Rust micro-VMM with sub-2-millisecond cold-start times. The in-Windows Hyper-V Virtualisation Service Provider (VSP) front-end's Rust status has not been publicly announced; that is Open Problem P6 in the article's frontier section [@newstack-russinovich].

<StudyGuide slug="rust-in-the-windows-kernel-2026-field-guide" keyTerms={[ { term: "win32kbase_rs.sys", definition: "The first Rust-implemented Windows kernel binary; contains the Win32k GDI region/shape engine and, by 2025, parts of the EMF/EMF+ metafile parser." }, { term: "panic = abort", definition: "The Rust compilation profile that converts a panic into an immediate abort rather than stack unwinding; mandatory for no_std kernel binaries." }, { term: "no_std", definition: "Rust crate attribute opting out of the standard library; required for kernel binaries because std assumes OS services the kernel itself provides." }, { term: "GlobalAlloc", definition: "The Rust trait for the global memory allocator; in kernel Rust it is implemented by wdk-alloc over ExAllocatePool2/ExFreePoolWithTag." }, { term: "FFI", definition: "Foreign Function Interface; the ABI-crossing mechanism by which Rust calls C kernel functions. Every FFI call in kernel Rust is an unsafe block." }, { term: "CFI", definition: "Control-Flow Integrity; the mitigation family (CFG, XFG, CET) that defends the control-flow graph; by construction blind to data-only attacks." }, { term: "DOP", definition: "Data-Oriented Programming; Hu et al. (IEEE S&P 2016) proved data-only attacks are Turing-complete and invisible to every CFI variant." }, { term: "IRQL", definition: "Interrupt Request Level; the Windows kernel per-CPU priority. At IRQL >= DISPATCH_LEVEL a panic has nowhere to go except the system bugcheck." } ]} />

The article's smallest claim is also its largest. Rust is in the Windows kernel today, in production, with a real binary you can list at a real path. The article's largest claim is its smallest. The realistic ten-year shape is not a Windows rewrite; it is a policy that compounds, over decades, across modules whose authors choose Rust on first contact. The most defended forward posture combines Rust for new code, targeted rewrites of high-blast-radius modules, CHERI-class hardware capabilities where silicon supports them, and the existing mitigations stack as the patient defence-in-depth backstop. Each piece is partial. The combination is the answer to the 70-percent figure that Matt Miller stood up and named in Tel Aviv in early February 2019.

Now go check C:\Windows\System32\win32kbase_rs.sys. It is there.

Parag Mali - tag: secure-future-initiative

The Layer Above the OS: The Windows Security Wars Part 6 (2023-2026)

1. Twenty Bytes at 04:09 UTC

2. Three Lineages Converging

Lineage 1: Identity-authority forgery

Lineage 2: Third-party AV in the kernel

Lineage 3: AI as a security boundary

3. Pre-CSRB Posture and Storm-0558

The four pre-conditions

4. Five Threads Across 2023-2026

4.1 The CSRB and the Secure Future Initiative

4.2 Recall as the AI-feature security-review worked example

4.3 CrowdStrike and the road to WESP

4.4 AI threat-model arrivals

4.5 Defensive arrivals across the era

5. The Insight

The third-party kernel privilege insight

The institution-is-the-boundary insight

The AI agent is a new trust principal insight

6. State of the Art, May 2026

Cross-platform comparison

7. Competing Approaches

Inside the kernel or outside

Hardware-rooted on-device or cloud-attested

Whether the AI trust boundary can be formalized at all

8. Theoretical Limits

The Forshaw bound on Recall

The trusted-insider-with-physical-access bound on hardware enclaves

The 4096-byte problem in post-quantum signatures

The AI-agent-judgment bound

The Rice's Theorem bound on driver validation

9. Open Problems

10. Practical Guide

11. Frequently Asked Questions

Forged from 2016: How Storm-0558 Turned One Stolen Signing Key into U.S. Government Email Access

1. A 2016 Key That Forged 2023 Government Email

2. The Lineage of Signing-Key Forgery

3. The Architecture Before Storm-0558

4. The Attack Chain, Step by Step

4.1 Key acquisition (mechanism unknown)

4.2 Token forgery

4.3 The cross-tier validation flaw

4.4 Mailbox access and exfiltration

4.5 The broader blast radius (potential, not exploited)

5. Why a Paying Customer, Not Microsoft, Caught It

6. The Public Reckoning -- CSRB, Retracted Hypothesis, Congressional Testimony

6.1 The CSRB's authority and process

6.2 The September 2023 hypothesis and the March 2024 retraction

6.3 The CSRB's findings

6.4 Brad Smith's June 13, 2024 testimony

7. The Architectural Response -- SFI and the Identity-Plane Re-Architecture

7.1 SFI: launch, expansion, motivation arc

7.2 HSM-bound key custody plus automatic rotation

7.3 Signing operations inside Confidential Computing TEEs

7.4 Tenant-issuer separation enforced in hardened validation libraries

7.5 Logging as a commodity, not a premium

8. How Other Cloud Providers Custody Signing Keys

9. Theoretical Limits

9.1 The core asymmetry

9.2 The CSP-monoculture residual

9.3 The Microsoft-as-Storm-0558-victim recursion

9.4 The upper bound

10. Open Problems

11. What a Defender Should Do Today

11.1 For Microsoft 365 customers

11.2 For builders of multi-tenant SaaS that signs JWTs

11.3 For CISOs evaluating a cloud IdP

12. FAQ and Study Guide

Rust in the Windows Kernel: A Field Guide to the 2024-2026 Memory-Safety Refit

1. The Blue Screen That Wasn't a Bug

2. The 70-Percent Number and Why Mitigations Plateaued

3. Verona, windows-rs, and the Long Approach

4. Three Generations of Microsoft's Rust-in-Windows Effort

4.1 Generation 1 (2019 to early 2023): the prerequisites

4.2 Generation 2 (March to July 2023): the first ship

4.3 Generation 3 (2024 to mid-2026): expansion and toolchain rollout

5. Memory-Safe by Default for New Code + the Unsafe-FFI Boundary

6. What Actually Ships in Windows 11 24H2 in 2026

6.1 win32kbase_rs.sys -- the in-kernel GDI region and shape engine

6.2 DWriteCore -- user-mode Rust in the Windows App SDK

6.1 `win32kbase_rs.sys` -- the in-kernel GDI region and shape engine

6.3 The `windows-drivers-rs` crate suite