Microsoft Recall: One Year Later

Microsoft Recall is the most misunderstood security story of the decade, and both the panic and the defense were wrong

By Geist | August 24, 2026

There are two Microsoft Recall stories in circulation. The first one covers the story the press told in May and June of 2024, which holds that Microsoft built a feature that screenshots everything you do on your Windows PC and stored the screenshots in a plaintext database that any malware could read. The second one covers the story Microsoft told when it relaunched Recall in April 2025, which holds that the new architecture, with VBS enclaves, AES-256-GCM encryption, Windows Hello biometric authentication, and an opt-in default, addresses the original concerns. Both stories are right about the parts they cover and wrong about the parts they leave out. The actual security story of Recall is one that neither the panic nor the defense has surfaced in a form a security team can act on. The post is the version a working security team would write.

What this post is built around is the research that has come out since the April 2025 relaunch, especially the work of Alexander Hagenah, the Zürich-based researcher whose original TotalRecall tool forced the 2024 redesign and whose March 2026 successor tool, TotalRecall Reloaded, demonstrated that the new architecture has the same fundamental exposure as the old one. The post walks through what Hagenah actually showed, what Microsoft’s response was, what the response misses, and what the practical response looks like for an enterprise IT team rolling out Copilot+ PCs in 2026. The post is written by a working threat analyst and is calibrated to the threat model a real enterprise security team is operating under, not the threat model Microsoft is responding to.

Technical facts at a glance

Item	Value
Original launch date	20 May 2024 (announcement), 18 June 2024 (preview to Insiders)
Original launch status	Opt-out by default, plaintext SQLite database, no authentication required
Original recall database location	%USERPROFILE%\AppData\Local\CoreAIPlatform.00\UKP\ukg.db and screenshot folder under same path
Researcher who found the original flaw	Kevin Beaumont, then at Microsoft, published findings 31 May 2024 via DoublePulsar
Researcher who built the original extraction tool	Alexander Hagenah, TotalRecall, published June 2024 on GitHub
Microsoft pause	13 June 2024, recall delayed, Windows Insiders preview pulled
Redesign launch	April 2025 for Copilot+ PC hardware requirement, opt-in default, VBS enclave, Windows Hello required
Hardware requirement	NPU capable of 40 TOPS or more (Qualcomm Snapdragon X Elite/X Plus, Intel Core Ultra, AMD Ryzen AI)
Storage protection	VBS Enclave (Virtualization-Based Security), AES-256-GCM encryption at rest, keys in Protected Process Light host
Authentication gate	Windows Hello Enhanced Sign-in Security, biometric face/fingerprint or PIN, with timeout and anti-hammering
Snapshot capture interval	Significant visual change, typically every few seconds during active use
Snapshot storage capacity	Up to 25 GB default, configurable by user
Recall deployment in enterprise	Disabled by default in Microsoft managed builds, opt-in by user if admin enables
TotalRecall Reloaded publication	March 2026, Hagenah published to GitHub and disclosed to MSRC on 6 March 2026
MSRC closure	3 April 2026, classified as working as designed, no CVE issued
Microsoft statement (3 April 2026)	“the access patterns demonstrated are consistent with intended protections and existing controls, and do not represent a bypass of a security boundary or unauthorized access to data. The authorization period has a timeout and anti-hammering protection that limit the impact of malicious queries.”
Compromised process	AIXHost.exe, the rendering process that receives decrypted data outside the VBS Enclave
Researcher who confirmed the second finding	Kevin Beaumont, Mastodon 11 March 2026: “Yep, you can just read the database as a user process. The database also contains all manner of fields that aren’t publicly disclosed for tracking the user’s activity. No AV or EDR alerts triggered.”
Capture avoidance	App exclusion list, sensitive content filter, Purview sensitivity label integration for the November 2025 build
Recall-capable PC share (GeekWire 2026)	Fewer than 10% of Windows 11 PCs at the time of the article
Intune policy controls	AllowRecallEnablement (0 disables, 1 allows user opt-in) and DisableAIDataAnalysis
Purview DLP integration	Sensitivity label based exclusion, added November 2025

