MDR Annex I Section 17 sits inside the General Safety and Performance Requirements. It covers electronic programmable systems and software. §17.2 demands a state-of-the-art software development lifecycle with risk management, verification, and validation. §17.4 demands minimum IT security requirements for hardware, network characteristics, and protection against unauthorised access. Together they make cybersecurity a GSPR, not a feature.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Section 17 of Annex I applies to every device that incorporates electronic programmable systems or software.
  • §17.2 establishes the state-of-the-art software development lifecycle obligation, incorporating development lifecycle, risk management, verification, and validation.
  • §17.4 establishes IT security as a distinct GSPR, including minimum hardware, network, and access control requirements.
  • A non-conformity against Section 17 is a GSPR finding, not a comment. It blocks certification until closed.
  • The interpretation reference point used by notified bodies is MDCG 2019-16 Rev.1, supported by EN IEC 81001-5-1:2022.

Why §17 exists at all

General Safety and Performance Requirements are the backbone of the MDR. Annex I defines what every medical device on the European market must satisfy, regardless of classification. Section 17 is the chapter where the MDR acknowledges that electronic programmable systems and software are not ordinary components. They have their own failure modes. They can be updated, patched, corrupted, and attacked. A safety regime that ignores software and its security surface cannot deliver patient safety in 2026.

In Tibor's experience working with notified bodies, Section 17 is one of the most frequently cited sections in software-intensive device audits. It is short, it is dense, and it has teeth. A single finding against §17.4 is enough to withhold the CE certificate until the manufacturer produces a remediation plan the auditor accepts.

What the MDR actually says

Section 17 of Annex I is titled "Electronic programmable systems: devices that incorporate electronic programmable systems and software that are devices in themselves". It is short enough to read in one sitting. The structure is four numbered subsections, each adding a specific obligation.

§17.1: Design principles for electronic programmable systems

Devices that incorporate electronic programmable systems shall be designed to ensure repeatability, reliability, and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance. In plain language: the system must be safe by design, and a single fault must not cascade into patient harm.

§17.2: State-of-the-art software development

For devices that incorporate software, or for software that is a device in itself, 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. This is the paragraph that makes EN 62304:2006+A1:2015 the de facto software lifecycle reference under MDR. It is also the paragraph that explicitly ties information security into the software lifecycle obligation.

The phrase "state of the art" carries weight. State of the art is not a single document. It is the current best practice as expressed in harmonised standards, guidance documents, and accepted industry convention. A manufacturer cannot argue that a particular practice was not required if that practice is baked into the current harmonised standard.

§17.3: Mobile and hardware compatibility

Software intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (for example, size and contrast ratio of screen) and the external factors related to their use (varying environment as regards level of light or noise). This section is usually read in conjunction with usability engineering under EN 62366-1:2015+A1:2020 rather than with security, but it is part of Section 17 and notified bodies do cite it.

§17.4: IT security

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. This is the GSPR-level IT security requirement. It is deliberately short. The heavy lifting happens inside MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022, but the obligation to address security exists at the GSPR level.

Reading §17.2 and §17.4 together

The two subsections that matter most for cybersecurity are §17.2 and §17.4. They work in tandem.

§17.2 says the software must be developed with a state-of-the-art lifecycle that explicitly includes information security. That means a secure development lifecycle is not optional. It is a consequence of a correctly-read Annex I.

§17.4 says there must be documented minimum requirements for hardware, network, and IT security, including protection against unauthorised access. That means the output of the security process is not just internal engineering artefacts. It is a set of declared minimum requirements the user can rely on.

The practical consequence is that a compliant file answers two distinct questions. First: was security built into the development process? Second: what minimum conditions must the user maintain to keep the device secure in operation? The first is §17.2 territory. The second is §17.4 territory. Miss either one and the GSPR checklist has a gap.

A worked example: an infusion pump companion app

A startup is building a Class IIb infusion pump with a companion Android app for clinicians. The pump runs its own firmware. The app communicates with the pump over Bluetooth Low Energy and with a cloud backend over HTTPS.

A §17.2-compliant file for this product includes:

  • A software development plan per EN 62304:2006+A1:2015 that explicitly incorporates the security lifecycle activities from EN IEC 81001-5-1:2022.
  • A risk management file per EN ISO 14971:2019+A11:2021 in which security hazards (unauthorised command injection into the pump, tampering with infusion parameters, exfiltration of patient data) are represented alongside clinical hazards.
  • A verification and validation plan that includes both functional testing and security-specific testing (threat model validation, penetration testing, fuzzing where appropriate).
  • A change control procedure that triggers re-verification when SOUP components or security-critical libraries are updated.

