Back to Insights
Cybersecurity June 2025 9 min read

Medical Device Security: Managing Risk in Connected Healthcare Environments

Connected medical devices expand the hospital attack surface in ways traditional IT security programmes are not built to address. Here is how to manage that risk.

The internet of medical things (IoMT) has transformed clinical care. Infusion pumps communicate dosing data to EHR systems. Patient monitors stream vitals to central nursing stations. Ventilators, imaging equipment, surgical robots, and diagnostic analysers are all network-connected, often operating continuously and sometimes managing life-critical functions. This connectivity improves clinical efficiency and enables new models of care — but it also expands the hospital attack surface in ways that traditional IT security programmes are not designed to address.

The IoMT Attack Surface

A typical acute-care hospital may have thousands of connected medical devices. Many were not designed with security as a primary consideration. They run embedded operating systems, often versions of Windows that are years or decades past end-of-support. They communicate using protocols originally designed for closed clinical networks. They may store patient data locally. And they are physically distributed across wards, theatres, imaging departments, and corridors — not confined to controlled server rooms.

The challenge is not simply technical. Responsibility for medical devices in most healthcare organisations is split between clinical engineering teams, IT departments, and vendor-managed service arrangements. Devices are often not included in standard IT asset management systems. Security teams frequently have limited visibility into what devices are on the network, what operating systems they run, or what vulnerabilities they carry.

Why Medical Devices Are Difficult to Secure

Legacy Operating Systems

Many medical devices run versions of Windows XP, Windows 7, or other end-of-life operating systems that no longer receive security patches from Microsoft. Device manufacturers may not have developed patches for these devices, or may have prohibited modification of device software as a condition of regulatory approval. This means vulnerabilities in the underlying OS cannot be remediated through standard patching.

Vendor Constraints and FDA Considerations

Medical devices in most markets are regulated products. In the United States, changes to device software can require FDA review. Manufacturers are understandably cautious about changes that could affect device certification or regulatory status. This creates tension between security best practice and the regulatory framework governing device modification.

The FDA has increasingly recognised this tension. Its 2023 final guidance on cybersecurity for medical devices sets clear expectations for manufacturers, but the large installed base of older devices predates these requirements and will remain in clinical use for years.

Operational Constraints

Medical devices often run continuously. Unlike a workstation that can be rebooted for a patch, a device managing a patient's medication delivery or monitoring a patient's cardiac rhythm cannot simply be taken offline for maintenance during operational hours. Maintenance windows for medical devices must be planned carefully in coordination with clinical teams.

Common Vulnerabilities

The most frequently identified vulnerabilities in medical devices include:

  • Default credentials — Many devices ship with default administrative usernames and passwords that are publicly known and rarely changed after deployment.
  • Unencrypted communications — Older devices may transmit patient data in cleartext over the network, enabling eavesdropping.
  • Outdated DICOM and HL7 implementations — Healthcare interoperability protocols have historically prioritised availability over security, and older implementations contain known weaknesses.
  • Exposed management interfaces — Web-based management consoles accessible from the general network without adequate authentication.
  • Hardcoded credentials — Credentials embedded in device firmware that cannot be changed without vendor intervention.

Device Inventory and Asset Management

Effective medical device security begins with visibility. You cannot protect what you cannot see. Building a comprehensive inventory of connected medical devices requires deploying passive network discovery tools specifically designed for healthcare environments — tools that can identify devices by their network behaviour without disrupting them, and that recognise healthcare-specific protocols.

The inventory should capture device type, manufacturer, model, firmware version, IP address, MAC address, clinical location, responsible department, and vendor support status. This data provides the foundation for risk prioritisation, network segmentation design, and vendor management.

Asset management for medical devices is not a one-time exercise. Devices are added, moved, and retired continuously. Integration between the biomedical engineering asset register and the IT security asset management system is an important operational goal.

Network Segmentation Strategies

Network segmentation is the most impactful control available for medical devices that cannot be patched. By placing medical devices on isolated network segments — with strict firewall rules controlling what traffic is permitted in and out — the potential impact of a compromised device is contained.

Segmentation design should reflect clinical function. Imaging devices that communicate with PACS servers have different connectivity requirements from infusion pumps that communicate with pharmacy systems. Segmentation should be granular enough to provide meaningful isolation without being so complex that it creates operational barriers.

Micro-segmentation — implemented through software-defined networking or firewall policy — can further restrict lateral movement between individual devices or device groups. East-west traffic monitoring within medical device segments can detect anomalous behaviour indicative of compromise.

Critically, the network architecture should ensure that medical device segments cannot initiate connections to clinical administrative systems or internet destinations beyond what is strictly required for clinical function.

Compensating Controls

For devices that cannot be patched and cannot be fully isolated, compensating controls reduce risk to an acceptable level:

  • Host-based firewalls on devices that support them, restricting unnecessary inbound connections.
  • Network-level intrusion detection monitoring device traffic for anomalous patterns.
  • Vulnerability scanning using passive or non-intrusive techniques appropriate for clinical devices — active scanning can disrupt some medical devices and must be coordinated carefully.
  • Vendor monitoring of remote access connections — ensuring that vendor remote access is controlled, logged, and session-limited rather than always-on.
  • Physical security controls limiting physical access to device management ports.

FDA Pre- and Post-Market Guidance

The FDA's 2023 cybersecurity guidance for medical devices establishes requirements for devices submitted for premarket review after March 2023. Manufacturers must now submit a software bill of materials (SBOM), demonstrate a vulnerability disclosure policy, and provide a software lifecycle plan covering security updates.

For the installed base of older devices, FDA's post-market guidance recommends that manufacturers implement coordinated vulnerability disclosure programmes and communicate actively with customers about known vulnerabilities and mitigations. Healthcare organisations should register for manufacturer security advisories and track the FDA's Medical Device Safety Action Plan.

Procurement Security Requirements

One of the most effective long-term interventions is incorporating security requirements into medical device procurement. Healthcare organisations should require vendors to provide SBOMs, document their patch release processes, commit to defined support lifecycles, and demonstrate compliance with relevant cybersecurity standards (such as IEC 62443 or NIST guidelines for IoT devices).

Contract terms should address what happens at end-of-support — whether the manufacturer will provide extended security updates, transition support, or a migration path to a supported successor product. Security requirements established at procurement are far more effective than attempting to retrofit security onto already-deployed devices.

FZ Consulting LLP works with healthcare organisations to assess, segment, and manage connected medical device risk. Contact our team to discuss a medical device security programme tailored to your clinical environment.