Digital Sovereignty & Cybersecurity  ·  27 August 2026

Windows Recall and the Lock on the Wrong Door

Microsoft built biometric authentication and a TPM-backed enclave to protect what Windows Recall captures. It never had to. The operating system underneath has never gated who is allowed to read your screen in the first place.
By Alan Wright  ·  The Haunted Lighthouse Limited  ·  Peel, Isle of Man

Microsoft has spent eighteen months describing Windows Recall in the language of user control and local, encrypted safety. The operational record, written mostly by independent researchers rather than by Microsoft's own disclosures, tells a narrower story: every headline claim is true at the sentence level and incomplete at the systems level.

Most of the coverage that followed this year's fresh round of findings flattened into "Recall is spying on you again," which isn't quite what's being reported. The encryption underneath Recall hasn't been broken by anyone. That correction matters, but it's not the interesting part of the story either. The interesting part is a question nobody chasing the encryption angle has been asking: what was actually stopping any of this before Recall existed.


What Microsoft promised

Recall was announced in May 2024 as a "photographic memory" for Copilot+ PCs: a background process that takes a screenshot every few seconds, runs on-device AI over each one to extract text and context, and indexes the result so a user can later search their own screen history in plain language. After the initial backlash, Microsoft rebuilt the feature around three public commitments: it is opt-in, it is encrypted, and, in the company's own framing, the user is always in control.


What actually ships

Recall is a Copilot+ exclusive; it needs an NPU, currently meaning Qualcomm, AMD or Intel silicon built for the job. Snapshots land in a local SQLite database (ukg.db), encrypted with AES-256-GCM inside a Virtualization-Based Security enclave tied to the device's TPM and Windows Hello identity, with a filter meant to keep passwords and other sensitive fields out of the index. None of that is fiction. The architecture is real, and by most accounts competently built. The question is whether it was built to defend the actual weak point.


Claim versus reality

Microsoft's claimOperational reality
“The user is always in control”Recall cannot be fully uninstalled, and the policy that governs it is scoped to Pro, Enterprise, Education and IoT Enterprise editions only; Home has no lever to lock the toggle off permanently.
“Encrypted, local storage”Decrypted data is handed live to an unsandboxed process, AIXHost.exe; same-user malware can read it straight out of memory with no admin rights and no exploit.
“Privacy filter for sensitive data”Independent testing in August 2025 found the filter still misses fields such as credit card numbers once the surrounding page drops words like “checkout” or “payment.”
“Committed to privacy and security”Microsoft has not published a formal GDPR compliance statement for the feature; the resulting data protection impact assessment is left to each deploying organisation.

“The user is always in control.” True of the toggle itself: Settings > Privacy & security > Recall & snapshots works identically on every Windows edition, off by default until the user opts in. What that claim glosses over is persistence. Recall cannot be fully uninstalled once present on a device, and app or website exclusions are configured per user with no way for an administrator to enforce them across a fleet. Microsoft's own policy documentation scopes the governing control, AllowRecallEnablement, to Pro, Enterprise, Education and IoT Enterprise editions; Windows 11 Home isn't in that list at all. A Home user who wants the toggle to stay off permanently, surviving a future reset, a different local account, or an update, has no supported way to lock it; only a registry edit, which is neither discoverable nor durable in the way a policy is. Control over a setting is real. Control over whether that setting stays put is a separate claim Microsoft doesn't quite make explicit.

“Encrypted, local storage.” The cryptography itself is not in dispute; even the researchers who keep finding problems agree the enclave holds. The gap sits one layer up, at the moment the feature is actually used. When a user authenticates via Windows Hello, the enclave decrypts the relevant data and hands it, live, to a rendering process called AIXHost.exe, which displays the timeline. That process carries no application sandbox and no code-integrity enforcement. In April 2026, researcher Alexander Hagenah published a proof of concept, Total Recall Reloaded, demonstrating that any process running as the same user, no elevation, no exploit, can inject into AIXHost.exe and read the decrypted screenshots and OCR text straight out of its memory as they flow through. As the tool's own documentation puts it, Microsoft built a vault and left the delivery route drywall. Separately, the function that deletes Recall's capture history carries no authentication check at all, meaning the same class of malware can wipe the evidence without ever needing to decrypt it. Microsoft closed Hagenah's report without assigning a CVE, describing the access pattern as working as designed. Researcher and vendor are describing the same boundary and disagreeing only on whether naming it in advance makes it acceptable.