A §17.4-compliant file for the same product additionally includes:

  • Minimum hardware requirements for the host device running the companion app (operating system version, patch level, hardware security features).
  • Minimum network requirements, including transport encryption and authentication.
  • Access control requirements, including user authentication, role separation, and session management.
  • A statement of intended use environment from a security perspective, for example "for use inside a hospital network with a firewall configured per the accompanying technical security guidance".

Both sets feed the instructions for use and the accompanying technical security documentation. Both are reviewed by the notified body.

The Subtract to Ship playbook

Felix sees founders over-complicate this. The practical approach is simpler than the legal text makes it look.

Treat Section 17 as a two-column checklist. Left column, §17.2 activities that live inside the development process. Right column, §17.4 declarations that flow into the instructions for use and the security manual. Every item on the left must have a corresponding verification record. Every item on the right must have a corresponding communication to the user.

Do not create a parallel security document library. The software development plan already exists for EN 62304. The risk file already exists for EN ISO 14971:2019+A11:2021. Fold the EN IEC 81001-5-1:2022 activities into those documents rather than duplicating them. Tibor has seen startups create three parallel plans, three parallel risk files, and three parallel V&V strategies. The result is contradictions that auditors find immediately.

Use MDCG 2019-16 Rev.1 as the interpretation layer. When the MDR text is terse and the standard is long, the guidance document is the bridge. The notified body will consult it. So should the manufacturer.

Map each §17.4 "minimum requirement" to a specific sentence in the instructions for use. If the requirement is "the device must be used on a network with transport encryption", the IFU must say so in plain language. The §17.4 obligation is not discharged until the user knows the constraint.

Reality Check

  1. Does the software development plan explicitly reference the state-of-the-art reference set (EN 62304:2006+A1:2015 and EN IEC 81001-5-1:2022) in the same document?
  2. Is information security explicitly cited in the risk management plan as an in-scope hazard category?
  3. Are verification and validation activities differentiated for functional behaviour and for security behaviour?
  4. Is there a documented set of minimum hardware requirements for any host platform the software runs on?
  5. Is there a documented set of minimum network requirements, including encryption and authentication?
  6. Are access control requirements defined at the user, role, and session level?
  7. Does the instructions for use communicate each §17.4 minimum requirement to the user in actionable language?
  8. Is the change control procedure triggered by security-relevant SOUP updates, not only by functional changes?

Frequently Asked Questions

Is Section 17 only for software-as-a-medical-device, or also for devices that contain software? Both. The chapter covers "devices that incorporate electronic programmable systems and software that are devices in themselves". If there is any programmable element in the device, Section 17 applies.

Is §17.4 limited to connected devices? No. §17.4 applies whenever IT security is relevant to the safe operation of the software. A device with no connectivity has a smaller attack surface, but §17.4 still asks the manufacturer to set out minimum IT security requirements. For a fully offline device, those requirements may be minimal but must still be documented.

Does compliance with EN IEC 81001-5-1:2022 automatically satisfy §17.2 and §17.4? EN IEC 81001-5-1:2022 is a harmonised standard, which gives a presumption of conformity with the relevant aspects of the GSPRs. It is the closest thing to a direct path to Section 17 compliance for security, but it must be applied correctly and traceably.

How does §17.2 interact with §17.4? §17.2 is about the process. §17.4 is about the output. The process must produce the output. A file that has a secure development lifecycle but no declared minimum IT security requirements is missing half of Section 17.

What happens if §17.4 requirements change after CE marking? Post-market changes to the declared minimum requirements trigger change control. A new Android OS vulnerability that changes the minimum host platform requirement, for example, is a field action candidate, not a silent update.

Is a software bill of materials required by Section 17? Section 17 does not use the term "SBOM". But the combination of §17.2's state-of-the-art lifecycle obligation and EN IEC 81001-5-1:2022's configuration management requirements means an SBOM is the de facto expectation in 2026.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, Chapter II, Section 17, subsections 17.1, 17.2, 17.3, and 17.4.
  2. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices (December 2019, revised July 2020).
  3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle.
  4. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.
  5. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.