# The Windows Security Wars Part 6: The Layer Above the OS
> How Storm-0558, CrowdStrike, and the Recall saga forced Microsoft to admit the biggest attack surface on a modern Windows PC is no longer the OS itself.
*Published: 2026-05-30*
*Canonical: https://paragmali.com/blog/the-windows-security-wars-part-6-the-layer-above-the-os*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**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](/blog/forged-from-2016-how-storm-0558-turned-one-stolen-signing-ke/) 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](/blog/the-thirteen-months-that-made-zero-trust-unavoidable-windows/) 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](/blog/krbtgt-the-account-that-owns-active-directory/)'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)](/blog/windows-kernel-code-integrity-2006-2026/) 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](/blog/your-face-is-not-your-password-inside-windows-hellos-hardwar/), 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](/blog/who-decided-this-token-is-good-a-field-guide-to-conditional-/); 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](/blog/inside-azure-confidential-vms-sev-snp-intel-tdx-and-the-para/) [@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](/blog/from-hotpatch-to-150-a-core-the-live-patch-pipeline-microsof/) -- 81% of enrolled devices compliant within 24 hours of Patch Tuesday -- and announced the [Rust rewrite of Surface UEFI firmware and Windows drivers](/blog/rust-in-the-windows-kernel-a-field-guide-to-the-2024-2026-me/), 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](/blog/microsoft-recall-2024-2026-re-architecture/). 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] |
> **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](/blog/the-day-85-million-devices-couldnt-boot----and-how-microsoft/) 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](/blog/agentic-identity-on-windows-when-the-process-acting-on-your-/) 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].
> **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](/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/) 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](/blog/beyond-bitlocker-the-three-file-level-encryption-layers-micr/) -- 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](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/), 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.