The healthcare sector operates some of the most complex and security-challenged operational technology environments in any industry. A large hospital network simultaneously runs clinical engineering equipment (MRI scanners, CT systems, infusion pumps, ventilators), building automation systems, and IT infrastructure — all connected to networks originally designed for clinical function rather than security. The consequence: ransomware groups have found that medical device networks offer both lateral movement pathways and the highest-leverage coercion available, because the alternative to paying is disrupted patient care.
The FDA’s 2023 cybersecurity requirements for medical devices, fully in force by 2024, have begun changing how new devices enter healthcare networks. But the installed base — medical devices with 10–20 year lifespans running Windows XP, Windows 7, or embedded Linux kernels patched years ago — represents a security debt that regulations cannot quickly resolve.
The IoMT Attack Surface
Internet of Medical Things (IoMT) devices encompass a wide range of equipment that connects to hospital networks:
Imaging systems — CT scanners, MRI machines, PET scanners, X-ray systems, and fluoroscopy equipment. These are typically managed by dedicated workstations running Windows, often unpatched due to vendor support constraints. Many require direct internet connectivity for remote vendor diagnostics.
Patient monitoring — bedside monitors, central station systems, telemetry equipment. These devices generate continuous patient data and must remain available during care delivery — creating pressure against patching or maintenance windows that require downtime.
Infusion systems — IV pumps and smart infusion devices. Several documented vulnerabilities in infusion pump systems have demonstrated potential for an attacker to alter drug delivery parameters if they gain network access, making these devices a patient safety concern as well as a cybersecurity one.
Laboratory and diagnostic equipment — blood analysers, pathology systems, sequencing equipment. These often run proprietary operating systems or embedded Linux with minimal security tooling available.
Building and facility systems — HVAC, physical access control, and emergency power systems. In healthcare environments, HVAC control affects clean room and operating theatre conditions; disruption has direct patient care implications.
The common thread: devices that were procured and installed when cybersecurity requirements were minimal, running operating systems that vendors no longer update, on networks where segmentation was rarely a design consideration.
FDA Cybersecurity Requirements
The FDA’s Final Guidance on Cybersecurity in Medical Devices (December 2023) requires manufacturers of new devices to:
- Submit a Software Bill of Materials (SBOM) as part of premarket submissions, listing all commercial, open-source, and off-the-shelf software components
- Establish a coordinated vulnerability disclosure process with a stated response timeline
- Design for update capability — the device must be patchable within a reasonable timeframe of a vulnerability being identified
- Provide a plan for monitoring, identifying, and addressing post-market cybersecurity vulnerabilities throughout the expected device lifetime
For healthcare delivery organisations, the practical impact of SBOM requirements is that new devices acquired after 2024 come with a documented component list that security teams can actually use to assess exposure when new CVEs are published. For the installed base that predates this requirement, SBOM data is often unavailable, making exposure assessment depend on vulnerability databases and vendor advisories of variable quality.
The FDA does not mandate specific technical security controls for installed devices — that responsibility sits with healthcare organisations and their vendors through service agreements.
Current Threat Landscape
Ransomware has become the dominant cybersecurity threat to healthcare OT. Groups including LockBit affiliates, BlackSuit (formerly Royal), and Scattered Spider have explicitly targeted hospitals, with attacks that disabled clinical systems, electronic health records, and medical devices simultaneously.
The attack pathway in documented healthcare ransomware incidents follows a consistent pattern: initial access via phishing or exploitation of internet-facing systems (VPN, remote access portals, EHR vendor systems), lateral movement through clinical networks that lack segmentation between IT and medical device networks, then simultaneous encryption of IT systems and whatever medical devices are reachable.
Medical devices amplify ransomware leverage in several ways. Patient monitoring systems going offline during active patient care creates immediate clinical risk. Imaging systems becoming unavailable blocks diagnostic capability. The combination turns a ransomware event from a data recovery problem into a patient safety event, dramatically increasing the pressure to pay.
Iranian state-sponsored actors and Chinese APT groups have also been documented conducting reconnaissance against healthcare OT networks, consistent with pre-positioning activity rather than immediate disruption intent.
Network Segmentation Approaches
The Purdue Model applied to healthcare creates a hierarchy that most hospital networks have never implemented:
Level 0 (Medical devices): The devices themselves — pumps, monitors, imaging equipment. These should communicate only with their associated Level 1 systems.
Level 1 (Clinical management systems): Device management workstations, central monitoring stations, PACS servers. These should be isolated from general hospital IT networks.
Level 2 (Site operations): Clinical information systems that aggregate device data — EMR integration, clinical dashboards. This layer is where clinical IT meets OT.
Level 3 (Enterprise): General hospital IT — email, administrative systems, internet access. This is the primary attack surface from ransomware initial access, and should be segmented from Levels 0–2.
DMZ: Any system requiring external connectivity (vendor remote access, telehealth) should terminate in a DMZ rather than directly connecting to clinical networks.
Practical segmentation in healthcare is more complex than this model suggests. Clinicians need data to flow between systems; hard segmentation breaks clinical workflows. The realistic implementation is micro-segmentation that allows specific, documented data flows between segments while blocking lateral movement pathways that ransomware uses.
Vendor Remote Access: The Persistent Gap
Medical device vendors require remote access for diagnostics, maintenance, and software updates. This access is often implemented as persistent VPN connections maintained by the vendor rather than on-demand access initiated by the healthcare organisation. These connections represent a persistent internet pathway into clinical networks that bypasses most perimeter controls.
Best practice is to replace persistent vendor VPN connections with session-based remote access tools that are initiated on demand by the healthcare organisation and terminated after each session, with all activity logged. Privileged Access Management (PAM) platforms designed for OT vendor access (Claroty SRA, Cyberark, BeyondTrust) provide this capability while maintaining the audit trail required for compliance.
Incident Response Considerations for Healthcare OT
Medical device incidents require clinical and IT coordination that standard incident response playbooks don’t address. Security teams should work with clinical engineering and clinical leadership to establish:
- Which devices can be isolated from the network without disrupting patient care
- Manual backup procedures for devices that may need to be disconnected
- Communication protocols between security operations, clinical engineering, and clinical leadership during an incident
- Relationships with device vendors for emergency support
The NHS’s experience with WannaCry in 2017 — which took MRI scanners, CT scanners, and patient monitoring equipment offline across multiple trusts simultaneously — remains the reference case. Healthcare organisations that have not run tabletop exercises simulating medical device compromise are operating without a tested response plan for what is now a predictable threat scenario.