The Medical Device Problem Nobody Puts in the Deal Room
I do not write scare pieces. That is not what Vorex Intelligence Group does, and it is not how I think about risk. Doom-and-gloom gets clicks; it rarely gets deals structured better.
But I recently finished a research engagement for a client that sent me deep into a corner of the threat landscape I had not spent much time in: medical devices. What I found was not theoretical. It was not a projected risk or a worst-case scenario. It was a documented, quantified, reproducible gap that sits inside virtually every hospital network in the country and by extension, inside every healthcare acquisition that does not specifically look for it.
I want to walk you through what I found, why it matters to M&A and PE teams specifically, and what questions you should be asking before you close on a healthcare target.
What the Research Showed
Unit 42 (Palo Alto Networks) analyzed 200,000 infusion pumps across hospital networks. Seventy-five percent contained at least one known vulnerability. Fifty-two percent were susceptible to two specific CVEs with a CVSS score of 9.8 — the top of the Critical scale. Those vulnerabilities were disclosed in 2019. Six years ago.
CVSS 9.8 means: attackable over the network, no privileges required, no user interaction required, full impact on confidentiality, integrity, and availability. That is as bad as it gets on the scoring scale.
Infusion pumps account for approximately 38% of all connected medical devices in a typical hospital. The picture with other categories MRI machines, CT scanners, patient monitors, imaging systems is not better.
This is not a niche finding. This is the baseline condition of most hospital networks right now.
Why This Is an M&A Problem, Not Just a Security Problem
When I think about this through the lens of a deal, three categories of exposure stand out.
Regulatory liability that does not appear in financial statements
Medical devices in the United States operate under FDA oversight. The FDA has been increasing pressure on manufacturers to implement Software Bills of Materials (SBOMs) registries of every software component inside a device, including third-party libraries and their version numbers. Many devices currently in hospital networks predate those requirements entirely.
Here is what that means in practice: a hospital may be running devices with known critical vulnerabilities that cannot be patched, ever, because patching firmware on an FDA-cleared device requires recertification. The manufacturer may no longer support the device. The hospital may have no path to remediation short of full device replacement.
That is a capital expenditure liability. It does not show up in the income statement. It will not appear in a standard financial audit. It requires a technical assessment to find and most healthcare due diligence processes do not include one.
Data breach exposure with a long discovery window
The protocols that medical devices use to communicate were not designed with security in mind. DICOM the standard for transmitting medical images between devices and storage systems requires no authentication by design. Any device on the same network can query a DICOM server and retrieve patient images and associated data. HL7, the protocol carrying lab results, prescriptions, and patient records between systems, transmits in cleartext.
In a flat hospital network meaning no segmentation between device categories and administrative systems an attacker who gains access to one device can move laterally to patient records, billing systems, and administrative infrastructure. That lateral movement is often trivial because the network was never designed to prevent it.
Per Industrialcyber, incidents involving penetration into medical facility networks through equipment increased 42% in the first nine months of 2025.
A healthcare target that has experienced a breach originating through a medical device may not know it. These networks frequently lack the monitoring tools that would detect such movement. Standard endpoint detection and response agents cannot be installed on devices running embedded operating systems. Security information and event management platforms do not parse DICOM or HL7 traffic by default. The blind spots are structural.
The discovery window for this class of breach is long. A PMC/OCDS study covering 92 million procurement records across 36 countries found an average exposure window of 3.2 years from device purchase to CVE publication meaning devices operate for years with vulnerabilities no one has catalogued yet. Even after a CVE is published, devices routinely remain unpatched for the remainder of their operational lifecycle, which runs eight to ten years in medical environments.
Valuation risk from deferred remediation
Device lifecycles in healthcare run eight to ten years. Replacement cycles are driven by clinical function, not security posture. A hospital acquiring a new imaging system does not retire the old one because it runs a vulnerable operating system — it retires it when the clinical upgrade justifies the capital cost.
That means the installed base of vulnerable devices in a target company’s network is not a problem with a near-term solution. It is a cost that will be carried forward. Network segmentation isolating medical devices into separate network zones with strict access controls is the primary remediation path that does not require device replacement. It is also an infrastructure project with real cost, real timeline, and real operational disruption during implementation.
For a PE fund modeling a healthcare acquisition, the question is not whether vulnerabilities exist. Per the Unit 42 data, they almost certainly do. The question is: what is the cost to bring the network to a defensible posture, and who is carrying that cost in the deal structure?
What the Vulnerabilities Actually Look Like
I want to be specific here, because the abstract version of this risk is easy to dismiss. The concrete version is harder to set aside.
The two CVEs affecting 52% of the pumps in the Unit 42 study include CVE-2019-12255, a buffer overflow in the VxWorks TCP/IP stack the operating system layer running on a large share of embedded medical devices. CVSS 9.8. Network-accessible. No authentication required. EPSS score of 0.80, placing it in the top 1% of vulnerabilities by exploitation probability. A public exploit exists. The vulnerability was published in 2019. Devices running VxWorks are still operating in hospital networks without patches, because patching requires firmware recertification, and recertification requires manufacturer support that may not exist.
A separate vulnerability class CVE-2020-12040, affecting Baxter Sigma Spectrum infusion pumps involves cleartext transmission of all status and operational data between the pump and its drug library server. An attacker on the same network segment can intercept that communication and, from that position, manipulate transmitted data. On an infusion pump, transmitted data includes dosage parameters.
I am going to stop there and not editorialize further on that particular implication. The risk is self-evident.
Physical access to devices yields an additional vulnerability class. BD Alaris infusion pumps models covered under CVE-2016-9355 and CVE-2016-8375 — store wireless network credentials in unencrypted flash memory, accessible to anyone who opens the casing. Security researchers, including Billy Rios, one of the leading figures in medical device security, have demonstrated this by purchasing decommissioned devices on eBay and extracting credentials from them in a lab. Decommissioned devices from your acquisition target may be on the secondary market right now.
The Network Architecture Problem
Individual device vulnerabilities are one issue. The network architecture that connects them is a separate and in some ways larger issue.
Most hospital networks were built for clinical function, not security segmentation. Infusion pumps, imaging systems, physician workstations, billing systems, and administrative infrastructure often share the same network segments. The protocols in use DICOM, HL7 were designed in an era when the network perimeter was the security boundary, and the assumption was that anything inside the hospital was trusted.
That assumption has not been valid for years. Guest Wi-Fi, vendor remote access, compromised contractor credentials, and supply chain attacks have all been used to gain initial access to hospital networks. Once inside a flat network, lateral movement to clinical systems is often a matter of minutes.
The monitoring tools that would detect this movement do not work on most medical devices. Endpoint detection agents are incompatible with embedded operating systems. Network traffic analysis tools are not configured to parse medical protocols. The devices generate no logs that a SIEM can ingest.
In practice, this means a hospital network can sustain an active intrusion that touches clinical systems without any alert being generated. The intrusion becomes visible only when it reaches systems that do have monitoring billing, administration, EHR platforms or when ransomware is deployed and clinical operations are disrupted.
What to Ask Before You Close
Based on my research, I would add the following to any healthcare due diligence process:
Device inventory with CVE mapping: Request a complete inventory of networked medical devices including make, model, firmware version, and operating system. Map that inventory against published CVEs. If the target cannot produce this inventory, the absence is itself a finding — you cannot manage risk you cannot see.
Network architecture documentation: Request network diagrams showing segmentation between medical device VLANs and administrative systems. Ask specifically whether DICOM and HL7 traffic is restricted to authorized network paths, or whether those protocols are permitted broadly.
Patch and update history: For each device category, ask what the manufacturer’s current support status is, whether firmware updates are available and applied, and what the remediation path is for devices that cannot be patched. Understand the delta between current firmware and the latest available release.
Incident history: Ask specifically about incidents involving medical devices, not just IT systems. Ask whether the hospital has experienced unexplained network anomalies, device communication failures, or performance degradation that was not traced to a clinical cause. These are potential indicators of compromise that may not have been investigated as security events.
Remediation cost estimate: If the assessment surfaces significant vulnerabilities, request an independent estimate of the cost to implement network segmentation across the affected device population. This is a capital cost that belongs in your model.
Vendor agreements and support contracts: Review manufacturer support agreements for end-of-life devices. Understand which devices are operating beyond manufacturer support windows and what the contractual path to remediation looks like.
The Framing I Keep Coming Back To
I said at the start that I do not write scare pieces. That is still true. The framing I keep coming back to is a simpler one: there are costs in this acquisition that are not in the data room, and the technical assessment required to find them is not standard in most healthcare deals.
The vulnerabilities are catalogued. The exploitation paths are documented. The monitoring gaps are structural. None of this is speculation it is the current condition of most hospital networks, confirmed by independent research across hundreds of thousands of devices.
The question for M&A teams is not whether the risk exists. It almost certainly does. The question is who is pricing it and whether that pricing is showing up in the deal structure before closing or in remediation costs after.
In my experience, deals that answer that question before closing are better deals.