EU MDR and MDCG Cybersecurity
EU medical-device cybersecurity starts from MDR and IVDR safety, performance, software lifecycle, risk management, information-security and user-information requirements. MDCG 2019-16 helps explain those requirements, but the EU file should be built as EU technical documentation, not as a copied FDA submission.
Annex I cybersecurity hooks
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 explicitly connects software risk management to information security, so cybersecurity cannot be treated as an isolated IT appendix when it affects safety or performance.
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
That short Annex I phrase is the bridge between cybersecurity and the MDR safety file. A vulnerability matters in the EU file when it can affect intended operation, safety, performance, essential performance, availability, data integrity, confidentiality, user information or the operating environment needed for the device to perform as intended.
MDCG 2019-16 status
MDCG 2019-16 is an official European Commission/MDCG guidance document, first published in 2020 and listed under the Commission's MDCG guidance page. Commission guidance says MDCG documents are intended to support effective and harmonised implementation of MDR and IVDR, but they are not legally binding.
The useful function of MDCG 2019-16 is practical interpretation. It explains how cybersecurity interacts with safety risk management, intended environment assumptions, secure design, verification, validation, technical documentation, IFU, postmarket surveillance and vigilance.
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
A defensible EU cybersecurity file should read like part of the MDR technical documentation and PMS system. It should not be a pasted FDA cybersecurity section with EU labels added later.
- 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 also points to practical security capabilities such as authentication, authorisation, audit controls, automatic logoff, configuration, integrity, malware protection, backup and recovery, emergency access, system hardening, transmission protection and security guides. Those capabilities are evidence prompts, not a universal list that every device must implement identically.
Different from FDA submissions
FDA and EU evidence often use the same engineering artefacts, but the source authority and document shape are different. A threat model, SBOM, security architecture or penetration-test report can support both jurisdictions only after it is mapped to the correct legal question.
No FDA 524B test
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.
No FDA submission format
An EU technical file needs Annex II and Annex III logic, risk-management traceability, GSPR mapping, IFU support and PMS integration. FDA section headings are not enough.
PMS is not optional maintenance
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.
Standards still need mapping
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.