Windows Recall is one of those features that generates strong opinions in IT circles. When Microsoft first previewed it in 2024, the backlash was swift enough to delay the whole rollout. Since then, Microsoft rebuilt the privacy and security architecture from scratch and has been gradually expanding availability to Copilot+ PCs. Now, with Recall shipping on most new business hardware and the Security Copilot E5 rollout accelerating Copilot+ adoption, desktop engineers need a clear picture of what Recall actually does, how the enterprise controls work, and what you should be configuring before your users start asking questions.
The short answer: Recall is off by default on managed devices. The longer answer is that “off by default” doesn’t mean your job is done.
What Recall Is and How It Actually Works
Recall takes screenshots of your screen at regular intervals and uses an on-device AI model to make them searchable. Users can describe something they saw — a document, a website, a conversation — and Recall surfaces it from the snapshot history. All of this processing happens locally using the NPU (Neural Processing Unit) on Copilot+ PCs.
The security architecture, post-rebuild, is meaningfully different from the original implementation. Snapshots are encrypted at rest using keys stored in the Trusted Platform Module (TPM), tied to the user’s Windows Hello Enhanced Sign-in Security (ESS) identity inside a Virtualization-based Security (VBS) Enclave. An admin with local admin rights cannot read another user’s Recall snapshots. Microsoft’s own support engineers cannot access them remotely. The decryption is just-in-time and scoped to the authenticated user’s session.
BitLocker and Device Encryption are required prerequisites and are enabled by default on Windows 11 Copilot+ PCs. Windows Hello ESS is also required, which means older biometric hardware that doesn’t meet the ESS standard won’t support Recall even on qualifying CPUs.
Hardware gating is strict. Recall requires a Copilot+ PC with an NPU capable of at least 40 TOPS (trillion operations per second). That limits it to devices with Snapdragon X, Intel Core Ultra 200V series, or AMD Ryzen AI 300 series processors and newer models. If you’re managing a mixed fleet of new and existing hardware, only a subset of devices will ever be capable of running Recall regardless of policy.
The Default State on Managed Devices
Here’s the practical starting point: on managed commercial and education devices, Recall is disabled by default. Users cannot enable it on their own through Settings. An IT admin must first configure the AllowRecallEnablement policy to permit it. Even then, users must individually opt in. Microsoft built in an explicit consent gate that admins cannot bypass.
This is a meaningful architectural constraint. Admins can gate access to Recall, restrict its behavior, and pull it back at any time. What they cannot do is force Recall on for a user without that user’s consent. If you delete snapshots by flipping a policy to disabled, they’re gone — there’s no recycle bin.
For most enterprise IT teams managing regulated industries (healthcare, finance, legal), this default-off posture is exactly what you want to maintain. The question is whether you’ve made that default explicit in policy, or whether you’re relying on behavior that could change.
Configuring Recall Through Intune
All Recall controls flow through the WindowsAI Policy CSP, under ./Device/Vendor/MSFT/Policy/Config/WindowsAI/ and in some cases at the user scope under ./User/Vendor/MSFT/Policy/Config/WindowsAI/. You can apply these through a custom OMA-URI profile in Intune or, where available, through the Settings Catalog.
AllowRecallEnablement: This is the master gate. Set it to Disabled and Recall is fully blocked: the feature bits are removed from the device and any existing snapshots are deleted. Set it to Enabled to allow users to opt in if they choose. This is a device-level policy only.
DisableAIDataAnalysis: This controls whether snapshot saving can happen at all. Setting it to Enabled turns off snapshot saving; any existing snapshots are deleted. This policy applies at both the device scope and the user scope, so you can target it to specific users via Entra ID group assignment rather than to all devices in a group.
SetMaximumStorageSpaceForRecallSnapshots: Available values are 10, 25, 50, 75, 100, or 150 GB. When the limit is hit, the oldest snapshots are purged automatically. If you don’t configure this, Windows sets it based on the device’s total storage: 25 GB for 256 GB devices, 75 GB for 512 GB, and 150 GB for 1 TB and above. This setting only applies on Enterprise and Education editions.
SetMaximumDurationForStoringRecallSnapshots: Valid values are 30, 60, 90, or 180 days. After that window, snapshots are automatically deleted. If you leave this unconfigured, snapshots are retained until the storage cap is hit. For compliance purposes, most organizations benefit from setting an explicit retention window rather than leaving it to storage pressure.
App and URI exclusions: You can maintain a semicolon-separated list of apps (by AUMID or executable name) that Recall will never snapshot. Similarly, you can exclude specific web URIs from being captured when users are using a supported browser. These settings let you carve out HR portals, financial applications, or internal tools from Recall’s reach without blocking the feature entirely.
In Intune’s UI, navigate to Devices > Configuration > Create > Settings Catalog, search for “Windows AI,” and you’ll find most of these controls grouped together. The OMA-URI approach gives you access to everything.
Integrating Purview DLP
The sensitive information filtering built into Recall is on by default. It uses the Microsoft Classification Engine and the NPU to detect credentials, credit card numbers, and national identification numbers before they’re written to the snapshot store. If it detects sensitive content in a moment’s capture, that frame is skipped.
You can extend this with Purview DLP policies. The SetDataLossPreventionProvider policy tells Recall to use a configured DLP provider to evaluate what should and shouldn’t be snapshotted against your organization’s custom sensitive information types. To configure this:
- In the Microsoft Purview compliance portal, create or edit a DLP policy.
- Under the policy scope, enable Recall as an enforcement location.
- Set the policy to Audit only first to see what would be blocked before enforcing.
- Switch to Block once you’ve validated the policy isn’t over-triggering.
This lets organizations that have already built out Purview SIT definitions for industry-specific data (HIPAA PHI patterns, PCI cardholder data, attorney-client privileged communications) apply that same logic to Recall’s capture behavior.
One important gotcha: sensitive information filtering works on what the OCR and AI model can detect in a frame. It doesn’t understand context across frames. A document that mixes sensitive and non-sensitive content on the same page may be captured partially. Relying on filtering alone as your compliance control is not enough for high-sensitivity environments.
Compliance Policy Enforcement
If you want to enforce Recall policy state as part of device compliance, Intune lets you create a compliance policy that marks devices non-compliant if Recall snapshot saving is active and you’ve determined that shouldn’t be allowed. From the Intune admin center:
- Go to Devices > Compliance policies > Create policy > Windows 10 and later.
- Under System Security, look for the Recall-related compliance settings.
- Tie the compliance policy to a Conditional Access policy that blocks access to corporate resources on non-compliant devices.
This gives you enforcement teeth beyond just configuration. If someone on a personal device enrolled in BYOD somehow has Recall active against your policy, they’ll lose access to Exchange and SharePoint until the device comes into compliance.
What to Actually Deploy: A Practical Decision Tree
If you’re managing a regulated environment (healthcare, finance, government): deploy AllowRecallEnablement = Disabled across all managed device groups. This removes the feature entirely and deletes any snapshots. Add an app exclusion list as a belt-and-suspenders measure if this policy ever changes.
If you’re in a general enterprise environment that’s Copilot+ PC capable: keep AllowRecallEnablement = Enabled but set SetMaximumDurationForStoringRecallSnapshots to 30 or 60 days. Configure your Purview DLP provider and establish an app exclusion list for your most sensitive internal tools. Monitor via Intune reporting before making any enforcement decisions.
If you have a mixed fleet with some Copilot+ and some non-capable hardware: the policies are safe to apply fleet-wide. Non-Copilot+ PCs won’t have Recall regardless of policy. The settings will simply be ignored on hardware that doesn’t meet requirements.
Limitations Worth Knowing
Sensitive information filtering is a best-effort control. It won’t catch everything, particularly in images, handwritten text, or application UIs that aren’t standard web or Office content. Don’t communicate to your legal or compliance teams that Recall is “DLP-protected” without that nuance.
The admin exclusion lists are app-level and URI-level only. There’s no domain-level or content-type-level exclusion. If your HR system runs inside a browser with no predictable URI pattern, a URI exclusion isn’t going to work reliably.
Recall snapshots are per-user. If you have shared or kiosk devices, Recall is likely not relevant (and should be disabled), but confirm this with your device setup rather than assuming kiosk mode blocks it.
The feature is only meaningful on Copilot+ hardware. Managing Recall policy on non-NPU devices costs you nothing in overhead, but you should still configure it explicitly so that your posture holds when those devices are eventually refreshed.
Conclusion
Windows Recall isn’t the uncontrolled surveillance tool the early previews suggested. The rebuilt security architecture, the default-off state for managed devices, and the granular CSP controls give desktop engineers real options. But “off by default” is not the same as “configured correctly.” Default behavior can change across Windows releases, and organizations that haven’t explicitly set their Recall policies in Intune are one policy change or device enrollment away from an ambiguous state.
Set your policies intentionally. Configure DLP if you’re using Purview. Establish a retention window. Get your app exclusion list in place before Copilot+ PCs start populating your fleet at scale.
The hardware refresh cycle will make this a live question for most IT teams in 2026. Better to have the answers ready before users start asking why their new laptop can’t do what the box promised.