1. Preliminary Remarks
- This document was prepared by the German Notified Bodies Alliance (“Interessengemeinschaft der Benannten Stellen für Medizinprodukte in Deutschland”, IG-NB) as a guide for Notified Bodies, manufacturers, and other interested parties. It is not intended to be comprehensive or mandatory.
- The document addresses assessments related to Technical Documentation for MDR / IVDR. It does not cover all MDR, IVDR, or MDCG 2019-16 requirements.
- Developed by Jan Küfner (TÜV SÜD), Dr. Abtin Rad (TÜV SÜD), Dr. Andreas Schwab (TÜV Rheinland), Volker Sudmann (mdc medical device certification), Markus Bianchi (DNV Medcert), Martin Tettke (Berlin Cert), Michael Bothe (DQS Med), Mark Küller (TÜV-Verband / IG-NB), it supersedes the previous version “IT Security for Medical Devices” (Version 5, June 9, 2022).
- For questions regarding AI security risks, refer to IG-NB’s latest “Questionnaire on Artificial Intelligence (AI) in Medical Devices”.
- Although compliance with IEC 81001-5-1 is not obligatory until the end of its transition period, it is recommended. This document references IEC 81001-5-1 for supplementary purposes, focusing on current MDR, IVDR, and MDCG 2019-16 requirements.
- Due to the evolving nature of cybersecurity, this document reflects the state of the art at the time of its creation.
References:
- Regulation (EU) 2017/745 (MDR), dated April 5, 2017
- MDCG 2019-16 – Guidance on Cybersecurity for Medical Devices, Rev. 1, July 2020
- IEC 62304:2006-05 Medical Device Software – Software Life Cycle Processes
- IEC 81001-5-1:2021-12 Health Software and Health IT Systems Safety, Effectiveness, and Security — Part 5-1: Security — Activities in the Product Life Cycle
2. System Description
Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
---|---|---|---|---|
2.1 | State of the Art (SOTA) | An appropriate system diagram must be available. | Is an appropriate system diagram available? | Yes, see: - Software development plan - Software architecture |
2.2 | IEC 81001-5-1 cl. 7.2 | ‘Each product must have a threat model specific to its development scope. This should include correct information flow, trust boundaries, data storage, communication protocols, etc.’ | A comprehensive system diagram should detail: 1. All medical devices and their interfaces (e.g., Bluetooth, Wi-Fi, Ethernet), protocols (e.g., HL7, DICOM, HTTPS, MQTTS, custom), protocol versions, and data types (e.g., health data, commands, updates, remote access). 2. Human-machine interfaces (e.g., screens, keyboards). |
Potential cybersecurity risks and IT security issues have been addressed through the FMEA risk analysis, in line with ISO 14971 for medical device risk management. |
3. Security Risk Management
Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
---|---|---|---|---|
3.1 | MDCG 2019-16 cpt. 3.2 | ‘The security risk management process must include the same elements as safety risk management, documented in a security risk management plan. This includes risk analysis, evaluation, control, residual risk assessment, and reporting.’ | Is there a security risk analysis available? | Yes, see: - Risk management plan - Risk table - Risk management report |
3.2 | MDCG 2019-16 cpt. 3.4 and IEC 81001-5-1 cl. 7.2 |
‘Threat modeling is a systematic method for analyzing security from a structural perspective, identifying and prioritizing vulnerabilities from an attacker’s viewpoint.’ AND ‘Activities must ensure a threat model for each product in the current development scope.’ |
Does the security risk assessment contain a systematic threat model? Note: STRIDE is one approach for interface-by-interface threat modeling. |
Cybersecurity risks and IT-security considerations are factored into the FMEA risk analysis following ISO 14971. |
3.3 | MDCG 2019-16 cpt. 3.4 | ‘Threat modeling involves identifying attack vectors and assets of interest from an attacker’s perspective.’ AND ‘Activities must identify and document vulnerabilities, threats, and their impacts on confidentiality, integrity, and availability, considering intended use and environment.’ |
Is the threat model comprehensive and accurate (e.g., addressing all applicable threats and vectors)? | Yes, see risk table. |
3.4 | IEC 81001-5-1 cl. 7.3 | ‘Activities should estimate the risk associated with vulnerabilities, considering the impact on security.’ ‘Estimation can be supported by using vulnerability scoring, based on existing likelihood/severity models for other risks.’ ‘Evaluate the risk and determine its acceptability.’ ‘Inform the product risk management process.’ |
Is the risk estimated pre- and post-mitigation? Note 1: Quantitative risk assessment is acceptable. Note 2: Security risk involves exploitability and severity. Note 3: Patient data breaches can cause harm. |
Yes, see: - Risk table - Risk management report |
3.5 | MDCG 2019-16 cpt. 3.2 | ‘If a security risk or control could impact safety and effectiveness, it should be included in the safety risk assessment.’ | Are potential impacts of security measures on safety properly addressed? | Yes, see: - Risk table - Risk management report |
3.6 | MDCG 2019-16 cpt. 3.3 | ‘For risks affecting safety or effectiveness, manufacturers must choose the most suitable risk control solution in this priority order: a) Eliminate or reduce risks through design and manufacturing; b) Implement protective measures like alarms for unavoidable risks; c) Provide safety information and training. For security, a similar strategy applies: a) Eliminate or reduce risks through secure design and manufacturing; b) Use protective measures and security notifications as needed; c) Provide security information and guidance for the user to minimize exploitation risk.’ |
Are risk control measures prioritized correctly? Note: MDR/IVDR requires that security measures be incorporated into the device, not left to user/admin implementation through IFU. |
Yes, see: - Risk table - Risk management report |
3.7 | IEC 81001-5-1 cl. 7.4 | ‘Verify that security risk control measures effectively reduce risks to an acceptable level based on acceptance policies.’ ‘Ensure mitigations do not create new or increased risks.’ ‘Verify the effectiveness of implemented measures.’ |
Are risk control and countermeasures appropriate? | Yes, see: - Risk table - Risk management report |
3.8 | MDCG 2019-16 cpt. 2.1 and MDR Annex I (17.4) / IVDR Annex I (16.4.1.ah) and MDR Annex I (18.8) and MDR Annex I (17.2) / IVDR Annex I (16.2) |
‘Key IT security concepts for medical devices include: – Confidentiality of data at rest and in transit. – Integrity to ensure data accuracy and authenticity. – Availability of devices, data, and systems.’ AND ‘Manufacturers must set minimum hardware and IT security requirements for operation.’ AND ‘Devices must be designed to resist unauthorized access and ensure proper functionality.’ ‘Cybersecurity risks should be minimized without impacting the benefit-risk ratio, aligning with risk management principles.’ |
Is the security concept for the device appropriate? | Yes, see: - Risk table - Risk management report - Software development plan |
4. Accompanying Documentation
Item | Source | Requirement(s) | IG-NB Commentary | Manufacturer Reference for Compliance |
---|---|---|---|---|
4.1 | MDCG 2019-16 cpt. 2.6 and MDR Annex I (23.4.ab) / IVDR Annex I (20.4.1.ah) |
‘While MDR and IVDR impose obligations on manufacturers, all stakeholders (e.g., manufacturers, suppliers, healthcare providers, patients) share responsibility for secure healthcare services.’ AND ‘IFUs must specify minimum hardware, IT network, and security requirements to run the software securely.’ |
Are manufacturer, integrator, and user responsibilities reflected in the IFU? Note: Ensure that necessary security controls provided by the environment are noted in technical documentation. |
Yes, see:<br |