EU MDR and MDCG medical-device cybersecurity
Sytance · Updated
The MDR and IVDR require information security to be considered in software development and risk management. The manufacturer’s technical documentation needs to show how the device remains safe and performs as intended in its operating environment. MDCG 2019-16 provides guidance on applying these requirements.
Cybersecurity requirements in Annex I
The MDR does not use section 524B language. Cybersecurity evidence is anchored in the general safety and performance requirements, especially the rules for software design, risk management, information security, protection against unauthorised access, intended operating environment and instructions for use.
Software lifecycle and risk management
MDR Annex I requires software to be developed and manufactured according to the state of the art, taking account of development lifecycle, risk management, verification and validation.
Information security
Annex I makes information security part of software risk management. When cybersecurity affects safety or performance, the assessment must address those effects.
Minimum IT requirements
Manufacturers must state the minimum hardware, IT network characteristics and IT security measures needed to run the software as intended, including protection against unauthorised access.
PMS feedback
PMS data should update benefit-risk, risk management, design, manufacturing, labelling, IFU, clinical evaluation, preventive and corrective action, usability, performance and safety records.
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, Annex I 17.2 (original English)
Annex I makes information security part of software risk management. For example, unauthorised changes to clinical data may affect a diagnosis, while loss of a required service may prevent the device from performing its intended function. Assess the consequences in the device’s actual use environment.
MDCG 2019-16 status
MDCG 2019-16 was first issued in December 2019 and revised in July 2020 as revision 1. It is official MDCG guidance, published by the European Commission to support consistent implementation of MDR and IVDR. The guidance is not legally binding.
MDCG 2019-16 explains how security decisions affect device safety and performance. It also addresses the protection expected from the operating environment and the information manufacturers need to give users. These explanations help connect the product design to the applicable MDR or IVDR requirements.
MDCG explains that a security risk-control measure can affect safety or performance, and a safety risk-control measure can affect security. The file should therefore show both directions of analysis instead of keeping two isolated registers.
MDCG treats threat modelling as a systematic method for identifying vulnerabilities and risks across devices, software, systems, networks and processes. Known vulnerabilities can become foreseeable risks once the manufacturer knows or should know about them.
MDCG expects manufacturers to define the intended IT environment and the minimum controls needed there. If the device relies on a hospital firewall, access management, hardening, patch management, segmentation, encryption or other external controls, those assumptions need to be documented and communicated.
Technical file structure
Cybersecurity records form part of the MDR technical documentation and postmarket surveillance system. Their organisation should show how the manufacturer meets the relevant MDR requirements.
- Risk management: security threats, vulnerabilities, risk controls, residual risks, safety interaction and verification evidence.
- Design and manufacture: secure architecture, software lifecycle controls, secure coding, configuration management, update mechanisms and supply-chain assumptions.
- Verification and validation: security-feature testing, vulnerability scanning, fuzz testing, penetration testing, secure-code analysis and third-party-component review when relevant.
- User information: secure configuration, update instructions, compatibility constraints, network ports and protocols, backup and restore, logging, support lifetime and decommissioning information.
- PMS and vigilance: monitoring for newly emerging vulnerabilities, field incidents, third-party component issues, threat-landscape changes and corrective or preventive action.
MDCG discusses security capabilities that address different problems. Authentication and authorisation restrict access; audit records help investigate actions; backup and recovery restore operation after disruption. Select and verify the capabilities needed for the particular device and its risks.
Different from FDA submissions
FDA and EU documentation often use the same engineering records, but follow different regulatory requirements and structures. A threat model, SBOM, security architecture or penetration-test report can support both jurisdictions only when the file explains how it addresses the relevant legal requirements.
EU applicability
MDR does not ask whether a device meets the FD&C Act cyber-device definition. EU files should explain safety, performance, information security, operating environment and postmarket control under MDR/IVDR terms.
EU documentation structure
The EU file follows Annexes II and III. It should connect risk-management records, general safety and performance requirements, instructions for use and postmarket surveillance.
Postmarket surveillance duties
MDR Article 83 requires manufacturers to actively and systematically gather, record and analyse relevant quality, performance and safety data throughout the device lifetime and update technical documentation accordingly.
Using lifecycle standards
IEC 81001-5-1 can support the software lifecycle and cybersecurity process, but the file still needs a clear MDR mapping. A recognised or useful standard does not erase the MDR obligation to justify the device-specific approach.