I. The 90 Percent Problem -- and the Feature That Just Made It Worse

The statistic that should restructure how every mid-size health system thinks about cybersecurity: over 90 percent of breached patient records in recent years were not stolen from the core electronic health record. They were taken from the systems around it -- cloud file shares, email accounts, backup repositories, billing platforms, and clinical workstations. The EHR itself is often the most hardened system in the environment. The systems that touch the EHR, feed it, and receive its outputs are frequently not.

Zero Trust is the security framework designed to address exactly that gap. Its core premise is that the traditional network perimeter -- the assumption that anything inside the firewall can be trusted -- has failed. Zero Trust replaces that assumption with three operating principles: never trust any access request without verifying it, assume that a breach has already occurred, and enforce least privilege so that even a verified user can access only what they specifically need.

In March 2026, Microsoft's Windows 11 Copilot+ PC feature called Recall added a new dimension to this problem. Recall is an opt-in AI feature that takes screenshots of everything visible on a workstation every few seconds, runs optical character recognition on those screenshots, and stores a searchable index of everything the device has ever displayed. On a shared clinical workstation -- one that has been used to review EHR charts, lab results, patient schedules, and insurance records -- Recall would create a persistent, locally stored, AI-indexed archive of protected health information. And as of March 19, 2026, cybersecurity researcher Alexander Hagenah publicly reported finding a new extraction vulnerability in Recall for the second time -- one that allowed the entire database to be dumped without user interaction.

This article covers both stories as a single 2026 priority. Zero Trust is the strategic framework. Recall is the specific, immediately actionable example of why that framework matters right now. Together they define what mid-size health systems and Critical Access Hospitals need to have in place before the next incident makes these decisions for them.

II. Zero Trust for Mid-Market Health Systems: What It Is and What It Is Not

The Framework, Not the Product

Zero Trust is not software you purchase and deploy. It is not a single vendor's platform. It is a security architecture built on three principles that, taken together, fundamentally change how every access request in your environment is evaluated.

• Never trust, always verify: every access request -- from any user, any device, any location -- must be authenticated and authorized against defined policies before being granted. Being inside the network perimeter is not sufficient.

• Assume breach: design your environment as though an attacker already has a foothold somewhere inside it. The question is not whether to prevent every intrusion but how to limit the damage when one occurs.

• Enforce least privilege: users and systems get access only to the specific resources they need for their specific function -- and only for the period they need it. A nurse's credential that can access the EHR should not be able to reach backup servers, cloud file shares, or billing systems.

For healthcare organizations, these principles directly address the 90 percent problem. If your clinical workstations are micro-segmented from your backup repositories, a compromised workstation cannot be used to encrypt your backups. If your privileged accounts require just-in-time elevation rather than standing access, a stolen credential is significantly less valuable to an attacker. If your device compliance policies block non-compliant endpoints from accessing EHR systems, a workstation with Recall enabled -- or with an unpatched vulnerability -- is blocked at the perimeter before it becomes a data source for an attacker.

Mid-Market Reality: What This Costs and What Tools You Already Have

The Zero Trust implementations documented in large health system case studies involve multi-million-dollar investments, dedicated security operations centers, and enterprise licensing that mid-size systems and CAHs cannot replicate. But Zero Trust is a phased architecture, not an all-or-nothing deployment. Mid-market organizations can achieve meaningful Zero Trust maturity over 6 to 12 months with a realistic investment of $200,000 to $500,000 -- and significantly less if Microsoft tools are already part of the environment.

The most important cost observation for organizations already running Microsoft 365: many of the capabilities needed for a functional Zero Trust foundation are already licensed. Entra ID Conditional Access, Intune device management, and Defender for Endpoint are included in M365 E3 or E5 licensing tiers that many healthcare organizations already pay for. The gap is not always a licensing gap -- it is a configuration and deployment gap.

The Four-Phase Implementation Roadmap

The roadmap below is calibrated for mid-market health systems and CAHs. Budget estimates reflect typical costs excluding existing Microsoft licensing already in your environment.

Phase 1 -- Discovery and Inventory (Weeks 1-8, $0-$15K)

Map every user, device, application, and data flow with a specific focus on non-EHR PHI repositories: cloud file shares, email archives, backup systems, and clinical workstations. Use Entra ID discovery, Intune device inventory, and Defender for Endpoint onboarding -- available at no incremental cost if M365 is already licensed. You cannot segment what you have not mapped.

Phase 2 -- Identity and Access Foundation (Months 2-4, $30K-$80K)

Enforce phishing-resistant MFA on every user who accesses ePHI systems. Standard authenticator app MFA can be defeated by adversary-in-the-middle phishing -- FIDO2 hardware keys or Windows Hello for Business are the current recommended standard. Deploy Entra ID Conditional Access policies requiring both strong authentication and device compliance before granting access to clinical applications. Implement just-in-time privileged access for admin accounts via Entra Privileged Identity Management.

Phase 3 -- Micro-Segmentation and Device Posture (Months 4-7, $50K-$150K)

