Cybersecurity in Connected Medical Devices

According to ENISA, the healthcare sector is the most affected by significant cybersecurity incidents in Europe for four consecutive years (2020–2023), with ransomware accounting for 54% of cyberattacks on the sector and 45% of health-related incidents analysed in 2024. And within the sector, connected medical devices are the most exploited entry vector: outdated firmware, unchanged factory credentials, unencrypted communications and hospital networks that mix clinical and administrative traffic without segmentation.

The result is an ecosystem where a connected pacemaker, infusion pump or diagnostic imaging system can become the entry point to a hospital’s entire network.

This article analyses what makes connected medical devices particularly vulnerable, what the European regulatory framework requires of manufacturers and healthcare operators, and which technical and organisational controls reduce risk in a demonstrable way.

What Are Connected Medical Devices and Why Are They a Priority Target?

The term IoMT (Internet of Medical Things) covers all healthcare devices with network connectivity: vital signs monitors, PACS and DICOM diagnostic imaging systems, smart ventilators, insulin and medication pumps, implantable pacemakers and defibrillators with telemetry, cloud-synced glucometers, radiation administration systems and laboratory equipment connected to LIS/HIS systems.

What makes them attractive to attackers is a combination of factors that is difficult to replicate in other sectors. Lifecycles of 10 to 20 years mean manufacturers cannot update software without re-running the MDR certification process. Hospital networks have historically not been designed with segmentation, so a compromised device has lateral visibility to critical systems. And the data they handle, medical records, health data as a special category under GDPR, commands a far higher price on the black market than financial data.

The 2020 attack on the Düsseldorf hospital, which resulted in the death of a patient diverted to another centre after systems were encrypted, marked the turning point in the European regulatory perception of the sector. Since then, NIS2 and the cybersecurity requirements already embedded in the original MDR (EU) 2017/745 have received far more demanding practical application from authorities and notified bodies.

Main Threats in the IoMT Ecosystem

Ransomware Targeting Hospital Infrastructure

Ransomware groups have identified the healthcare sector as a high-yield target: the operational pressure on hospitals makes them more likely to pay to restore access quickly. Connected medical devices are frequently the initial vector because they run outdated operating systems (Windows XP, Windows 7) that cannot be patched without revalidating device certification, and because they are connected to the same network as clinical record systems.

Unpatched Firmware Vulnerabilities

Most connected medical devices have firmware update cycles that depend on the manufacturer, not the healthcare operator. When the manufacturer stops supporting a model, the device is frozen on a software version with known vulnerabilities. ENISA has documented that more than 40% of connected medical devices in use in European hospitals have unpatched vulnerabilities with published CVEs.

Unencrypted Communications in Legacy Protocols

Protocols such as HL7 v2, DICOM without TLS or older Bluetooth LE versions transmit patient data in plain text or with trivial authentication mechanisms. An attacker on the same wireless network can intercept real-time monitoring data or, in the case of implantable devices with telemetry, modify operating parameters within the physical range of the device.

Unmanaged Third-Party Access

Manufacturers and maintenance providers access devices remotely for diagnostics and updates, frequently using shared credentials or VPN connections without MFA. This third-party access is rarely actively audited by the hospital, and it is a common vector for initial intrusion.

Unhardened Factory Configurations

Devices are delivered with default credentials, open administration ports and configurations designed to ease installation, not to minimise the attack surface. The hardening process specific to medical devices is not standardised or systematically required, and many hospital IT teams lack the clinical knowledge to modify configurations without affecting functionality.

Applicable European Regulatory Framework

The Medical Device Regulation (MDR)

Regulation (EU) 2017/745 on medical devices (MDR), in full application since May 2021, requires that devices with software or connected functions incorporate security measures by design from the outset. Annex I of the MDR establishes that manufacturers must minimise risks arising from connection to other devices or networks, implement authentication, access controls and data integrity protection, and ensure that software can be updated securely. The MDCG 2019-16 guidance from the European Commission develops these requirements with specific technical criteria for cybersecurity in the device lifecycle.

NIS2 and the Healthcare Sector as an Essential Entity

The NIS2 Directive classifies hospitals, diagnostic centres and manufacturers of critical medical devices as essential entities, carrying the most demanding obligations of the directive: documented risk management, incident notification within 24 hours for early warnings and 72 hours for formal notification, supply chain security measures (including device manufacturers) and direct liability of senior management. For detail on what this means in Spain, the article on NIS2 in Spain covers the specific obligations for the sector.

GDPR and Special Category Data

Health data is special category data under Article 9 of GDPR, raising the required level of protection and the consequences of a breach. A patient data leak caused by a compromised medical device can result in fines of up to 4% of global turnover, and supervisory authority doctrine in recent years has significantly tightened the standard for insufficient security measures in the healthcare sector. For how to implement GDPR operationally in this context, it may be useful to consult how to implement GDPR in organisations with sensitive data.

