# Medical Device Cybersecurity
Medical device cybersecurity is the discipline of protecting networked medical equipment from unauthorized access, manipulation, and disruption, with the specific recognition that compromise of these devices can cause direct physical harm to patients. It occupies a distinct position in the security landscape because the consequences of a failure are not limited to data loss, regulatory penalties, or operational disruption; they extend to patient injury or death.
A networked infusion pump that delivers the wrong dosage because an attacker modified its programming is not equivalent to a compromised file server. A pacemaker that receives unauthorized commands over a wireless protocol is not equivalent to a phished email account. An insulin pump that is instructed to deliver an incorrect bolus is not equivalent to a defaced website. The physical consequence dimension places medical device security in a risk tier that demands a different analytical framework, a different regulatory context, and a different set of compensating controls than conventional IT security.
The scope of the problem has grown substantially as healthcare delivery has become more dependent on networked technology. Modern hospitals connect hundreds to thousands of devices to their clinical networks: patient monitoring systems, infusion pumps, imaging equipment (MRI, CT, X-ray), ventilators, laboratory analyzers, surgical robots, and implantable devices with telemetry capabilities. Each of these represents an attack surface that, if exploited, could affect a patient.
Medical device cybersecurity encompasses three distinct problem spaces that require different approaches: securing new devices entering the market, managing legacy devices already deployed in clinical environments, and maintaining network-level visibility and control across both populations.
New Device Security Requirements
The FDA's December 2022 amendment to the Federal Food, Drug, and Cosmetic Act (FD&C Act), signed into law as part of the Consolidated Appropriations Act 2023, created explicit cybersecurity requirements for medical device premarket submissions. These requirements, detailed in the FDA's September 2023 "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" guidance, apply to any device that contains software or programmable logic.
Manufacturers submitting a 510(k), PMA, De Novo, or EUA application for a device with software must now provide: a plan to monitor, identify, and address cybersecurity vulnerabilities throughout the device's lifecycle; a Software Bill of Materials (SBOM) that identifies all software components including commercial, open source, and off-the-shelf software; documentation of the threat model used during design; evidence of security testing; a process for coordinated vulnerability disclosure; and plans for deploying security patches. The "reasonable assurance of safety and effectiveness" standard that governs all FDA submissions now explicitly includes cybersecurity.
A Software Bill of Materials is an inventory of every software component that runs on or within the device, including the operating system, firmware, libraries, and dependencies. The FDA requires this in machine-readable formats compatible with established SBOM standards (SPDX or CycloneDX). An SBOM enables healthcare organizations and the FDA to determine whether a device is affected when a new vulnerability is disclosed in a component; without it, determining exposure requires contacting the manufacturer and waiting for a response. With it, impact assessment can be partially automated.
The Legacy Device Problem
FDA premarket requirements apply to new submissions; they do not retroactively upgrade the security posture of the installed base of legacy devices already in clinical use. This creates a persistent, unresolvable gap: hospitals operate substantial populations of medical devices that were designed before cybersecurity was a regulatory concern, that run operating systems no longer receiving security updates, and that cannot be patched without triggering regulatory re-clearance requirements.
The operational lifecycles of medical devices are long by design. A diagnostic imaging system (MRI, CT scanner) typically remains in clinical service for 10 to 15 years. An infusion pump may operate for 8 to 12 years. An anesthesia delivery system may serve for 15 to 20 years. The capital cost of these devices and the complexity of clinical validation and staff training make early replacement economically impractical.
The software environments embedded in these devices reflect their vintage. It is common to find networked medical devices running Windows XP (end of extended support: April 2014), Windows 7 (end of extended support: January 2020), Windows CE, or Linux distributions with kernels from 2008 to 2012. Applying a Windows security patch to a cleared medical device requires the manufacturer to validate that the patch does not affect device function, update the 510(k) or PMA, and distribute the update. Many manufacturers choose not to pursue this process for older product lines. Some manufacturers have exited the medical device business entirely, leaving their device populations in an unpatched state with no responsible party.
The clinical reality is that security teams inherit these devices and must protect patients without the ability to apply the controls that would be standard in any other context: no patch, no EDR agent, often no ability to change credentials or disable unused network services.
The 2017 WannaCry ransomware attack provided the most consequential demonstration to date of medical device vulnerability in a clinical setting. WannaCry exploited EternalBlue, a Windows SMB vulnerability (MS17-010) developed by the NSA and later published by the Shadow Brokers. It spread autonomously through networks, encrypting files on every Windows system it could reach.
The UK National Health Service (NHS) was one of the hardest-hit organizations globally. Approximately one third of NHS Trusts were affected. The impacts included: imaging systems (MRI, CT, X-ray) that ran Windows XP or unpatched Windows 7 were encrypted and rendered unusable. Pathology laboratories lost access to test result systems. Patient record systems were encrypted, forcing clinicians to revert to paper records. Approximately 6,800 appointments were cancelled, including cancer appointments and non-emergency surgeries. Ambulances were diverted from affected hospitals. The estimated total cost to the NHS exceeded 92 million pounds.
WannaCry did not specifically target medical devices or healthcare. It was ransomware that spread opportunistically. The NHS's exposure was the predictable outcome of operating a large population of legacy Windows systems that could not be patched promptly, on networks without adequate segmentation to contain lateral movement. The attack was not sophisticated; it exploited a patched vulnerability on systems that could not receive the patch.
Beyond ransomware, researchers have demonstrated direct device manipulation attacks in controlled settings. Researchers at Billy Rios's organization disclosed vulnerabilities in Hospira (now ICU Medical) infusion pumps that could allow unauthorized modification of drug library parameters. Researchers at the University of Alabama demonstrated that an implantable cardioverter-defibrillator could receive unauthorized wireless commands at close range. The FDA's 2015 Safety Communication on Hospira infusion pump vulnerabilities was among the first public acknowledgments that networked medical devices were a patient safety concern, not merely an IT concern.
Network Segmentation for Medical Devices
The most effective compensating control for legacy medical devices is network segmentation. Placing all medical devices on dedicated clinical VLANs, isolated from the general hospital network, limits lateral movement and reduces the attack surface visible to each device class.
Effective segmentation for healthcare environments involves: a dedicated medical device VLAN or set of VLANs organized by device class and clinical unit; stateful firewall rules that permit only the specific traffic flows required for clinical function (device to Electronic Health Record system, device to clinical workstation, imaging device to PACS server); default-deny rules that block all other lateral traffic; and monitoring of all traffic crossing segmentation boundaries.
Access from general workstations or staff personal devices to the medical device VLAN should require explicit authorization and should be logged. Vendor remote access, which is a common vector for both legitimate maintenance and unauthorized access, should flow through a controlled remote access solution (privileged access management or a dedicated jump server) rather than through VPN configurations that grant broad network access.
Compensating Controls for Legacy Devices
Where patching is not possible, compensating controls must substitute for the protection that patches would provide. Network-level controls can block the specific vulnerability exploitation vectors even when the underlying vulnerability cannot be remediated.
For devices vulnerable to EternalBlue (the WannaCry vector), SMB traffic (TCP port 445) can be blocked at the network level for device segments that do not require file sharing. For devices with unencrypted management interfaces, network access control lists (ACLs) can restrict which source addresses are permitted to reach those interfaces. For devices with default credentials that cannot be changed without voiding clearance or breaking vendor support, MAC address binding and 802.1X port authentication can limit which physical ports can reach the device.
SBOM in Practice
For new devices that include SBOM documentation, healthcare organizations should integrate SBOM data into their vulnerability management programs. When a new CVE is disclosed affecting a software component, the SBOM allows the organization to query which devices contain that component, prioritize outreach to relevant manufacturers, and assess exposure before the manufacturer issues a formal communication.
The machine-readable SBOM formats required by the FDA (SPDX and CycloneDX) are compatible with vulnerability management tools that can cross-reference component versions against public vulnerability databases (NVD, OSV). This creates an automated exposure assessment pipeline that was not possible when device software contents were opaque.
Coordinated Vulnerability Disclosure in Healthcare
When security researchers discover vulnerabilities in medical devices, the standard responsible disclosure process is supplemented by the healthcare regulatory context. Researchers coordinate with the manufacturer, the FDA, and (in many cases) the Department of Homeland Security Cybersecurity and Infrastructure Security Agency (CISA). CISA issues Medical Advisory (ICSMA) advisories through ICS-CERT for significant medical device vulnerabilities. Healthcare organizations should monitor these advisories, as they may be the first notification that a deployed device has a known vulnerability requiring compensating controls.
Risk Tiering
Not all medical devices represent equivalent risk. A networked pill dispenser is a different patient safety risk than a networked infusion pump delivering chemotherapy. Risk tiering for medical devices should consider: whether the device can directly affect a clinical outcome (drug delivery, mechanical life support, implanted function), whether the device operates autonomously without continuous clinical supervision, the network connectivity model (wired clinical network vs. wireless vs. Bluetooth), the age and software vintage of the device, and the vendor's track record of issuing security updates.
High-risk devices (those that can directly affect patient physiology) warrant more aggressive compensating controls, more frequent monitoring review, and priority replacement planning. Lower-risk devices can be addressed through standard segmentation and monitoring controls.
CDA's Vulnerability and Surface Defense (VSD) domain applies its Continuous Surface Reduction (CSR) methodology to medical device environments with one critical adaptation: "eliminating" a surface sometimes means compensating controls rather than remediation, because remediation may not be technically or regulatorily available. CSR in healthcare contexts prioritizes: removing unnecessary network connectivity (devices that do not require internet access should not have it), closing unused management ports at the firewall level, and enforcing least-privilege network access so that each device class can only reach the specific systems it needs to function clinically.
The patient safety dimension elevates medical device security to a risk tier where CSR surface reduction is not discretionary. An organization that accepts uncontrolled network access for legacy infusion pumps is not making a risk-acceptance decision in the conventional IT sense; it is making a patient safety decision. CDA's assessment frameworks for healthcare clients reflect this: medical device network exposure is treated with the same analytical rigor as critical infrastructure.
The Security Posture and Hygiene (SPH) domain's Autonomous Posture Command (APC) provides continuous monitoring of the medical device network environment, including detection of new unregistered devices connecting to clinical VLANs, anomalous traffic patterns from known devices, and segmentation control integrity. Posture reviews for healthcare clients specifically verify that medical device VLAN segmentation rules have not been modified, that vendor remote access paths are controlled, and that the medical device inventory reflects the actual device population.