Segment clinical workstation networks so a compromised endpoint cannot reach EHR servers, backup repositories, or administrative systems. VLAN-based segmentation on-premises; Azure Virtual Network segmentation for cloud workloads. Require Intune device compliance -- including Recall-disabled status -- as a Conditional Access prerequisite. A compliant, segmented clinical workstation that is compromised is a contained incident. An unsegmented one is a network-wide incident.

Phase 4 -- Continuous Monitoring and Automation (Months 7-12, $40K-$120K)

Deploy Microsoft Sentinel or equivalent SIEM for centralized logging. Configure behavioral anomaly alerts: off-hours logins, bulk downloads, new mail forwarding rules, and anomalous processes accessing the Recall database path. Build automated response playbooks for common alert types. Update your HIPAA risk analysis quarterly to reflect current Zero Trust control status.

III. Microsoft Recall on Clinical Workstations: The Specific HIPAA Risk

What Recall Actually Does

Microsoft Recall is available on Windows 11 version 24H2 and later, on devices with Copilot+ PC hardware -- specifically, machines with a neural processing unit (NPU) capable of running local AI inference. Microsoft CEO Satya Nadella described Recall as giving Windows a 'photographic memory.' That description is accurate. Recall takes screen snapshots every few seconds or whenever content changes, runs optical character recognition on those snapshots, and creates an AI-indexed, searchable timeline of everything the device has ever displayed. A user can search in natural language -- 'show me the lab results I looked at on Tuesday' -- and Recall retrieves the relevant snapshot.

For a personal device used exclusively by one person for non-clinical purposes, Recall is a productivity tool with documented privacy tradeoffs. For a clinical workstation that has displayed EHR charts, patient schedules, lab results, insurance eligibility information, and medication administration records, Recall is a PHI capture mechanism that operates without clinician awareness and without patient authorization.

The March 2026 Vulnerability: Still Not Solved

Recall's security posture has been a documented concern since its announcement in 2024. The original design stored snapshots in an unencrypted SQLite database -- a vulnerability so widely criticized that Microsoft redesigned the feature before its initial commercial release. The redesigned version stores data in encrypted form, with encryption keys tied to Windows Hello credentials.

On March 19, 2026:  Cybersecurity researcher Alexander Hagenah publicly disclosed finding a second extraction vulnerability in Recall. Hagenah stated he was able to locate where the feature stores encrypted data and extract the entire database contents for easy review -- without requiring user interaction, by a process running with sufficient privilege. Hagenah reported the vulnerability to Microsoft and the case was under review as of publication. He noted: 'Software of this complexity is never fully solved from a security perspective. When a feature touches multiple components and likely involves several teams and engineering disciplines, achieving a fully streamlined security model becomes inherently more difficult.'

The practical implication for healthcare IT directors is not that Recall is uniquely dangerous compared to other endpoint risks. It is that Recall is a new, optional, and completely disableable feature that creates documented PHI exposure risk -- and that disabling it is a ten-minute administrative task that eliminates the exposure entirely. The cost-benefit analysis is not complicated.

The BAA Gap: What Microsoft Does and Does Not Cover

Microsoft signs Business Associate Agreements for its enterprise cloud services -- Azure, Microsoft 365, Defender, and related cloud platforms. Those BAAs provide HIPAA coverage for PHI processed through those services. The Windows client operating system is not a cloud service. Microsoft does not sign a BAA covering local OS features including Recall. That means every covered entity deploying Windows 11 Copilot+ PCs bears full HIPAA responsibility for Recall's configuration, data handling, and security posture on those devices.

The compliance implication is direct: if Recall captures PHI on a clinical workstation and that data is subsequently accessed by an unauthorized party -- through the March 2026 extraction vulnerability or any future one -- that is a covered-entity HIPAA violation. Not a vendor breach. Not a business associate incident. Your organization's breach to report.

The Recall Risk Matrix

The following table maps the specific Recall risk scenarios in clinical environments and the Zero Trust controls that address each one.

IV. How Zero Trust Specifically Contains the Recall Risk

The reason to address Recall and Zero Trust as a single article is that they are not parallel stories -- Recall is a specific, concrete example of the threat category that Zero Trust is designed to contain.

Device Posture Enforcement Blocks Recall at Access

Zero Trust Phase 3 deploys device compliance policies through Intune. A device with Recall enabled can be marked non-compliant. A non-compliant device is blocked by Conditional Access from reaching any EHR, email, or clinical application. This means a clinical workstation that -- through user action or policy misconfiguration -- has Recall active cannot access patient data until the compliance violation is remediated. The PHI capture risk is contained before any data is accessed.

Micro-Segmentation Limits Recall Exposure Post-Compromise

If a Recall extraction vulnerability is exploited on a compromised clinical workstation, micro-segmentation determines what the attacker can reach next. In a flat network, a compromised workstation can pivot to EHR servers, backup repositories, and administrative systems. In a micro-segmented Zero Trust network, a compromised clinical workstation reaches only what clinical workflows require -- which limits the value of any data extracted from the Recall database and prevents the lateral movement that turns a single endpoint compromise into a system-wide breach.

