In our projects with medical device manufacturers, the topic of IT security has increasingly moved into focus in recent years. Many manufacturers face the challenge that Notified Bodies require concrete evidence of information security as part of the conformity assessment.
The reason for this lies in the advancing digitalization of medical technology. Hardly any modern medical device can do without cloud backends, mobile control apps for iOS/Android, or Bluetooth Low Energy (BLE) interfaces. Pure Software as a Medical Device (SaMD) is also playing an increasingly important role. However, with each of these components, the attack surface grows, making a systematic assessment of IT security necessary.
Legal Basis
In Annex I, for “devices that incorporate electronic programmable systems and software that are devices in themselves”, the MDR requires verification and validation under point 17.2 that the product or software was developed according to the state of the art – from the perspective of the IT security:
For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.
REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 5 April 2017
In the Medical Device Coordination Group Document “MDCG 2019-16 Guidance on Cybersecurity for medical devices” there is now the requirement of penetration testing as a specification of the previous verification and validation requirement:
MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require for devices that incorporate software or for software that are devices in themselves, that the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of the development life cycle, risk management, including information security, verification and validation. The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing. Additional security testing can be one by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues.
Medical Device Coordination Group Document, MDCG 2019-16
Scope Definition and Alignment with Risk Analysis
During the scoping phase, we frequently observe two distinct issues in practice:
- Overly narrow scope: Potentially relevant interfaces (such as cloud APIs or physical maintenance interfaces) are excluded to save time and effort. While this may seem convenient initially, it often leads to critical inquiries from Notified Bodies and delays during the approval process.
- Excessively broad scope: Attempts are made to test every theoretically conceivable vector—regardless of how realistic the threat scenario actually is for the specific product.
In our experience, it is crucial to align the scope of an MDR penetration test closely with the manufacturer’s own risk analysis and to follow a pragmatic approach.
Practical Example: For a medical device intended exclusively for home use (“home-only”), the threat landscape differs significantly from that of a device in a hospital network. It is generally disproportionate to spend days testing whether an attacker on-site could physically manipulate a local BLE connection if that same attacker could potentially access far more data or cause greater damage through inadequately protected backend APIs or app interfaces.
The testing focus should therefore rest on attack vectors that present a realistic risk to patient safety or data privacy.
Conclusion
A penetration test within the context of the MDR serves its purpose best when the scope is defined on the basis of a realistic risk analysis. In this way, manufacturers obtain solid documentation for their conformity assessment while ensuring that the actual risks of the product are adequately addressed.
The core questions for a penetration test of a medical device or SaMD typically revolve around:
- Can patient health be negatively impacted by manipulating the device, its software, or its configuration?
- Can measurement data, medical data, calculations, diagnoses, or therapy recommendations be manipulated in a way that leads to patient harm due to incorrect or omitted treatment?
- Can the availability of the device or software be compromised to the extent that a necessary diagnosis, monitoring, or treatment is delayed or prevented?
- Are patient health data adequately protected in storage, processing, and transmission in accordance with the state of the art?
