EU MDR (Regulation 2017/745) Annex I cybersecurity requirements, explained

Annex I is organized into three chapters: Chapter I (general requirements), Chapter II (requirements regarding design and manufacture), and Chapter III (requirements regarding the information supplied with the device), per TUV SUD's public breakdown of the annex's structure. The cybersecurity-relevant text sits in Chapter II, under point 17, "devices incorporating electronic programmable systems and software that are devices in themselves" — a design-and-manufacture requirement, not a separate standalone clause. A matching duty to disclose those same requirements to the end user, point 23.4(ab), sits in Chapter III. There is no Annex I point, chapter or standalone legal instrument labeled "cybersecurity" anywhere in the regulation — it's a label the industry applies to this scattered handful of clauses, not one the regulation uses itself.

Per the EUR-Lex consolidated text (quoted directly by this guide's secondary source):

Point 18.8 adds a parallel protection-against-unauthorised-access duty specifically for devices with a measuring function or a built-in monitoring system, and point 23.4(ab), in Chapter III, requires the manufacturer to carry the same 17.4 minimum requirements — hardware, network characteristics, IT security measures — into the device's instructions for use, so the end-user organization running the device actually receives them, not just the technical file reviewer. The IVDR, Regulation (EU) 2017/746, mirrors nearly all of this wording at its own Annex I point 16, for in vitro diagnostic devices.

This is the clause device makers find hardest to operationalize, because 17.2 names the dimensions a secure development process must cover — development life cycle, risk management including information security, verification and validation — without specifying a method, a standard, or a pass/fail bar. That gap is exactly what MDCG 2019-16 was written to fill: the guidance works through 17.4 (and IVDR 16.4) clause by clause and layers in concepts the regulation's own text never uses, such as a documented security risk management process run alongside the device's ISO 14971 safety risk file, and a security benefit-risk analysis that weighs a security control's side effects (an authentication step that could delay emergency use, for example) against the risk it mitigates. See MDCG 2019-16: Guidance on Cybersecurity for Medical Devices for how that guidance structures the answer. The regulation sets the legal bar; MDCG 2019-16 is the Commission-endorsed account of how most manufacturers and Notified Bodies currently read that bar in practice — but it is guidance, not law, and MDCG itself says so.

Not as far as this guide's research found. MDCG 2019-16's own Annex III lists standards relevant to this area — EN ISO 14971, IEC 62304, 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 — but states explicitly that these "cannot provide a presumption of conformity, unless they are harmonised under" MDR/IVDR and published in the Official Journal. That is a meaningfully different legal position from, say, EN 18031 under the RED's cybersecurity delegated act, which does give that presumption for radio equipment in scope (see EN 18031 explained for firmware teams). A connected medical device maker should treat every one of those standards as strong design and audit evidence for its Annex I 17.x file, not as a document that, once applied, lets it skip the regulation's own conformity assessment route.

The shape differs even where the underlying engineering overlaps heavily. FDA's Section 524B "cyber device" duties — an SBOM, a vulnerability-monitoring and disclosure process, and a patching commitment — are a distinct, more itemized statutory list than MDR's broader "state of the art... including information security" language in 17.2; see FDA premarket cybersecurity for medical devices for that side. A manufacturer selling the same connected device into both the US and EU markets needs separate submissions built against each legal text, even though the underlying work — secure development, an SBOM, a vulnerability-handling process, a patch pipeline — is largely the same engineering effort documented two different ways.