Cybersecurity for Medical Devices

The MDR does not use the term “cybersecurity” literally, but Annex I sets out clear requirements: Section 17.1 requires, for devices incorporating programmable electronic systems, repeatability, reliability and performance in line with their intended purpose; Section 17.2 requires software to be developed in accordance with the state of the art, taking into account the life cycle, risk management – including information security – as well as verification and validation. Under Section 17.4, manufacturers must set out minimum requirements concerning hardware, IT network characteristics and IT security measures, including protection against unauthorised access; Section 18.8 and Section 23.4(ab) add protection against unauthorised access and the obligation to communicate these minimum requirements in the instructions for use. The Cyber Resilience Act (Regulation (EU) 2024/2847) explicitly excludes medical devices from its scope in Art. 2, because the MDR already imposes IT security requirements covering the entire life cycle.

The guidance MDCG 2019-16 Rev. 1 (July 2020) issued by the Medical Device Coordination Group specifies how the Annex I requirements are to be implemented across the entire life cycle: secure by design, a dedicated security risk management process interlinked with safety risk management, and a catalogue of security capabilities such as authentication, authorisation, encryption and audit logging. It establishes the principle of joint responsibility: alongside the manufacturer, integrators, operators and users also bear defined obligations for secure operation – such as secure configuration and compliance with the manufacturer’s minimum IT requirements. A mapping table cross-references the relevant sections of MDR and IVDR Annex I, and an annex with case examples distinguishes cybersecurity incidents from reportable serious incidents.

IEC 81001-5-1:2021 (“Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle”) defines the process requirements for the secure development and maintenance of health software: security risk management with threat modelling, security testing, configuration management, and processes for vulnerability monitoring and problem resolution. It extends the life cycle structure of IEC 62304 with security activities and is modelled on IEC 62443-4-1. The European version EN IEC 81001-5-1:2022 is earmarked for harmonisation under the MDR and IVDR, but even after the update of the lists of standards in June 2026 (Commission Implementing Decision (EU) 2026/1231) it has still not been cited in the Official Journal of the EU – so there is no presumption of conformity. In practice, notified bodies nevertheless treat the standard as the state of the art for demonstrating compliance with the requirements of Annex I Sections 17.2 and 17.4.

The AI Act (Regulation (EU) 2024/1689, in force since 1 August 2024) complements the MDR but does not replace it: under Art. 6(1), an AI system qualifies as high-risk AI if it is a safety component of a medical device, or is itself such a device, and its conformity assessment requires a notified body – which, under the MDR, is regularly the case from class IIa upwards. The FAQ MDCG 2025-6 (June 2025), developed jointly with the AI Board, answers 36 practical questions on the interplay between the two frameworks, for example on role mapping (manufacturer under the MDR corresponds to provider under the AI Act) and on combining the conformity assessments. On timelines, 2026 brought a significant change: the “Digital Omnibus” agreed by Parliament and Council in May 2026 postpones the application of the high-risk obligations for AI systems embedded in regulated products from 2 August 2027 to 2 August 2028; this takes effect upon publication in the Official Journal of the EU. A more far-reaching proposal to largely exempt medical devices from the AI Act was not adopted.

Because the threat landscape and vulnerabilities keep changing after a device has been placed on the market, the MDR requires an active post-market surveillance system (Art. 83) with a PMS plan (Art. 84) and – depending on the class – a PMS report or a periodic safety update report (PSUR, Art. 86); under MDCG 2019-16, cybersecurity is explicitly part of this system. If an exploited or exploitable vulnerability leads to a serious incident, the vigilance obligations under Art. 87 apply: reporting no later than 15 days after awareness, 10 days in the event of death or an unanticipated serious deterioration in health, and 2 days in the event of a serious public health threat; trend reporting under Art. 88 comes on top. IMDRF codes are available for reporting security-related causes, such as “Computer System Security Problem” and “Software Security Vulnerability”. From a regulatory perspective, security patches are corrective actions and may be reportable as field safety corrective actions (FSCA) – a structured vulnerability handling process in line with IEC 81001-5-1 connects both worlds. Worth watching: the Commission proposal for the MDR revision presented in December 2025 (COM(2025) 1023) additionally provides for CRA-style reporting of actively exploited vulnerabilities to CSIRTs and ENISA – not yet adopted.

Notified bodies assess cybersecurity as part of the technical documentation under MDR Annexes II and III – from the security risk analysis and the definition of security capabilities to evidence from security testing and the processes for vulnerability handling and PMS. The Team-NB position paper “Cyber Security” (October 2022) describes the common expectations of the European notified bodies regarding this evidence; in a letter of February 2026, Team-NB also urges the swift harmonisation of standards such as IEC 81001-5-1. As long as harmonised cybersecurity standards are lacking, there is no presumption of conformity – manufacturers must substantiate the state of the art themselves and should build their line of argument along MDCG 2019-16 and IEC 81001-5-1.