What the original Recall actually was, and why the 2024 panic was justified

The original Microsoft Recall was announced on 20 May 2024 as part of the Copilot+ PC marketing push, the first wave of Windows 11 PCs that had the new Snapdragon X Elite and Intel Core Ultra NPUs capable of running the on-device AI workloads Microsoft wanted Recall to use. The pitch was a “photographic memory” of everything the user did on the PC, captured in a continuous stream of screenshots, OCR’d on the fly, indexed in a semantic search database, and queryable by natural language. Microsoft positioned this as a productivity feature. Security researchers took one look at the architecture and called it a privacy and security disaster.

What the researchers found, within days of the preview becoming available to Windows Insiders, was that the screenshots were stored in a SQLite database at a predictable file path under the user profile, with no encryption, no access controls, and no authentication. Any local user account, or any malware with basic filesystem access running in the user’s context, could read the entire history of the user’s activity. Kevin Beaumont, who at the time was a senior threat intelligence analyst at Microsoft and had worked in security for two decades, put it bluntly in a 31 May 2024 blog post: “stealing everything you have ever typed or viewed on your own Windows PC was now possible with two lines of code.” Beaumont measured the entire Recall database as compressible to about 90 kilobytes, which is what an infostealer needs to extract it.

The second thing the researchers found, in a controlled test, was that the infostealer extraction was fast enough to beat most enterprise endpoint detection and response systems. Beaumont’s test showed Microsoft’s own Defender for Endpoint catching the simulated infostealer activity about ten minutes after the initial file read. The Recall database, at 90 kilobytes compressed, could be found, copied, and exfiltrated in under two seconds. The detection response time was an order of magnitude slower than the attack time, and the post is being written on a clean machine rather than a fully compromised one. The threat model that the original Recall assumed was that a user with local admin access was the adversary, and the design treated any other code running in the user’s context as not the adversary at all.

The 2024 panic was justified because the original design treated the local user context as a safe place to put a complete record of the user’s activity, and that assumption has not been true since the first PC virus. Any feature that assumes the local user context is safe to store sensitive data in is, by definition, a feature that any malware running in that context can read. The original Recall was, in the literal sense of the phrase, a feature that stored the user’s entire digital life in a place where the most common type of attack on a Windows PC, the user-context infostealer, could trivially extract it. The press got the practical security story right, even when the technical details in some of the coverage were imprecise.

What the press got wrong, in many cases, was the suggestion that Microsoft had built the original Recall with no security review at all. The original design did have Microsoft Defender for Endpoint integration, did have the database stored under the user profile rather than system-wide, and did have the opt-out default that the original announcement specified. The problem was not that Microsoft had no security awareness, it was that the threat model Microsoft applied was the wrong threat model. Microsoft was protecting against a remote attacker who had not yet compromised the user, and the actual threat was the local attacker who already had user-level code execution. The two threat models are not the same and the design that handles the first one does not handle the second one.

What the April 2025 redesign actually changed

Microsoft pulled the original Recall preview on 13 June 2024, four weeks after the announcement. The company said it would rework the feature and that the redesigned Recall would require Windows Hello authentication, would store the data in an encrypted form using a virtualization-based security enclave, and would be opt-in by default. The redesign shipped in April 2025 as a Copilot+ PC exclusive feature, which gave Microsoft a useful way to gate the rollout: only the new hardware class could run Recall at all, and the new hardware had the necessary security primitives built in.

The April 2025 redesign has four substantive changes worth understanding. The first change is the storage architecture. The Recall data now lives in a VBS Enclave, which is a virtual machine that runs at a higher trust level than the normal user session. The encryption keys are held in a Protected Process Light host, which is a Windows mechanism for protecting processes from being tampered with by other user-context code. The actual data is encrypted with AES-256-GCM at rest. This is a meaningful change because the file path that was the original attack surface, the predictable SQLite database location, is now an encrypted file that requires a key to decrypt, and the key is held outside the user context.

