OT Security in Healthcare: Medical Device Protection

What Does the FDA Require for Medical Device Cybersecurity?

The FDA's December 2023 guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," represents the most significant regulatory development in medical device cybersecurity. Under the Omnibus Consolidated Appropriations Act of 2023, the FDA can now refuse medical device submissions that do not include adequate cybersecurity documentation. This requirement applies to devices that contain software or that are software-based, covering the vast majority of connected medical devices submitted for premarket clearance or approval.

Required documentation includes a software bill of materials (SBOM) listing all commercial, open-source, and off-the-shelf software components; documentation of the device's security architecture; identification of known vulnerabilities in software components; a cybersecurity risk assessment; plans for monitoring and responding to post-market cybersecurity vulnerabilities; and a patch management plan covering the expected device lifetime. These requirements reflect the FDA's recognition that cybersecurity must be designed into medical devices, not addressed retrospectively after clinical deployment.

Post-market requirements are equally important. Medical device manufacturers must monitor their devices for cybersecurity vulnerabilities after deployment, communicate with customers about significant vulnerabilities, and provide patches or workarounds in a timeframe proportional to the risk. The Medical Device Reporting (MDR) requirements may apply to cybersecurity incidents if they constitute a malfunction that could cause serious injury. Healthcare providers receiving devices from manufacturers must understand these post-market obligations and factor them into their vendor management processes.

IT vs OT security - why medical devices need different security approaches

How Should Healthcare Organizations Segment Clinical Networks?

Clinical network segmentation must separate medical devices from administrative IT systems to prevent attacks that originate in the administrative network from reaching patient care devices. This segmentation mirrors the Purdue Model approach used in industrial OT: a DMZ architecture with explicit, controlled communication paths between clinical device networks and hospital IT networks. Data flows, such as patient monitoring data to electronic health record systems, must pass through these controlled paths rather than via direct network connections.

Medical device network zones should be organized by device category and risk level. Infusion pumps, ventilators, and other life-sustaining devices belong in the highest-criticality zone, with the most restrictive network access controls. Imaging systems may share a zone with PACS servers and RIS (radiology information system) interfaces. Non-critical administrative devices, like barcode scanners and nurse call systems, should be in lower-criticality zones. Each zone requires explicit conduit definitions for inter-zone communication.

VLAN-based segmentation is the most common implementation approach in healthcare. Medical device VLANs restrict lateral movement: a compromised device on the infusion pump VLAN cannot directly reach a device on the imaging system VLAN without crossing a firewall that enforces explicit permit rules. Firewall rules for medical device zones must be defined by clinical informaticists who understand the communication requirements of each device category, not by IT security teams alone. Clinical knowledge is essential for distinguishing necessary from unnecessary network communication in medical device environments.

[IMAGE: Diagram of clinical network segmentation showing medical device zones, PACS zone, and administrative IT network with DMZ - search terms: clinical network segmentation medical device zones hospital IT architecture]

How Do You Manage Legacy Medical Devices with Unsupported Software?

Legacy medical devices running unsupported operating systems are the most intractable OT security challenge in healthcare. A 2024 Forescout study found that 80% of healthcare organizations had devices running Windows 7 or older operating systems. Many of these devices cannot be updated because their clinical applications are FDA-cleared on specific software versions: updating the operating system would require re-clearance, which manufacturers may not pursue for older device models. The security risk is real and cannot be remediated through patching; it must be managed through compensating controls.

The compensating control framework for legacy medical devices mirrors the approach used for legacy industrial OT. Network isolation prevents attackers from reaching vulnerable devices: a device that cannot be reached cannot be exploited. Application whitelisting prevents unauthorized software from executing on devices that support it. Protocol-level filtering blocks network communication that the device should not participate in. Enhanced monitoring detects anomalous access attempts and communications that might indicate exploitation. These controls collectively reduce exploitability without touching the device or its clinical software.

Device replacement planning must account for both clinical and security timelines. A medical device scheduled for clinical replacement in three years can be managed through compensating controls for that period. A device with no replacement in sight requires either compensating controls in perpetuity or a business case for early replacement based on accumulated security risk. Healthcare security teams should work with biomedical engineering departments to integrate cybersecurity considerations into device lifecycle planning and procurement specifications for replacement devices.

What Ransomware Threat Do Healthcare OT Systems Face?

Healthcare ransomware attacks have caused documented patient harm, not just operational disruption. A 2021 German court case examined a ransomware attack on Düsseldorf University Hospital, which caused the death of a patient who was diverted to a more distant facility during a critical care emergency. While causation in that case was complex, it illustrated the potential for healthcare ransomware to create patient safety incidents. Ransomware attacks on OT environments are growing 40% annually, and healthcare is among the most heavily targeted sectors.

