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

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 ^{[1] [2]}. 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 ^{[1] [3]}.

Hagenah called the tool TotalRecall and committed it to GitHub the same day ^[4]. 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" ^[2]. His description of why he released it, as quoted by Help Net Security: "They should know it can be dangerous" ^[1].

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

// 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\<user>\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 ^{[3] [1] [7]}. 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 ^[8]. Hagenah's TotalRecall, posted June 5, turned Beaumont's framing and Forshaw's filesystem-ACL bypass into a runnable artifact ^{[4] [1]}.

Each was load-bearing. Without any one of them, Microsoft's June 7 delay-and-recommit blog ^[5] 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 ^[9]. 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 ^[9]. 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.

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" ^{[3] [1]}. 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 ^{[1] [3]}. 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 ^{[3] [1]}

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 ^[8]. 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 ^[8]. The asterisks around non-security boundary pointed at the MSRC servicing criteria ^[10]: 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 ^{[4] [1] [2]}. 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 ^{[4] [2]}. Hagenah's stated motive, via Help Net Security: "They should know it can be dangerous" ^[1]. 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 ^[5]. Wired's coverage of the same announcement referred to Davuluri as "Microsoft's corporate vice president for Windows and devices" ^[7]. 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 ^[5].

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 ^[9]. That property is preserved in the Generation 3 architecture ^[6] and is reiterated in the IT administrator documentation ^[11]. The original engineering team did not get the privacy framing wrong as a category. They got the isolation framing wrong.

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 ^[8]: 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 ^[10]. 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 ^{[3] [1]}. 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 ^{[1] [3]}. 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 ^[10]. 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 ^{[3] [8]}. "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" ^[2]. This was an overstatement -- Beaumont and Forshaw both established that admin was not required. Subsequent coverage in Help Net Security used the stricter framing ^[1].

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 ^[12]. 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 ^[13].

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.

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 ^[5] 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 ^[6] and David Weston's companion SecurityWeek interview ^[15] together describe four security and privacy design principles and five architectural components.

The four principles, drawn from Davuluri's blog ^[6]:

1. The user is always in control. Recall is opt-in at setup, with Hello enrolment required before any snapshot capture.
2. 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.
3. 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.
4. 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 ^[6]. 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 ^[15]

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 ^[16]), 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 ^{[17] [18]}. The first-run experience in that build asks the user to opt in to saving snapshots and to enrol Windows Hello ^[17]. 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 ^[19], with broad rollout in the May 13, 2025 Patch Tuesday cycle ^[20]. 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 ^[11].

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.

The five components#

1. 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.
2. 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.
3. 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 ^[6].
4. 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.
5. 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 ^[6].

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 ^[16]. 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

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 ^[6]. Second, an unnamed third-party security vendor performed an independent review. Neither report is public. §9 will return to this transparency gap.

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 ^[14] and corroborated by the GA announcement ^[19]. The pattern is consistent: every Copilot+ PC carries TPM 2.0 services, but the attachment of those services varies by silicon vendor.

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 ^[11]. 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 ^[11]. 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 ^[17] and the developer integration page ^[23]. 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.

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 ^{[24] [25] [26]}. 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 ^[24] and the SQLCipher canonical pages ^{[25] [26]} 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 ^[26]. 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 ^[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#

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" ^[6]. 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 ^[28]. 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 ^{[28] [29]}.

Hagenah's verbatim characterisation, from the README: "No admin required. Standard user. No kernel exploit. No crypto bypass. Just COM calls." ^[28]. 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) ^[28]. 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 ^[28]

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 ^[30]. 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" ^[30]. The public release of the tool followed.

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

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 ^[10], 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 ^[31] 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 ^[6] 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 ^[6] 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 ^[10], 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 ^[6]. 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 ^[11] 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 ^[32]. 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 ^[32]. 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 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.

1. 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 ^{[16] [14]}.

2. 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" ^[11]; 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.

3. Data minimisation. Deploy the snapshot-retention and disk-allocation policies from the Manage Recall policy reference ^[11]. Fewer snapshots and shorter retention reduce the maximum size of any single exfiltration window.

4. 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 ^[11]. This is the operator-controlled complement to the in-enclave Purview EDM content filter.

5. 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.

6. 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.

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#

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.