The second change is the authentication gate. Accessing the Recall timeline, changing Recall settings, or exporting Recall data now requires Windows Hello authentication, which is biometric face or fingerprint, or a PIN configured with Enhanced Sign-in Security. The authentication has a timeout and anti-hammering protection, meaning the authentication session is short-lived and the system rate-limits authentication attempts. This is a meaningful change because the user can no longer access their own Recall data without proving it is them, and the proof has a much higher bar than just having access to the user account.

The third change is the capture process. Recall now runs as a protected process that captures screenshots into the enclave, where the data is encrypted before any user-context code can see it. The capture is still every few seconds during active use, but the captured screenshots are encrypted immediately and the plaintext version exists only in the rendering pipeline that shows the user their own timeline.

The fourth change is the opt-in default. The original Recall was opt-out, which meant the user had the feature enabled until they turned it off. The April 2025 redesign is opt-in, which means the user has the feature disabled until they turn it on. Microsoft also added a managed build that defaults to off in enterprise tenants, with the user able to opt in if the IT team allows. This is a meaningful change because the default matters in security, and the opt-in default is a real improvement over opt-out.

These four changes are a real security improvement. The original 2024 attack, in which any user-context code could read the SQLite database directly, does not work against the April 2025 build. The encryption is real, the authentication is real, the protected process is real, and the opt-in default is real. The post is willing to be specific about this because the security community spent most of 2024 and early 2025 calling the redesign vaporware, and the post-check that the redesign actually works on the original attack is a meaningful piece of the story. Microsoft is correct that the original attack does not work. Where Microsoft is wrong, and where the 2026 research has been clear about this, is the threat model that the redesign assumes.

What TotalRecall Reloaded actually showed, and why the MSRC response was wrong on the substance

Alexander Hagenah is the researcher whose original TotalRecall tool, published on GitHub in June 2024, demonstrated the original SQLite attack and forced the Microsoft redesign. In March 2026, Hagenah published TotalRecall Reloaded, a successor tool that demonstrates the same fundamental attack against the April 2025 redesign. The tool runs as a standard user, with no admin rights, no kernel exploit, and without breaking any encryption. It works by injecting into AIXHost.exe, which is the Windows process that renders the Recall timeline when the user opens it. The injection happens after the user authenticates with Windows Hello, and the tool extracts the screenshots, thumbnails, OCR text, and metadata that Recall has captured over the history period.

The technical detail that matters is that AIXHost.exe receives the decrypted data outside the VBS Enclave boundary. The enclave protects the data at rest. The authentication protects access to the timeline. The rendering process that shows the user the timeline runs in the normal user context, which means any code running in the user context can read from that rendering process once the user has authenticated. The attack is a same-user attack. It does not bypass the encryption. It does not bypass the authentication. It uses the user’s own authentication session, in the user’s own context, against a process that has the user’s decrypted data because the user is looking at it.

Hagenah disclosed the research to Microsoft Security Response Center on 6 March 2026, with full source code and reproduction steps. Microsoft reviewed the case for a month. On 3 April 2026, Microsoft closed the case, telling Hagenah that the behavior “does not represent a bypass of a security boundary or unauthorized access to data.” A Microsoft spokesperson told CSO Online in March 2026 that the access patterns “are consistent with intended protections and existing controls” and that the authorization period has a timeout and anti-hammering protection that limit the impact of malicious queries. David Weston, Microsoft’s corporate vice president of security, told The Verge that the access patterns are consistent with intended protections and do not represent a bypass.

Microsoft is technically correct that the attack does not bypass the encryption, the authentication, or any of the VBS Enclave protections. Microsoft is also technically correct that the timeout and anti-hammering limit the window. Where Microsoft is wrong is on the threat model. The Microsoft threat model for the timeout is the threat model for an interactive user opening the timeline, opening a screenshot, and closing the timeline. The Microsoft threat model does not include a malware process that opens the timeline once, holds the authentication session open in the background, and reads everything Recall has captured over a six month period. The timeout limits the impact of an interactive adversary. The timeout does not limit the impact of a passive malware adversary that has time to wait.