Healthcare ransomware attacks increasingly target clinical systems specifically, knowing that hospitals cannot operate without electronic health records, clinical communications, and connected medical devices. Attackers have demonstrated knowledge of healthcare clinical workflows in the timing and targeting of their attacks. Some ransomware groups have announced policies of not targeting hospitals while continuing to do so, illustrating the gap between stated policy and actual behavior. Healthcare organizations should not rely on attacker restraint as a security control.

OT security best practices and 12 essential controls

How Do You Build a Healthcare OT Security Program?

Healthcare OT security programs must balance patient safety, clinical operations, end-to-end compliance risk, and cybersecurity in ways that purely technical programs do not. The starting point is a complete medical device inventory: every connected device, its software version, its network connections, its clinical function, and its criticality. Biomedical engineering departments often maintain portions of this inventory for clinical and maintenance purposes; cybersecurity teams must work with biomedical engineering to extend these records with security-relevant information.

Risk assessment must be consequence-driven, prioritizing devices where compromise has direct patient safety implications. Infusion pumps, ventilators, and patient monitoring systems rank highest on this consequence scale. Imaging and diagnostic systems rank high on operational impact. Administrative medical systems, like scheduling and registration, rank lower on patient safety consequence but may rank high on business continuity impact. This consequence-driven prioritization guides which controls receive the most investment and the fastest implementation timelines.

Governance structures for healthcare OT security must include clinical leadership, not just IT and security leadership. Clinical informaticists who understand medical device clinical workflows, biomedical engineers who maintain devices, nursing and physician informaticists who represent clinical user needs, and security professionals who understand the threat landscape must all contribute to program design and decision-making. Security controls that clinical staff find operationally impractical will be circumvented; clinical buy-in is a security requirement, not a soft consideration. For healthcare organizations building OT security programs that integrate clinical and security requirements, Opsio's OT security services provide sector-specific guidance and technical implementation support.

Frequently Asked Questions

Does HIPAA cover medical device cybersecurity?

HIPAA Security Rule requirements apply to electronic protected health information (ePHI) processed by medical devices. Devices that store, process, or transmit patient data must have appropriate technical, physical, and administrative safeguards. However, HIPAA does not specifically address the clinical safety dimensions of medical device cybersecurity that the FDA governs. Healthcare organizations must satisfy both HIPAA security requirements and FDA medical device cybersecurity guidance, which together cover both data privacy and clinical safety perspectives.

What is an SBOM and why does it matter for medical devices?

A software bill of materials (SBOM) is a formal inventory of all software components in a product, including open-source libraries, third-party components, and proprietary code. The FDA now requires SBOMs in premarket device submissions. SBOMs enable healthcare organizations and manufacturers to quickly identify whether a newly disclosed vulnerability affects their devices. When Log4Shell was disclosed in 2021, organizations with SBOMs could assess exposure in hours; those without them spent weeks manually investigating each product. SBOMs are becoming a standard supply chain transparency requirement across all connected product categories.

How do we handle cybersecurity for devices in use during an active incident?

Devices actively supporting patient care must not be taken offline for security response without clinical authorization. Pre-established incident response procedures should specify which devices can be isolated without clinical risk, which require physician authorization before isolation, and which must remain operational regardless of cybersecurity status. These decisions must be made in advance through a structured clinical-security governance process, not ad hoc during an active incident. Clinical informaticists should review and approve the clinical triage component of the cybersecurity incident response plan.

What should we require from medical device vendors for cybersecurity?

Require vendors to provide SBOMs for all devices before purchase. Require documented vulnerability disclosure and patch delivery processes with defined response timelines. Require manufacturer disclosure of the device's security architecture and known security limitations. Ask for reference customers who have deployed the device and assess its cybersecurity in practice. Require contractual commitments for security support throughout the planned device lifetime, not just the initial warranty period. These requirements are increasingly feasible as FDA premarket guidance raises the floor for what manufacturers must be able to demonstrate.

Conclusion

Healthcare OT security is uniquely demanding because its failure modes include patient safety consequences that go beyond operational or financial harm. The 500 million connected medical devices in US healthcare alone represent an OT attack surface that is only partially addressed by current security programs. The FDA's 2023 premarket guidance, healthcare ransomware's documented patient harm, and the 60% incident rate across all sectors define a threat environment that demands urgent, structured response.

Building effective healthcare OT security requires clinical-security collaboration, consequence-driven prioritization, and compensating controls for the legacy devices that cannot be patched. The investment required is justified by what is at stake: patient safety in an environment where cyber threats have already caused harm.

---

Author: Opsio Security Practice | Published: April 2026 | Last updated: April 2026