Penetration Testing for Medical Devices in the Context of the Medical Device Regulation

Introduction

The Medical Device Regulation (MDR) defines requirements for the safety of medical devices, particularly when they include software or are software-based themselves.

Annex I, Section 17.2 of the regulation requires that software must be developed and manufactured in accordance with the state of the art. In particular, the following aspects must be considered:

• Software lifecycle
• Information security
• Verification and validation

From an information security perspective, this means that manufacturers must demonstrate that their products are protected against relevant threats and operate securely.

Guidance on Cybersecurity for medical devices

The regulation itself does not specify concrete testing procedures. However, further clarification is provided by the document MDCG 2019-16 (Guidance on Cybersecurity for medical devices).

This document states that verification and validation should primarily be achieved through testing and explicitly lists several security testing methods:

• Security feature testing
• Fuzz testing
• Vulnerability scanning
• Penetration testing

Penetration testing is positioned as a method to simulate real-world attack scenarios and to practically verify the effectiveness of implemented security controls.

Practical Approach

Regulatory requirements define the objective but not a standardized methodology. In practice, penetration testing for medical devices strongly depends on the specific device and its operational context.

Medical devices often consist of complex systems, for example:

• Sensors and measurement devices
• Embedded systems (often based on Linux)
• Wireless communication such as Bluetooth, RFID, or Wi-Fi
• Backend systems such as server infrastructures, cloud services, or mobile applications

Due to this heterogeneity, each penetration test is an individual case. The specific approach is typically defined jointly with the manufacturer at the beginning of the engagement.

Typical guiding questions include:

• Can a patient’s health be negatively impacted through direct manipulation of the device?
• Can measurement data be manipulated, leading to incorrect medical decisions?
• Are patient health data adequately protected across the entire processing chain?

From these questions, typical testing areas and attack vectors emerge:

• Analysis of wireless communication interfaces
• Physical access and device teardown to identify internal interfaces (e.g., JTAG, UART)
• Examination of embedded systems and firmware
• Analysis of backend systems, including web applications and APIs

The objective is to simulate realistic attack scenarios across the entire technical architecture and evaluate their impact on patient safety and data protection.

Relevance for Manufacturers

For manufacturers of medical devices, penetration testing is a suitable method to support regulatory requirements. It is particularly used to validate security controls in practice, assess risks in a traceable manner, and strengthen compliance evidence.

Penetration testing is therefore not explicitly mandated by name within the MDR, but it is considered a relevant and recommended method in the context of the required verification and validation.

In practice, notified bodies responsible for conformity assessment typically require evidence of security testing. Penetration testing is often expected, especially for software-based or connected medical devices, as it provides a practical demonstration of resilience against realistic attack scenarios.