Kevin Beaumont confirmed the same finding on 11 March 2026 in a Mastodon post, writing “Yep, you can just read the database as a user process. The database also contains all manner of fields that aren’t publicly disclosed for tracking the user’s activity. No AV or EDR alerts triggered.” Beaumont’s contribution to the 2026 story is that the same attack works against the AIXHost.exe process, the same field set is exposed, and the standard EDR tools that an enterprise IT team is paying for do not flag the activity. The fact that the field set includes tracking fields that Microsoft has not publicly documented is a separate concern, because the privacy surface of Recall is larger than the feature description suggests.

The Microsoft position that the access pattern is “working as designed” reads as the kind of answer that is technically true and substantively wrong. No boundary was bypassed, and the technically true part stops there. The substantively wrong part runs deeper, because the design assumed a threat model that the actual threat does not fit. Microsoft built around an interactive user who wants to look at their own screenshots. The actual threat runs in the user context after the user has authenticated, which any other feature that stores data on the local disk has to defend against. The post is willing to be specific about this because the security community spent a year debating whether the redesign was real, and the redesign working on the original attack is the part that Microsoft got right. The redesign not working on the same-user attack is the part Microsoft has been trying to avoid, and the post is going to surface that part.

The actual privacy concern that nobody is talking about

The original panic in 2024 was about screenshots being stored in plaintext. The Microsoft defense in 2025 was about screenshots being encrypted. The Hagenah finding in 2026 is about screenshots being decrypted for display. All three of these are the same technical story at three different moments. The post is going to argue that the actual privacy concern is none of these and is instead the inference graph that the indexed OCR text creates.

Recall does not store screenshots as a simple image archive. Recall runs OCR on every screenshot at capture time, stores the OCR text, builds a semantic embedding of the text, and indexes both in a searchable database. The semantic embedding is what makes Recall useful as a feature, because the user can search for “the email I got last Tuesday from my lawyer about the divorce” and get the right screenshot. The embedding is the privacy surface that nobody is talking about, because the embedding is a model of what the user has been doing that is more searchable than the screenshots themselves.

Consider what a malware process that has read the Recall index can do. The malware process does not need the screenshots. The malware process can search the index for the user’s bank login, find the screenshot, extract the password from the OCR text, and use the password without ever looking at the screenshot. The malware process can search the index for the user’s medical appointments, find the screenshots, read the doctor’s name and the appointment time, and use that information without ever looking at the screenshot. The malware process can search the index for the user’s travel plans, find the screenshots, read the dates and locations, and use that information without ever looking at the screenshot. The screenshots are a record. The index is a queryable model of the user’s life.

This is the privacy concern that the 2024 panic missed and the 2025 defense did not address and the 2026 research is starting to surface. The screenshots are a privacy concern, but the index is a larger privacy concern because the index is more useful to an attacker than the screenshots. Microsoft has not addressed the privacy surface of the index separately from the privacy surface of the screenshots. The Hagenah finding is about the screenshots. The index is the larger problem, and the post is willing to be the first security blog post to surface this as the actual concern.

What the smart deployment looks like in 2026

The smart deployment for Microsoft Recall in 2026 is not the all-or-nothing deployment that most enterprise IT teams have been defaulting to. The smart deployment is a tiered deployment that matches the Recall exposure to the user’s role and the data they handle. Microsoft has built the controls for this deployment, and the post is going to walk through them.

For the highest-sensitivity roles, the deployment is to disable Recall entirely. This means setting the Intune policy `AllowRecallEnablement` to 0, which removes the feature binaries from the device, deletes any previously captured snapshots, and requires a device restart. This is the right answer for executives with access to merger and acquisition data, for legal teams with access to privileged communications, for finance teams with access to material non-public information, for security teams with access to incident response data, and for any user whose compromise would have outsized business impact. The deployment cost is zero because the feature is not enabled to begin with, and the security benefit is the elimination of the entire Recall attack surface for these users.

