Microsoft announced Windows Recall yesterday at the Copilot+ PC event, and by this morning it was the only thing our clients wanted to talk about. So this is a same-day note, written while the details are still thin and the marketing gloss is still wet, because the questions worth asking are clearest before a narrative sets in. Recall is the headline feature of the new Copilot+ PC class — machines built around a neural processing unit rated at 40-plus TOPS, launching first on Snapdragon X silicon — and it is the most consequential thing Microsoft has put on the endpoint in years, for reasons that have very little to do with how well it works.
Here is the mechanic as Microsoft describes it. Recall periodically takes snapshots of your screen — everything you see, on a rolling basis — processes them on the device using that NPU, and builds a searchable, browsable timeline of your activity. You can scroll back through what you were doing, or ask in natural language to find that thing you saw last Tuesday, and it surfaces the snapshot. The processing is local; Microsoft is emphatic that the snapshots stay on the device and are not sent to the cloud. For an individual chasing a document they cannot name, it is a genuinely useful idea. For anyone responsible for a fleet, it is a database of everything every user has ever looked at, sitting on the endpoint, and that framing should focus the mind.
What Recall actually is, stripped of the pitch
Strip away the demo and Recall is a local, continuously-updated, full-text-searchable index of screen contents. That is the thing to hold in your head, because every enterprise concern follows from it directly and none of them are exotic once you say it that plainly.
The on-device claim is real and it matters — this is not screenshots streaming to a Microsoft server, and the distinction defuses one category of fear. But "the data never leaves the device" is not the same as "the data is safe," and conflating the two is the mistake the early coverage is already making. On-device data lives on a device that gets lost, stolen, shared, re-imaged, seized, or handed to the next employee. On-device data is in scope for anyone who can reach that device, whether that is a thief, an abusive partner, a coworker at an unlocked machine, or a legal process. The security boundary did not disappear because the processing is local; it moved onto the endpoint, which is the least controlled tier in most estates, and the one your users physically carry into the world.
The disablement question comes first
The first question every one of our clients asked this morning, correctly, is: can we turn it off, at scale, by policy, before a single one of these machines touches our network? Any feature of this weight that cannot be centrally governed is a non-starter for a managed environment, full stop.
The honest answer, on day one, is that we do not yet have the enterprise management surface fully documented. Microsoft has signaled that Recall will be manageable and that users can control it — pause it, exclude applications, delete snapshots — and the reasonable expectation is that Intune and Group Policy controls will exist to disable it and to enforce that disablement so a user cannot re-enable it. But "reasonable expectation" is not "verified policy path with a documented CSP," and we are not going to tell a client their fleet is governed on the strength of a keynote. The specific things we are chasing down: is there a policy to disable Recall outright, is it enforceable so users cannot override it, can it be scoped to device groups, and does it survive an OS update. Until those answers are concrete and testable, the capability is ungoverned by default, and ungoverned is the operative word.
Data classification blows up on contact
Recall does not know what it is looking at. It snapshots the screen, and the screen shows whatever the user has open — and that is where any data classification program collides with reality. Your Purview labels, your DLP rules, your careful separation of what may be stored where: all of it assumes data lives in files and flows through channels you can inspect. A screenshot of a labeled document is not the labeled document. It is a picture, sitting in the Recall store, that no DLP policy inspected and no sensitivity label governs, and it contains exactly the content the label was meant to protect.
Think through what actually crosses a screen in a working day. Regulated data under HIPAA, GLBA, PCI. Material non-public information. Privileged legal communications. Another person's protected data visible in a support tool. Credentials in a config file. If Recall is capturing all of it into a local index, you have created a store of your most sensitive content that sits entirely outside every governance control you spent years building. For a regulated client, that is not a feature toggle, it is a compliance question that has to be answered before the hardware is approved, not after.
Secrets on the screen, and the timeline nobody scoped
Two specific hazards deserve their own paragraph because they are the ones that turn an abstract worry into an incident.
The first is captured secrets. Passwords in a text editor, API keys in a terminal, account numbers in a form, a one-time code on screen for the three seconds before you type it — anything visible is potentially in a snapshot. Microsoft has indicated Recall will try to avoid capturing certain sensitive content and will let users exclude apps, and we will test exactly how well that filtering works before trusting it, because "tries to avoid" is doing a great deal of load-bearing work in that sentence. A local store that has incidentally captured live credentials is a privilege-escalation and lateral-movement gift to anyone who compromises the endpoint, and endpoints get compromised.
The second is the one your legal team has not thought about yet, so raise it for them. Recall creates a rich, timestamped record of user activity, and records are discoverable. Is the Recall store in scope for legal hold? Can it be preserved, collected, and produced in eDiscovery? If a device is subject to hold, does snapshotting need to stop or the store need to be frozen? Right now these questions have no clean answers, and "we don't know" is itself a material risk when a record of this granularity exists on every machine. The reciprocal problem is just as real: retention. A store of everything a user ever saw, kept indefinitely, is a liability that grows every day it exists, and most retention schedules never contemplated it because nothing like it existed to contemplate.
BYOD makes all of this sharper. On a corporate device you at least aspire to control. On a personal Copilot+ PC that an employee uses for work, Recall is capturing corporate data into a store you have no authority over, on hardware you do not manage, governed by a consumer's choices. Any BYOD policy written before yesterday did not account for this, and it now needs to.
Our posture: block by default, prove the controls, then revisit
Given all of the above, on day two our recommendation to clients is unambiguous and deliberately conservative: block Recall by default across managed devices until the controls are documented, tested, and proven against your specific obligations. This is not reflexive fear of a new feature. It is the same posture we would take toward any capability that captures sensitive data outside existing governance and whose management surface is not yet verified. The burden of proof sits with the feature, not with the people responsible for the estate.
A regional bank we work with — a few thousand endpoints, heavily regulated, exactly the profile where this matters most — got a short memo from us this morning laying out precisely this stance. Copilot+ PCs are not in their near-term refresh plan regardless, but the memo puts a marker down: no Recall-capable device enters the managed fleet with the feature enabled until the disablement path is verified in Intune, the data classification and eDiscovery questions have real answers, and legal and compliance have signed off in writing. That is not obstruction. It is giving the organization a defensible position to point at while the picture develops, so the decision is made deliberately by the people accountable for it rather than by default the day the first machine arrives.
The practical near-term to-do list is short. Get the hard questions to your Microsoft account team in writing and hold them to specifics rather than reassurance. Add Recall to your endpoint standard as blocked-pending-review so the posture is documented before anyone asks. Brief legal and compliance now, while it is a planning exercise and not an incident response. And frankly, expect scrutiny and changes before this reaches broad availability — a feature this sweeping, announced this fast, is going to get poked hard by a lot of serious people, and the shape it ships in for enterprises may not be the shape it was announced in yesterday. Planning for that evolution is more useful than reacting to the keynote.
If you're facing this
If Copilot+ PCs are anywhere on your hardware roadmap, or your users have already started forwarding you the launch coverage asking when they can have one, the time to set a posture is now, before the devices land and the defaults decide for you. We have the hard-questions memo and the blocked-pending-review standard drafted from this week's work and can adapt them to your obligations. Get in touch and we will help you take a defensible position while the details settle.