MDCG 2019-16: the EU's guidance on cybersecurity for medical devices

MDCG 2019-16 does not invent new cybersecurity law; it maps existing MDR/IVDR essential requirements onto practical guidance. Its own correspondence table lines up the relevant MDR Annex I sections against their IVDR Annex I equivalents:

The clearest single clause is MDR Article 17.4 / IVDR Article 16.4, quoted directly in the guidance: manufacturers "shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended." MDCG 2019-16 spends most of its length explaining what satisfying that one clause looks like in practice.

Chapter 3 of the guidance sets out a "secure by design" expectation running through the device life cycle: a documented security risk management process (run alongside, not instead of, the device's ISO 14971 safety risk management file), the identification of security capabilities the device needs, a security risk assessment, and — distinctively — a security benefit-risk analysis that weighs a security control's side effects (for example, an authentication step that could delay emergency use) against the risk it mitigates. The guidance's minimum IT requirements section works through MDR 17.4/IVDR 16.4 clause by clause, giving a non-exhaustive, non-mandatory list of possible operating-environment controls — network segmentation, access management, anti-malware, patch management — that a manufacturer can draw on when defining what its device needs from its hosting environment, while making clear the manufacturer alone decides which of those controls actually apply to its own device and risk profile.

Chapter 4 covers what a manufacturer must document and disclose. Instructions for use must include the device's minimum IT/network/security requirements (the Article 23.4(ab)/20.4.1(ah) disclosure duty) in a form clear enough for an operator to actually configure a safe environment around the device. The guidance also points to the MDS2 (Manufacturer Disclosure Statement for Medical Device Security), describing it as "an industry-wide and globally accepted form" a manufacturer can use to convey the device's security information to purchasers and operators in a standard structure.

Chapter 5 extends the same cybersecurity lens into the post-market phase. A manufacturer's post-market surveillance (PMS) system under MDR Article 83 / IVDR Article 78 must actively collect and review cybersecurity-relevant field experience, not just safety complaints. For vigilance reporting under MDR Article 87 / IVDR Article 82, the guidance maps cybersecurity root causes onto existing IMDRF coding: device problem code A110502 ("Computer System Security Problem," further split into application security problems and unauthorized access) and incident root-cause code C1007 ("Software Security Vulnerability"). MDCG 2019-16's Annex II gives worked examples distinguishing a security incident from a reportable serious incident — ranging from malware on an external programmer for an implantable deep brain stimulator or pacemaker, to ransomware against a PACS system, to a legacy RDP vulnerability on an X-ray machine — explicitly flagged as illustrative rather than an exhaustive list of what to expect.

Annex III lists standards the guidance considers relevant to cybersecurity, including EN ISO 14971 (safety risk management), IEC 62304 (software lifecycle), ISO/IEC 27001, ISO/IEC 80001-1 and IEC 81001-5-1, IEC 62443-4-1 and 62443-4-2, and IEC/TR 60601-4-5. The annex carries its own disclaimer, worth quoting in full: this section "is intended for information purposes only and does not provide any guidance that could be used for the purposes of meeting requirements" under MDR or IVDR, and the listed standards "cannot provide a presumption of conformity, unless they are harmonised under the aforementioned regulations and published in the Official Journal." Citing one of these standards in a technical file is evidence of a reasonable approach, not an automatic conformity shortcut the way a harmonised standard would be.