ISO 14971 and Risk Management in the Device Lifecycle

ISO 14971 is the international standard for risk management in medical devices, required by the MDR and adopted as a harmonised EU standard. It defines the systematic process of risk identification, estimation, evaluation and control, including since the 2019 version an explicit extension to cybersecurity risks (IEC TR 80002-1). For manufacturers, the absence of a process conforming to ISO 14971 blocks CE marking. For healthcare operators, risk management under ISO 14971 provides the framework for documenting decisions about third-party devices on their network.

Applicable Technical Standards

Beyond the regulatory framework, there are technical standards that provide the specific controls to protect connected medical devices.

IEC 62443 is the cybersecurity standard for industrial automation and control systems, widely adopted in the healthcare sector for protecting hospital networks that include medical devices. It defines security levels (SL1 to SL4) and establishes requirements for manufacturers (IEC 62443-4-1 and 4-2) and operators (IEC 62443-2-1 and 3-3).

ISO/IEC 80001-1 addresses specifically risk management for IT networks that incorporate medical devices, with a focus on shared responsibility between the device manufacturer and the network operator.

ISO 27001 as an information security management framework provides the organisational structure for managing hospital cybersecurity systematically. The ISO 27001 guide in PDF format is a good starting point for understanding the scope of the standard before beginning an implementation.

Priority Technical and Organisational Controls

Asset Inventory and Continuous Visibility

Without an up-to-date inventory of connected medical devices on the network, no cybersecurity programme is operational. The inventory must include manufacturer, model, firmware version, operating system, communication protocols, date of last patch and manufacturer support status. IoT-specific tools such as Claroty, Medigate or Asimily can automate discovery and monitoring.

Clinical Network Segmentation

Segregating medical device traffic from administrative traffic and internet access is the most effective containment measure for limiting lateral movement in the event of a compromise. An infected device in a segmented VLAN with a default-deny policy cannot propagate ransomware to the clinical record system. This segmentation must also cover firmware update traffic and manufacturer remote access.

Lifecycle Management and End-of-Support Policy

The healthcare organisation needs an explicit policy for devices whose manufacturer has stopped providing security updates. The options are: compensating the risk with additional network controls (strict isolation, intensive monitoring), contractually requiring the manufacturer to extend security support, or planning early device replacement with a documented clinical risk justification.

Third-Party Access Management

Every remote access by a manufacturer or maintenance provider must be logged, pre-authorised, time- and scope-limited and audited. The use of shared credentials must be eliminated. The minimum standard is MFA for remote access and SIEM logging of all privileged access sessions.

Documented Risk Assessment

A structured risk assessment reviewed annually is the documentary basis for demonstrating due diligence before the supervisory authority, NIS2 auditors and healthcare inspection bodies. Without that documentation, the organisation cannot demonstrate that it has made informed decisions about the risks it accepts with its connected device ecosystem.

The Chain of Responsibility: Manufacturer and Healthcare Operator

The MDR and NIS2 establish a shared responsibility chain that generates frequent practical friction.

The manufacturer is responsible for designing the device with cybersecurity by default per Annex I of the MDR, providing technical security documentation for CE marking, notifying known vulnerabilities and maintaining a secure update process throughout the expected product lifecycle.

The healthcare operator, whether a hospital, clinic or primary care network, is responsible for configuring and maintaining devices securely in their specific environment, managing access to them, monitoring their network behaviour and notifying incidents affecting their operation under NIS2.

When the manufacturer stops providing support, responsibility falls entirely on the operator. The most common friction is that the manufacturer’s responsibilities end where the operator’s begin, and that boundary is not always well defined in procurement contracts. Establishing it contractually before device installation is a preventive measure that few centres apply systematically.

How PrivaLex Can Help

PrivaLex supports both medical device manufacturers and healthcare operators in implementing the cybersecurity controls required by the MDR, NIS2 and GDPR.

For manufacturers, the work covers gap analysis against MDR requirements and MDCG 2019-16 guidance, integration of cybersecurity into the design process in line with ISO 14971, and the technical documentation required for CE marking with connected functions.

For healthcare operators, the work covers assessment of the connected medical device ecosystem, definition of network segmentation and third-party access policies, preparation of the risk assessment required by NIS2, and support in incident response involving medical devices.

Conclusion

Cybersecurity in connected medical devices is not a technical problem to solve once: it is a continuous programme that requires an up-to-date inventory, active segmentation, lifecycle management, third-party controls and a living risk assessment.

The European regulatory framework, with the MDR, NIS2 and GDPR as pillars, already requires those controls explicitly from both manufacturers and healthcare operators. The question is not whether to act, but when and with what level of maturity.

If you want to know what gaps your organisation has in the protection of connected medical devices, request your free risk assessment. If you already have a defined scope, book a session with our team.

Frequently Asked Questions