Medical Device Security
Reviewed by Fully Compliance editorial staff
Medical devices were designed for clinical safety, not cybersecurity. Many devices in active use run outdated operating systems, cannot receive security patches, and create network vulnerabilities you cannot easily mitigate through standard IT approaches. The primary defense is network segmentation that isolates vulnerable devices, combined with a complete device inventory, documented risk assessments for end-of-life equipment, and security criteria built into every new procurement decision.
Network Segmentation Is Your Primary Defense for Unpatchable Devices
Your medical devices were designed to save lives, not to be security masterpieces. The infusion pump from 2015 was tested for clinical safety but not for vulnerability to network attack. The ultrasound machine from 2012 runs Windows 7 with service packs, a configuration that modern security standards flag as catastrophically out-of-date. The cardiac monitor has no built-in ability to receive security patches. These devices create network risks you don't fully control and can't easily mitigate through standard cybersecurity approaches. The challenge is that you need the clinical functionality these devices provide, you can't pause healthcare to implement perfect security, and most medical device manufacturers are years behind in security maturity.
This is a constraint that separates healthcare security from IT security in other industries. In enterprise IT, you can often decommission old insecure systems and replace them with modern alternatives. In healthcare, a device is often clinically irreplaceable for the population you serve. It keeps working because patients depend on it. That clinical lock-in creates a specific security vulnerability: devices with known vulnerabilities that can't be patched become permanent fixtures in your network. According to Ponemon Institute research, 53% of connected medical devices in hospitals have known critical vulnerabilities, and the average healthcare organization has more than 26,000 network-connected devices. The FDA's 2023 guidance on cybersecurity in medical devices acknowledged this systemic problem by requiring premarket cybersecurity submissions for new devices, but that does nothing for the legacy equipment already in your facility.
Device Inventory and Connectivity Assessment
The first step is knowing what you actually have. This sounds obvious until you walk through a large healthcare facility and discover that nobody has a current list of connected medical devices. You find a patient monitor that's been moved between units three times and is connected to the network in a way that nobody documented. You find a PACS workstation running software that was installed a decade ago. You find devices on the network that nobody claims to own. This inventory problem is endemic in healthcare because clinical staff focus on what the device does, not on how it's networked.
Start with a comprehensive inventory of every connected medical device in your organization. What is it? When was it manufactured? What operating system does it run? How is it connected to your network? Does it need internet connectivity or just local network access? Who owns it clinically? Who's responsible for updating it? Is it still supported by the manufacturer? Many healthcare organizations do an initial inventory exercise and are shocked by what they find.
The next layer is understanding connectivity requirements. Not every medical device needs to be on the hospital network. Some can operate in complete isolation with local data transfer via USB or other physical media. Some need network connectivity for clinical workflows but don't need internet connectivity. Understanding the actual connectivity requirement versus the implemented connectivity is where you often find unnecessary risk. A device that's connected to the hospital network for no clinical reason — "it was just easier to plug it in" — represents pure risk with no benefit. If that device is compromised, it's a potential foothold into your network.
Vulnerable Device Management and Patching
The harsh reality is that many medical devices have known vulnerabilities that cannot be patched. The manufacturer stopped supporting the device years ago. The device is running Windows XP or Windows 7 because updating to a newer operating system would void the device's clinical certification. The device's software is embedded in firmware and there's no mechanism for updates. These devices represent a specific security category: old, vulnerable, unpatchable, and often irreplaceable.
The standard IT response to vulnerable devices is to patch them. That option often doesn't exist in healthcare. Instead, the approach is risk mitigation: putting controls in place to reduce the probability that the vulnerability will be exploited. The primary mitigation is network segmentation — isolating the vulnerable device from the general network so that a compromise doesn't give an attacker access to other systems.
For devices that do have patching capability, the patching process needs to be managed carefully. Unlike desktop patches that often get deployed automatically, medical device patches are frequently manual and require coordination with clinical staff because applying a patch requires the device to be temporarily offline. You need to understand the device's downtime tolerance. Some devices can be patched during scheduled maintenance windows. Others are in active clinical use and can't be taken offline. The decision about whether to patch a vulnerable medical device requires weighing the risk of the known vulnerability against the risk of the patch itself — a patch that introduces instability to a critical medical device is worse than living with the known vulnerability.
Network Segmentation and Isolation
Network segmentation is the primary control for medical devices because it limits what an attacker can reach if they compromise a device. The simplest segmentation approach is VLAN segregation — putting medical devices on a separate virtual network that's restricted from the general hospital network. A compromised patient monitor on a medical device VLAN can't directly access workstations, servers, or other infrastructure on the general network.
More sophisticated segmentation uses microsegmentation where different types of devices are further isolated — cardiology devices on one segment, imaging devices on another, infusion pumps on another. Each segment has restricted rules about what traffic can flow between them. An attacker who compromises a patient monitor in the cardiology segment can't automatically access imaging devices in the imaging segment.
The practical challenge is that some medical devices genuinely need to communicate with other systems. A device that sends data to the EHR, a monitoring system that collects telemetry from multiple devices, or a central station that aggregates data from bedside monitors all require cross-segment communication. The segmentation approach is to allow those specific flows while blocking everything else. Only the traffic that's required for clinical functionality is permitted; all other traffic is denied by default.
Implementation requires network infrastructure support — switches and routers that support VLANs and access control lists, firewalls that can enforce rules between segments, and monitoring to verify that the segmentation is actually in place and functioning. Many healthcare organizations start segmentation projects and discover that their network infrastructure is older than they thought and needs upgrades to support it. Testing segmentation is critical because misconfigured rules create either false security or broken clinical workflows.
Managing End-of-Life and Unsupported Devices
Many healthcare organizations have medical devices in active clinical use that the manufacturer no longer supports. The manufacturer won't provide patches, won't provide technical support, and may actively discourage use of the device because of liability concerns. These devices represent the highest-risk category because they combine age, vulnerability, and the inability to get help from the manufacturer.
The treatment for end-of-life devices is either replacement or decommissioning. Replacement is expensive and disruptive. Decommissioning means you can't use the device anymore. Neither option is attractive when the device is clinically important. This is where prioritization matters. Some end-of-life devices are low-clinical-value and decommissioning them is straightforward. Other devices are clinically important but replaceable — you budget for replacement and plan the transition. Still other devices are clinically important and seemingly irreplaceable — those require intensive network segmentation and monitoring because living with the risk is the only option.
Every end-of-life device in your environment should be documented with its risk profile, its mitigation strategy, and the plan for eventual replacement. This documentation ensures that key people understand why you're accepting the risk, it creates accountability if something goes wrong, and it drives replacement planning and budgeting. A device that's in isolation on a dedicated network segment with no patient data is a different risk profile than a device that's connected to the general network and sends data to the EHR.
Manufacturer Evaluation and Procurement Security
Modern medical devices are increasingly connected and increasingly subject to security vulnerabilities. Responsible manufacturers have security practices that include regular patch releases, security advisories, and vulnerability disclosure processes. When selecting new medical devices, security practices should be an evaluation criterion alongside clinical functionality and cost.
Questions to ask manufacturers: Do you have a documented security update process? How quickly do you patch critical vulnerabilities? Do you maintain security advisories for your products? How long is the support window for each device? What's your process for handling responsibly disclosed vulnerabilities? Do you require authentication for remote access? Can you disable unnecessary network services? Can you provide evidence of security testing?
The economic reality is that security investments cost money and manufacturers sometimes cut security investment to maintain margins. A slightly more expensive device with better security infrastructure saves money in the long run because it doesn't consume as much time for security management and has a longer useful life. The purchasing process for new medical devices should include security criteria in the RFP, and procurement should negotiate for security features that matter to your organization: the ability to disable unnecessary network services, the ability to configure network access controls, the availability of security updates, and vendor liability for security vulnerabilities.
Replacement of older devices should be driven by a combination of clinical obsolescence and security risk. A device that's clinically adequate but running Windows 7 with no patching capability should be on a replacement roadmap even if it's not broken. The budget process should include a medical device refresh cycle that takes into account aging devices and security risk.
Balancing Security with Clinical Functionality
Medical device security creates genuine tension with clinical usability. Restricting network connectivity improves security but disables remote monitoring. Requiring authentication improves security but slows down emergency access. Applying updates improves security but requires downtime that impacts care delivery. This tension is real and shouldn't be pretended away.
The balance requires ongoing conversation between clinical teams who understand the workflow and security teams who understand the risk. The conversations should be specific and grounded in actual risk. A patient monitor that's in a locked recovery room and never leaves the facility has different security requirements than a portable monitor that moves between units. An infusion pump connected to a medical device network requires different controls than one that operates entirely offline. A device used in an operating room during active surgery has different downtime tolerance than a monitoring device used on a general floor.
Physical security matters alongside network security. Physical access to a device can enable tampering, unauthorized modification, or firmware replacement. Devices that contain or process sensitive information should be in secured areas where only authorized personnel can access them. For portable devices like wireless patient monitors or portable ultrasound machines, controls include password protection, encryption of stored data, and logging of access.
The test of your medical device security program is whether it's actually reducing risk without making healthcare impossible. If you've segmented devices so heavily that they can't communicate with the EHR, the security is theoretical. If you've locked down access so completely that staff can't use the device in emergencies, the security is counterproductive. The goal is reasonable security for your actual environment and your actual threat profile.
Frequently Asked Questions
What percentage of medical devices have known security vulnerabilities?
Ponemon Institute research found that 53% of connected medical devices in hospitals have known critical vulnerabilities. The problem is widespread because many devices were designed before cybersecurity was a design consideration, and manufacturers often stop providing security updates well before the device reaches the end of its clinical useful life.
Can we patch medical devices the same way we patch regular IT systems?
Usually not. Medical device patches are often manual, require coordination with clinical staff for downtime, and may need manufacturer involvement. Updating the operating system can void the device's clinical certification. Each patch decision requires weighing the security risk of the known vulnerability against the operational risk of patching, including potential instability.
What is network segmentation and why is it the primary control for medical devices?
Network segmentation places medical devices on separate virtual networks (VLANs) isolated from the general hospital network. If an attacker compromises a device on the medical device segment, they cannot directly access workstations, servers, or the EHR on the general network. Segmentation is the primary control because many devices cannot be patched, making isolation the most effective way to limit the damage from a compromise.
How should we handle a medical device the manufacturer no longer supports?
Document the device with its risk profile, known vulnerabilities, and mitigation strategy. Place it on an isolated network segment with restricted traffic rules. Monitor it for anomalous behavior. Develop a replacement timeline and include replacement costs in your capital budget. If the device processes patient data and cannot be adequately isolated, replacement should be prioritized.
What security questions should we ask when purchasing new medical devices?
Ask about the manufacturer's security update process and patch timeline for critical vulnerabilities, the support window for the device, authentication requirements for remote access, the ability to disable unnecessary network services, evidence of third-party security testing, and firmware version documentation. Include these criteria in your RFP and negotiate security commitments as part of the purchase agreement.
Does the FDA require cybersecurity for medical devices?
The FDA's 2023 guidance requires premarket cybersecurity submissions for new medical devices, including a software bill of materials, vulnerability assessment, and a plan for security updates throughout the device's lifecycle. This applies to new devices seeking FDA clearance. It does not retroactively apply to devices already on the market, which is why legacy device security remains an organizational responsibility.