For the general fleet, the deployment is to keep Recall disabled by default and to allow individual users to opt in for productivity reasons, with the user understanding that the feature creates a comprehensive record of their activity that is accessible to any malware that compromises their account. The deployment uses `AllowRecallEnablement` set to 1 to allow opt-in, combined with `DisableAIDataAnalysis` set to 1 to disable the on-device AI analysis that builds the semantic index. The opt-in is the user’s choice. The opt-in is informed. The AI analysis is off by default and requires a separate opt-in. This is the right answer for users whose compromise would have normal business impact.

For the user-facing controls, the deployment enables the Windows Hello Enhanced Sign-in Security with biometric authentication required, not PIN. The deployment uses Microsoft Purview sensitivity labels to mark documents that should be excluded from Recall capture, and the deployment uses the application exclusion list to block Recall capture from the most sensitive applications. The deployment enables Purview Audit Premium logging for E5-licensed tenants, which gives the security team a record of when Recall databases were accessed and by which user. The deployment verifies the EDR tool’s detection coverage for the AIXHost.exe process injection pattern and the CoreAIPlatform AppData path, because the standard EDR rules do not cover these paths by default and the security team has to add coverage.

For the end-of-life process, the deployment treats Recall snapshots as a distinct data destruction artifact. The NIST SP 800-88 Rev 2 cryptographic erase or purge that has been the standard for the last twenty years is no longer sufficient on its own, because the Recall data is on a Copilot+ PC that has been powered on in a staging room, a transport locker, or a third party logistics handoff. The Recall snapshots need to be purged while the device is still running and authenticated, with the purge logged and timestamped, before the device leaves the enterprise’s controlled environment. The certificate of sanitization needs to attest to the specific Recall snapshot destruction, not just the general media sanitization. This is the right answer for the disposal and decommissioning path that the ITAD vendor is using.

What the post recommends and why

The post’s recommendation for an enterprise IT team rolling out Copilot+ PCs in 2026 is to deploy the tiered Recall exposure model described in the previous section, with the highest-sensitivity roles on `AllowRecallEnablement` = 0, the general fleet on `AllowRecallEnablement` = 1 with `DisableAIDataAnalysis` = 1, and the user-facing controls including Windows Hello biometric, Purview sensitivity labels, and EDR coverage for the AIXHost.exe process. The post is willing to make this recommendation because the threat model Microsoft is responding to, same-user malware with the user’s own authentication, is a real threat that the current architecture does not defend against, and the only defense is to reduce the Recall attack surface for the users who matter.

The post’s recommendation for the threat model that the security team should be operating under runs as the same-user threat model, not the remote attacker threat model that Microsoft’s design implicitly assumes. Under the same-user threat model, any code running in the user’s context after the user has authenticated with Windows Hello gets treated as an adversary with the same level of trust as the user. Apply the same-user threat model to any feature that stores data in the user context, which includes Recall, browser saved passwords, the Windows credential vault, and any third party password manager. The same-user threat model is the threat model that the actual infostealer landscape has been operating under for years, and the security team that has been operating under the remote attacker threat model has been missing the actual threat.

The post’s recommendation for the response to the Hagenah finding specifically is to treat the AIXHost.exe process as an untrusted process that has access to decrypted data, and to deploy EDR rules that detect and alert on any other process reading from AIXHost.exe during the user’s authenticated Recall session. The post is willing to make this recommendation because the Microsoft position that the attack is working as designed is correct in the narrow sense that no boundary was bypassed, but the post-check that the security team can build a useful response without Microsoft’s cooperation is the more important point. The EDR coverage is in the security team’s hands, not Microsoft’s.

The post’s recommendation for the privacy discussion that the post expects to happen over the next year is to surface the index surface as a separate concern from the screenshot surface. The screenshots are a privacy concern, but the index is a larger privacy concern because the index is a queryable model of what the user has been doing. The Microsoft position that the screenshots are protected by encryption and authentication is correct on the technical point and misses the practical point, which is that the index is the actual attack surface for the same-user adversary. The post is willing to surface this as the actual privacy concern because the security community has been debating the screenshot surface for two years without noticing that the index surface is more useful to the attacker.