Continuous Monitoring Detects Anomalous Recall Database Access

Phase 4 of the Zero Trust roadmap deploys SIEM and behavioral monitoring. The Recall database has a known file path on Windows 11 Copilot+ PCs. A process accessing that path outside of expected Recall operational patterns -- especially one running at elevated privilege -- is a detectable behavioral anomaly. Microsoft Sentinel can be configured with a custom alert rule for this specific path. Without centralized logging and behavioral monitoring, the March 2026 extraction vulnerability could be exploited silently on a clinical device with no detection.

Least Privilege Limits What a Recall-Enabled Device Can Do

Even if Recall captures PHI on a shared clinical workstation, the Zero Trust least-privilege principle limits the downstream damage. A clinical workstation account with access only to the specific EHR modules required for that device's clinical function -- and nothing else -- limits the PHI exposure to what that workstation is authorized to access. The scope of a Recall-based breach from a properly segmented, least-privilege-configured device is dramatically smaller than from a flat-network device with broad credential access.

V. HIPAA Compliance Matrix

The following table maps both Zero Trust and Recall to specific HIPAA Security Rule provisions. Use it as a gap analysis reference for your next risk analysis update or compliance review.

VI. 2026 Action Roadmap

Red rows are Recall-specific actions -- immediate priority. Teal rows are Zero Trust implementation phases. Amber rows address training. Green rows address continuous monitoring.

VII. Looking Ahead

The HIPAA Security Rule Updates and Zero Trust

The proposed HIPAA Security Rule updates, with a May 2026 finalization target, reference several Zero Trust principles directly. Network segmentation requirements, multi-factor authentication mandates, and access control specificity are all elevated in the proposed rule. Organizations that complete Phases 1 and 2 of the Zero Trust roadmap before the rule takes effect are building toward the expected regulatory baseline rather than retrofitting after mandate. The proposed rule also explicitly references the need to identify and document AI tools that process or access ePHI -- a direct reference to the category that Recall occupies.

Recall Will Evolve -- and So Will the Risks

Microsoft's roadmap for Recall includes expanded Purview DLP integration -- the ability to configure sensitivity labels that prevent Recall from indexing labeled content. If your organization deploys Microsoft Purview with sensitivity labels on clinical documents and EHR data, Recall can theoretically be configured to exclude that content. But that configuration requires Purview licensing, label deployment, and ongoing governance -- a significant administrative investment compared to simply disabling Recall on clinical devices. The current recommendation from security practitioners is to disable Recall on clinical and shared workstations and revisit the decision when the feature's security posture stabilizes after the current vulnerability disclosure cycle completes.

AI Endpoint Features Are a New Permanent Risk Category

Recall is the current example, but it will not be the last. As AI capabilities are embedded more deeply into operating systems and productivity tools, the endpoint becomes an AI processing environment as well as a user interface. Each AI feature that operates locally on a clinical device represents a new data handling question: what does it capture, where does it store it, who can access it, and does Microsoft's existing BAA cover it? Healthcare IT directors need a standing process for evaluating new AI OS features as they ship -- not a reactive one triggered by the next security researcher's disclosure.

VIII. Conclusion

The 90 percent problem and the Recall risk are the same problem at different scales. The attackers who are stealing healthcare data in 2026 are not primarily breaking through EHR defenses. They are finding the systems around the EHR -- the endpoints, the cloud shares, the backup repositories, the clinical workstations -- that were not designed with Zero Trust principles and were not hardened against the assumption that a breach will eventually occur.

Recall is a concrete, specific, disableable example of that category. A ten-minute Intune policy deployment eliminates a documented PHI capture risk on every managed clinical workstation in your environment. That is not a complex security project. It is a configuration decision with a clear HIPAA compliance rationale and a documented enforcement basis in OCR's Risk Analysis Initiative.

Zero Trust is the longer project. But it is not an all-or-nothing investment. Phase 1 -- inventory your PHI locations outside the EHR -- costs nothing if you have Entra ID and Intune in your environment. Phase 2 -- deploy Conditional Access and phishing-resistant MFA -- is available in licensing many organizations already pay for. The gap between where most mid-market health systems are and where Zero Trust Phase 1 and 2 take them is largely a configuration gap, not a budget gap.

Disable Recall this week. Start the inventory this month. The framework that contains the next Recall -- whatever it is called -- is the same one that contains the ransomware attack your risk analysis already documents.

This article is for informational purposes only and does not constitute legal or technical advice. Microsoft Recall feature status, vulnerability details, and Group Policy/Intune configuration options are based on publicly available Microsoft documentation, security research disclosures, and news reporting as of March 23, 2026. Vulnerability details are based on public researcher disclosures; Microsoft's response to the March 2026 finding was pending review at publication. Consult qualified legal counsel and IT security professionals regarding your organization's specific HIPAA obligations and technical implementation