Every Copilot+ PC that arrives at an ITAD dock this year is potentially carrying something that didn’t exist on a corporate laptop two years ago: a dense, time-stamped archive of nearly everything that ever crossed the user’s screen. That expands the threat model for every operator in the ITAD and secondary market industries, and a fresh round of security research suggests the box on the pallet may be more sensitive than the spec sheet implies.
A quick refresher. Recall is the AI feature Microsoft built into Copilot+ PCs that takes periodic screenshots of the user’s screen, runs OCR on them, and stores the results in an encrypted local SQLite database that users can search by natural language. After Microsoft pulled the original 2024 release in response to a security backlash, the company rebuilt Recall around Virtualization-Based Security (VBS) enclaves, AES-256-GCM encryption, Windows Hello biometric authentication, and a Protected Process Light host for keys, and relaunched it in April 2025. Microsoft’s stated design goal was to block “latent malware trying to ‘ride along’ with a user authentication to steal data.”
In March 2026, Zürich-based researcher Alexander Hagenah, the same researcher whose original TotalRecall tool forced the 2024 redesign, published a successor called TotalRecall Reloaded that performs the same action Microsoft said it had prevented. Running as an ordinary user, with no admin rights, no kernel exploit, and without breaking any encryption, the tool injects into AIXHost.exe (the Windows process that renders the Recall timeline) and extracts screenshots, thumbnails, OCR text, and metadata after the user authenticates through Windows Hello. Hagenah’s summary: “The vault door is titanium. The wall next to it is drywall.”
Microsoft disagrees that this is a vulnerability. David Weston, corporate vice president of Microsoft Security, told The Verge that “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 company’s position is that any same-user process can do this kind of thing, it’s how Windows works.
For ITAD and secondary-market operators, that argument is where the problem begins. Until now, a retired laptop was a collection of separately protected data stores, from an Outlook cache and a browser profile to some local files, and maybe a password manager. Each had its own protections, and a NIST 800-88-aligned wipe handled them all by handling the underlying media. Recall doesn’t change the wipe, a cryptographic erase or purge per NIST SP 800-88 Rev. 2, finalized in September 2025, still renders the bits inaccessible. What Recall changes is everything that happens before the wipe.
Here are three implications that come to mind and are worth raising with clients now:
Pre-collection is now a data-destruction event. A Copilot+ device powered on in a staging room, a transport locker, or a third-party logistics handoff carries a unified, decryptable-on-authentication record of the user’s working life, from emails and Teams chats to CRM screens, financial models, and displayed credentials. NIST 800-88 Rev. 2’s emphasis on enterprise-program governance and chain-of-custody evidence applies directly to this gap. Devices should be powered down, or Recall snapshots purged, before they leave the client’s controlled environment.
Certificates of sanitization need to evolve. Generic “user data destroyed” language no longer covers the question an auditor or downstream buyer will start asking: were Recall snapshot stores specifically destroyed, and is there evidence? Operators who can attest to that, by batch, with serials where the policy requires, have a defensible answer that competitors using legacy templates do not.
There are really two moments where this can be addressed, and they answer different questions. The first is at the client site, before collection: the user or IT disables Recall and deletes the snapshot store while the OS is still running and authenticated. This is the only moment where Recall destruction can be verified as a discrete action, with a timestamp, on a working system.
The second is at the ITAD facility, where a NIST 800-88 cryptographic erase or purge destroys the snapshot store along with everything else on the drive. The data is gone, but the certificate can only honestly say the media containing Recall snapshot data was sanitized,, it cannot specifically attest that Recall was handled as a distinct artifact, because by that point Recall is just bytes on a drive indistinguishable from any other bytes. The defensible Recall-specific certificate requires the first moment.
Client conversations should distinguish managed from unmanaged fleets. On managed enterprise devices, IT admins can disable Recall via policy, and Microsoft Purview now offers DLP controls for Recall snapshots. On unmanaged Copilot+ PCs — including BYOD, executive devices, and small-business fleets, Recall is available by default, with users opting in. Mixed fleets need a documented intake question, and not just an assumption.
The two-moment distinction has a commercial implication worth sitting with. It pushes some data-destruction work upstream, into the client’s environment, in a way the industry hasn’t really had to deal with before. Most ITAD value propositions are built on “hand it to us, we’ll handle everything.” Recall complicates that because the highest-value verification has to happen before the handoff.
All in all, while the encryption is sound, the enclave is solid and the wipe still works, what’s new is the concentration of risk between the moment a device leaves the user’s desk and the moment it reaches the shredder or wipe queue. And that window is ITAD’s to manage.