What the post is not going to argue

The post is not going to argue that Microsoft Recall should not exist. The post is going to argue that the design has a specific, well-defined threat model, the threat model is the wrong one for the actual threat landscape, and the security team should deploy the feature in a way that accounts for the actual threat. The Recall feature is a useful productivity tool for the right user with the right deployment. The Recall feature is a privacy and security disaster for the wrong user with the wrong deployment. The post is going to spend the rest of the recommendation on getting the deployment right, not on getting the feature removed.

The post is also not going to argue that the Microsoft threat model runs wrong because Microsoft is malicious or because Microsoft is hiding something. The post argues that the Microsoft threat model runs wrong because the threat model was set in 2024 before the same-user malware threat was as well documented as it stands now, and the threat model has not been updated to account for the 2026 research. Hagenah’s finding reads as a real, documented, disclosed-to-Microsoft vulnerability that Microsoft has chosen not to patch. Microsoft picked the choice of a vendor that has decided the design boundary is correct, not the choice of a vendor that has decided to ignore the vulnerability. Calling the choice wrong reads as a security policy position, not a security incident.

MITRE ATT&CK mapping for the Recall attack chain

The same-user malware attack on Microsoft Recall maps to a specific set of MITRE ATT&CK techniques. The mapping is useful for the security team that is building EDR coverage for the AIXHost.exe process and the CoreAIPlatform AppData path, because the mapping tells the security team which techniques to look for in the telemetry. The post is going to walk through the most important techniques in the chain, with the corresponding Windows-specific implementation, the relevant data sources, and the EDR detection that the security team should deploy.

• Execution (TA0002), T1059 Command and Scripting Interpreter, T1059.001 PowerShell: The first step in the Recall attack chain is often PowerShell, which is the most common way to invoke the Recall APIs and to inject into the AIXHost.exe process. PowerShell is the default scripting language on Windows, has access to the .NET classes that wrap the Recall APIs, and has the privilege level to call into the AIXHost.exe process. The EDR detection is on the parent-child process relationship between PowerShell and the AIXHost.exe process, which is an unusual relationship and is the kind of thing the EDR rules can flag with high confidence.
• Defense Evasion (TA0005), T1562 Impair Defenses, T1562.001 Disable or Modify Tools: The same-user malware attack on Recall often includes steps to disable the EDR rules that would detect the AIXHost.exe injection, either by killing the EDR process, by tampering with the EDR configuration, or by adding the AIXHost.exe path to the EDR exclusion list. The EDR detection is on any change to the EDR configuration from a non-administrative process, which is a high confidence indicator of compromise.
• Credential Access (TA0006), T1555 Credentials from Password Stores, T1555.004 Windows Credential Manager: The Recall attack is often combined with credential theft from the Windows Credential Manager, which is the Windows mechanism for storing saved credentials. The same-user malware that can read the Recall index can also read the Credential Manager, and the EDR detection is on any process other than the credential manager that is reading from the credential store. The Recall attack makes the credential manager attack more valuable because the malware can search the Recall index for the credentials the user is typing in real time.
• Collection (TA0009), T1005 Data from Local System: The Recall attack is fundamentally a local data collection attack. The malware reads the Recall index and the screenshot files from the user profile, and the EDR detection is on any large read of the CoreAIPlatform.00 folder, which is the folder that holds the Recall database. The EDR rule should flag any process other than the Recall system processes that is reading the folder, and the rule should flag any process that is reading more than 100 MB of data from the folder in a 60 second window, which is a strong indicator of data exfiltration preparation.
• Command and Control (TA0011), T1071 Application Layer Protocol, T1071.001 Web Protocols: The Recall attack often exfiltrates the data over HTTPS, which is the standard command and control channel for modern malware. The EDR detection is on any outbound network connection from a process that has been reading the CoreAIPlatform.00 folder, which is a strong indicator of exfiltration. The network detection is on the data volume, which is small (90 KB compressed) but unusual in the context of the local process.
• Exfiltration (TA0010), T1567 Exfiltration Over Web Service, T1041 Exfiltration Over C2 Channel: The Recall attack exfiltrates the data over the same channel as the command and control, which is either a cloud storage service or a direct HTTP connection to the attacker’s infrastructure. The EDR detection is on the same data volume indicator as the command and control detection. The network detection is on the destination, which is a domain that has not been seen before on the network, or a domain that has been flagged as malicious by the threat intelligence feed.