“Privacy filter for sensitive data.” Independent testing by The Register found the sensitive-information filter worked reasonably well on standard e-commerce checkout pages but failed once a custom form dropped the contextual words the filter was keying on; a card number typed into a page with no mention of “payment” or “checkout” went straight into the database, unredacted. The filter is a genuine engineering effort, not vapourware, but it's marketed with the confidence of a control rather than the caveats of a best-effort classifier sitting in front of a system whose failure mode is a standing, searchable archive rather than one leaked message.

“Committed to privacy and security.” Microsoft has not published a formal compliance statement addressing GDPR for Recall. The UK Information Commissioner's Office said in May 2024 that it was making enquiries with Microsoft to understand the safeguards built in; no public resolution has surfaced since. Microsoft's own enterprise guidance acknowledges that Recall's default, comprehensive capture raises data-minimisation questions, and leaves the resulting DPIA to each deploying organisation's own data protection officer. A setup-screen disclosure is not a lawful-basis assessment, and Microsoft hasn't supplied one.


The wrong perimeter

Here is the reframe that makes the rest of this worth writing. None of the AIXHost.exe research matters to an attacker who doesn't need Recall at all. Windows has no broad equivalent of macOS's Transparency, Consent and Control framework, which gates screen recording behind an explicit, revocable, system-level permission. Windows has a narrower version of that idea: a privacy control, managed through CapabilityAccessManager, that governs apps using the modern Windows.Graphics.Capture API, scoped per packaged app identity and paired with a visible yellow capture border. Classic Win32 capture, BitBlt, PrintWindow, the DXGI Desktop Duplication API that most legitimate remote-access and screen-sharing tools already use, sits entirely outside that system. Any process running as the logged-in user can call those functions. No elevation, no prompt, no indicator, no policy to flip. This is precisely why commodity remote-access trojans and infostealers have shipped screen-capture-on-a-timer for years without needing to bypass anything, because there was never a lock on that door.

Which means Microsoft built a TPM-backed enclave, biometric gating and per-page AES-256 encryption to protect a screenshot archive, on an operating system that has never required consent for the thing that fills the archive. Injected, same-user malware of today's spec doesn't need Hagenah's technique, doesn't need to touch the enclave, doesn't need Recall's database at all. It can call BitBlt on its own schedule and collect the same pixels Recall would have, with zero OS-level obstacle in the way. The elaborate lock isn't guarding the weak point. The weak point was already open, and it predates Copilot+ by two decades.


Why this isn't just a Recall story

It would be easy to read this as a Microsoft-specific embarrassment and move on. That's the wrong lesson, because it hands Redmond a rebuttal for free: patch AIXHost.exe, add a CVE, call it fixed. The same structural failure keeps turning up wherever a vendor markets a compliance label as if it were an audited technical guarantee, sovereign residency claims, EU data-boundary marketing, a screenshot archive's encryption, and nobody outside the vendor relationship checks whether the claim covers the part that actually matters. The label is never technically false. It's just answering a narrower question than the one the customer thinks was asked.


What to actually do about it

Verify the toggle, not the marketing. Check Settings > Privacy & security > Recall & snapshots on any Copilot+ device in your environment directly; don't assume off means off after an update.

Lock it by policy where you can. On Pro, Enterprise or Education, set AllowRecallEnablement to 0 in Intune or Group Policy rather than relying on individual opt-in; on Home, there is no equivalent lock, only a registry edit.

Don't mistake the filter for a guarantee. Sensitive-information filtering catches the obvious cases, not all of them; treat any Recall history as a further copy of sensitive material, not a substitute for good data hygiene.

Ask what's actually gating capture. Encryption at rest is not the only question that matters. Check whether legacy screen-capture APIs are constrained by EDR or application allow-listing in your environment, since Recall's protections don't extend there and never claimed to.


Caveats

Hagenah has disclosed Total Recall Reloaded's existence and its effect but is, as of this writing, keeping some implementation specifics under wraps pending further exchange with Microsoft; the description here draws on his and Kevin Beaumont's public accounts rather than the withheld detail. Beaumont's assessment of the setup dialogue's button design was conducted on a Release Preview build in April 2025; no equivalent independent audit of the exact wording and layout on the current general-availability build has been located. Microsoft's classification of the AIXHost.exe access path as working as designed is the company's own characterisation, not an independent finding; the underlying facts of what the tool can access are not in dispute between the parties, only whether that access should count as a flaw.


Sources


Questions about this analysis, or interested in working with The Haunted Lighthouse?
consultancy@haunted.lighthouse.co.im

The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy—with particular focus on Isle of Man jurisdiction and Crown Dependency issues.

Support independent analysis. Subscribe directly—or scan on your phone.

Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.