“Legacy system” is the polite term. What most healthcare security leaders mean when they say it is something more specific and more frustrating: a system they cannot patch, cannot replace, and cannot take offline, because it is still running something critical. An imaging workstation on Windows 7. A laboratory information system built on a database platform the vendor abandoned in 2018. A clinical device whose firmware hasn’t been updated since the Obama administration because the manufacturer no longer supports it and a replacement would cost seven figures and eighteen months of regulatory approval.
These systems exist in virtually every healthcare organization. They are not theoretical risks - they are active vulnerabilities sitting on networks that also hold EHR data, patient identifiers, and billing systems. And the challenge they present for security teams is not just operational. It is methodological: how do you test something you cannot touch, cannot patch, and cannot afford to disrupt?
The answer is not to skip them. It is to test smarter.
Why Legacy Systems Are a Disproportionate Risk
The threat these systems pose is not symmetrical to their age. A fifteen-year-old Windows XP workstation running an embedded clinical application is not just an outdated machine - it is an unmonitored, unpatched, often network-connected asset sitting inside the same trust boundary as your most sensitive data. It almost certainly cannot run an endpoint detection agent. Its vendor may no longer exist. The staff managing it may not have touched its configuration in years.
From an attacker’s perspective, legacy systems are attractive precisely because of their neglect. Exploit code for end-of-life operating systems is freely available and well-documented. Default credentials on systems that have never been hardened are common. And because these systems generate little security telemetry - they do not appear in SIEM dashboards, they are not enrolled in vulnerability management platforms, they are not included in patch cycles - compromise can go undetected for months.
According to the HHS 405(d) Health Industry Cybersecurity Practices report, unpatched and end-of-life systems are among the top five cybersecurity threats facing healthcare organizations today. The Ponemon Institute has found that legacy systems are a contributing factor in more than a third of healthcare data breaches: not because they are targeted exclusively, but because once an attacker establishes a foothold elsewhere, legacy systems frequently provide the easiest lateral movement path to high-value data.
The Testing Challenge: First, Do No Harm
The clinical imperative, first, do no harm, applies to security testing as much as it does to patient care. A penetration test that crashes a ventilator controller, disrupts a laboratory information system mid-workflow, or causes an imaging workstation to freeze during a procedure is not a security win. It is a patient safety incident and a liability event.
This is the constraint that shapes everything about how legacy healthcare systems should be tested. And it is a constraint that rules out a significant portion of standard penetration testing methodology at least when applied directly to the systems themselves.
Active exploitation of a fragile legacy system is rarely the right approach. These systems were not built to withstand modern exploit payloads, and the consequences of instability are unacceptable. What responsible testing of legacy environments looks like instead is a combination of passive reconnaissance, careful enumeration, and aggressive testing of the controls and network architecture around the system rather than the system itself.
The Right Framework: Test What Surrounds It
The most important conceptual shift when approaching legacy system security testing is moving from “can I exploit this system?” to “what can an attacker do if they reach this system, and what would stop them?”
That reframe unlocks a productive testing methodology even when direct exploitation is off the table.
The matrix above captures the core prioritization logic. Legacy systems that are both clinically critical and unpatchable, the upper right quadrant, demand the most intensive security attention, but not necessarily the most aggressive testing of the system itself. The testing focus shifts to the network controls, authentication requirements, and monitoring capabilities that govern access to those systems. Can an attacker reach the system from a compromised workstation on a different VLAN? Can they authenticate with credentials harvested elsewhere? If the system were compromised, would anyone know?
For systems in the lower right, unpatchable but lower clinical criticality, the priority is aggressive network segmentation and exposure reduction. These systems are still potential entry points and lateral movement stepping stones, but the blast radius of a compromise is more containable. The testing goal is to validate that the segmentation actually holds under adversarial conditions, not just that it is configured.
What a Legacy-Aware Testing Engagement Looks Like
A penetration testing engagement that accounts for legacy systems requires a different scoping conversation than a standard external or internal assessment.
It starts with discovery and inventory. Before any testing begins, the engagement needs to establish a complete picture of what legacy assets exist, what operating systems and firmware versions they run, what network segments they occupy, and what other systems they communicate with. This is often the most revealing phase: organizations frequently discover legacy assets they did not know were on the network, or connections between segments they believed were isolated.
The workflow above reflects how a well-structured engagement proceeds. Discovery and risk assessment come first, establishing what exists and how much exposure each system represents. Isolation validation follows before any testing touches systems in the legacy environment, the penetration tester should confirm that network segmentation controls are in place and that the blast radius of testing activity is understood and bounded.
Testing then focuses on the controls around the legacy system rather than the system itself: firewall rules, VLAN boundaries, authentication requirements for management interfaces, monitoring coverage, and lateral movement paths from adjacent network segments. The goal is to answer the question an attacker would ask: if I reach this system, where can I go next, and will anyone stop me?
Validation and documentation close the engagement. Compensating controls that hold up under testing are documented as such. Gaps - network paths that should not exist, authentication that can be bypassed, monitoring that generates no alerts - are reported with the same rigor as findings against any other system type. Residual risk, for systems where controls cannot fully mitigate the exposure, is formally documented to support risk acceptance decisions.
The Compensating Control Conversation
For legacy systems that cannot be patched or replaced on any near-term timeline, the security program’s responsibility is to implement and validate compensating controls and to document them formally as the accepted risk mitigation strategy.
HIPAA’s Security Rule explicitly contemplates this through its flexibility provisions. Where a specific implementation specification cannot be met, covered entities are permitted to implement an equivalent alternative measure. But that alternative must be documented, must demonstrably reduce risk, and must be validated as effective. A compensating control that exists on paper but has never been tested is not a compensating control - it is an aspiration.
The compensating controls most relevant to legacy clinical systems typically include aggressive network segmentation to limit what the system can reach and what can reach it; enhanced monitoring of network traffic to and from the system to detect anomalous behavior; strict authentication controls on any management or administrative access path; and compensating endpoint controls such as application whitelisting or read-only filesystem configurations where the system’s architecture permits it.
Testing these controls under realistic adversarial conditions; attempting to bypass segmentation, attempting to reach the legacy system from other network segments, attempting to move laterally from the legacy system to adjacent assets is the core value that penetration testing delivers in legacy environments. It is not about finding a new vulnerability in a fifteen-year-old operating system. It is about confirming that the walls around it are as solid as the documentation claims.
The Documentation Imperative
One aspect of legacy system security that is underappreciated is the documentation requirement. Healthcare organizations that carry significant legacy system risk, and most do, need a formal record of how that risk is being managed. Risk acceptance decisions should be documented with specificity: which system, which vulnerability or exposure, which compensating controls are in place, who approved the risk acceptance, and when it will be reviewed.
For HIPAA purposes, this documentation is the evidence that the organization has identified the risk through its risk analysis, evaluated it, and made a reasoned decision about mitigation. Organizations that can produce that record along with testing evidence confirming that compensating controls are operational - are in a substantially stronger position than those who simply acknowledge that legacy systems exist and have not formally addressed them.
Penetration testing results, even when they reflect the constrained methodology required for clinical environments, contribute directly to that record. A finding that says “network segmentation successfully prevented lateral movement from the legacy PACS workstation to the EHR database segment” is meaningful evidence. So is a finding that says it did not.
Key Takeaways for Security Leadership
Legacy healthcare systems are not a problem that goes away, and they are not a problem that can be solved by exclusion from the security program. The systems your organization cannot patch or replace are, in many cases, the systems an attacker would most like to reach or most like to move through on the way to something else.
A security program that addresses this reality does three things: it maintains an accurate, current inventory of legacy assets and their network exposure; it implements and formally validates compensating controls for systems that cannot be remediated; and it includes those systems, or more precisely, the controls surrounding them, in the scope of regular penetration testing.
The goal is not perfection. It is demonstrable, documented diligence and a clear understanding of where the residual risk lives.
Want to build a penetration testing program that accounts for your legacy clinical environment?Learn more at sprocketsecurity.com or reach out at contact@sprocketsecurity.com.