The MITRE mapping is useful for the security team that is building the EDR coverage because the mapping tells the security team which techniques to look for in the telemetry and which EDR rules to deploy. The mapping is also useful for the security team that is communicating the threat to the executive team, because the MITRE framework is the standard language that the executive team is going to be familiar with. The mapping is not useful for the security team that is trying to convince Microsoft to change the design, because Microsoft has already made the design decision and the post is not going to spend time on the political argument.

The bottom line

Microsoft Recall in 2026 is a feature that works as designed. The design is the wrong design for the actual threat landscape. The original 2024 panic landed on the practical point and missed the technical detail, and the 2025 defense landed on the technical detail and missed the practical point. The 2026 research has surfaced a third point, which runs as the same-user malware threat model being the actual threat and the design not defending against it. Microsoft has the position that the design works as designed right. The part that is wrong runs as the Microsoft position that the design is the right design for the threat.

The post recommends that the security team deploy the feature with the tiered exposure model, putting the highest-sensitivity roles on the disabled setting, the general fleet on the opt-in setting with the AI analysis disabled, and the user-facing controls including Windows Hello biometric, Purview sensitivity labels, and EDR coverage for the AIXHost.exe process. The post recommends the same-user threat model, which the security team should apply to any feature that stores data in the user context. The post recommends surfacing the index surface as a separate concern from the screenshot surface, because the index serves as the more useful attack surface for the same-user adversary.

The post is not going to argue that Microsoft Recall should be removed. The post is going to argue that the feature should be deployed with the controls that Microsoft has built for the actual threat, that the controls are deployed in the right tier for the right user, and that the security team is not waiting for Microsoft to change the design. The post is the version a working security team would write, and the recommendation is the one the security team is going to implement.

Geist verdict

The 2024 panic was right that Recall was a security disaster. The 2025 defense was right that the redesign fixed the original attack. The 2026 research is right that the design does not defend against the actual threat. The three positions are not contradictory, and the security team that has been waiting for a clear answer is the security team that has been asking the wrong question. The clear answer is that Recall is a feature with a real attack surface, the attack surface is the same-user malware threat, the attack surface is not going away, and the security team has the tools to manage the attack surface without Microsoft changing the design.

The Microsoft Recall story stands as the most useful security story of the decade for a specific reason. It ranks as the most useful because it has been the most public example of the gap between the security community’s threat model and the vendor’s threat model, and the gap serves as the gap that every feature shipping in 2026 has to navigate. The post reads as the working security team’s response to the gap, and the response is the one that the security team is going to deploy.

Defensive checklist

1. Set the Intune policy `AllowRecallEnablement` to 0 for all devices joined to the enterprise tenant. The default for managed devices is already 0, but the policy has to be set explicitly so that the deployment is auditable.
2. Segment the fleet by role sensitivity. Create a separate Intune device group for the highest-sensitivity roles, including executives, legal, finance, and security, and apply the most restrictive Recall policy to the group. The general fleet stays on the default policy.
3. For users that the business requires to have Recall, set `DisableAIDataAnalysis` to 1. The setting disables the on-device AI that builds the semantic index, which removes the index surface as a separate attack surface while leaving the screenshot surface for the user to use.
4. Deploy Windows Hello Enhanced Sign-in Security with biometric authentication required, not PIN. The biometric requirement is the strongest authentication option for Recall, and the E5 licensing makes the requirement enforceable through Intune Endpoint Security policies.
5. Configure the application exclusion list. Identify the enterprise applications that handle the most sensitive content, including the HR portal, the legal document management system, the finance ERP, and the source code repository, and add them to the Recall exclusion list through the Intune policy.
6. Configure the Purview sensitivity label integration. Mark documents that should be excluded from Recall capture, including HR records, legal documents, and financial records, and let the Purview policy propagate the exclusion automatically.
7. Enable Purview Audit Premium logging for the Recall access events. The E5 licensing is required, and the logging gives the security team a record of when Recall databases were accessed and by which user.
8. Add EDR coverage for the AIXHost.exe process. The standard EDR rules do not cover the process injection pattern, and the security team has to add the rule. The rule should flag any process other than the Recall system processes that is reading from the AIXHost.exe process, and the rule should flag any process that is opening a handle to the AIXHost.exe process with process injection flags.
9. Add EDR coverage for the CoreAIPlatform.00 folder. The folder is the storage location for the Recall database, and the security team has to add a rule that flags any process other than the Recall system processes that is reading from the folder. The rule should also flag any process that is reading more than 100 MB of data from the folder in a 60 second window, which is a strong indicator of data exfiltration preparation.
10. Update the certificate of sanitization process. The certificate has to attest to the specific Recall snapshot destruction, not just the general media sanitization. The Recall snapshots need to be purged while the device is still running and authenticated, with the purge logged and timestamped, before the device leaves the enterprise’s controlled environment.
11. Establish a review cadence. Microsoft updates Copilot+ PC features with each Windows 11 cumulative update. Assign ownership of the Windows AI policy CSP to a specific team member who reviews the Microsoft Learn Manage Recall page after each Patch Tuesday.
12. Document the threat model the security team is operating under. The same-user malware threat model is the threat model the security team should be applying to any feature that stores data in the user context, which includes Recall, the browser saved passwords, the Windows credential vault, and any third party password manager. The document is the artifact the security team uses to justify the deployment decisions to the executive team.

Sources

• Microsoft, “Recall and snapshots frequently asked questions,” Microsoft Support, updated periodically through 2026. support.microsoft.com
• Microsoft, “Manage Recall,” Microsoft Learn, updated through 2026. learn.microsoft.com
• Microsoft Digital, “Accelerating workplace productivity at Microsoft with Windows Recall,” Microsoft Inside Track Blog, 2026. microsoft.com
• Kevin Beaumont, “Recall security,” DoublePulsar, 31 May 2024 (original disclosure) and follow-up posts through March 2026. doublepulsar.com
• Kevin Beaumont, Mastodon post on the AIXHost.exe extraction, 11 March 2026. infosec.exchange/@GossiTheDog
• Alexander Hagenah, TotalRecall Reloaded, GitHub repository, March 2026. github.com/xaitax
• Alexander Hagenah, “TotalRecall Reloaded – One Year Anniversary of TotalRecall,” LinkedIn, April 2026. linkedin.com
• CSO Online, “Microsoft’s Windows Recall still allows silent data extraction,” March 2026. csoonline.com
• The Verge, “Microsoft’s response to TotalRecall Reloaded research,” April 2026. theverge.com
• GeekWire, “One year after its rocky launch, Microsoft’s Windows Recall still raises security red flags,” April 2026. geekwire.com
• Beyond Scale, “Windows Recall Enterprise Security: CISO Guide 2026,” 2026. beyondscale.tech
• TechTarget, “Are Copilot+ PCs worth it? Evaluating AI-powered Windows PCs,” 2026. techtarget.com
• Resource Recycling, “Windows AI Recall is pushing data destruction upstream,” 30 April 2026. resource-recycling.com
• Top AI Threats, “INC-24-0019: Microsoft Windows Recall Privacy,” incident record, last updated 13 March 2026. topaithreats.com
• University of Pennsylvania Office of Information Security, “Microsoft Recall feature warning,” 14 April 2025. almanac.upenn.edu
• MITRE ATT&CK Enterprise Matrix, current as of August 2026. attack.mitre.org