MDR Annex I point 17: the cybersecurity requirement in full

The text, in full

Annex I of Regulation (EU) 2017/745, the Medical Device Regulation, contains the general safety and performance requirements. Point 17 is headed “Electronic programmable systems – devices that incorporate electronic programmable systems and software that are devices in themselves”. It has four sub-points, quoted here from the consolidated text of 10 January 2025.

17.1 requires that such devices “shall be designed to ensure repeatability, reliability and performance in line with their intended use”, and that “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”.

17.2 is the cybersecurity clause: “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.”

17.3 deals with software intended for mobile computing platforms, which must be designed “taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise)”.

17.4 pushes part of the problem outwards: “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.”

What “state of the art” actually imports

Point 17.2 does not describe a control, a standard or a test. It imports whatever competent practice looks like at the moment of assessment, and that is why two lines of law can support a forty-page cybersecurity file. The phrase has three practical consequences.

• The bar moves. Evidence that satisfied a review in 2021 can be insufficient in 2026 without any change to the legal text, because the state of the art moved underneath it.
• The burden is yours. There is no list to comply with, so the manufacturer has to argue that its development life cycle, its risk management including information security, and its verification and validation are current. That argument is made in documents.
• Guidance fills the gap. Where the law is silent, the Medical Device Coordination Group writes down what the assessment expects, and notified bodies read the same document you do.

Note also what point 17.2 lists as principles: development life cycle, risk management including information security, verification and validation. Those are exactly the three things a cybersecurity file has to evidence, in that order. A test report on its own answers only the third.

Point 17.4 and the environment you do not control

Point 17.4 obliges you to state the minimum hardware, network and IT security conditions the device needs. MDCG 2019-16 rev.1 chapter 3.6 defines the operating environment as “any IT/network asset interacting with the medical device that is not supplied by the medical device manufacturer”, and sets out how far you may lean on it.

The medical device should be as autonomous as possible in terms of IT security and sole reliance on the existence of any IT security requirements on the operating environment should be kept to a minimum and reflect the manufacturer’s assumptions on the baseline environment security for the secure operation of the medical device.MDCG 2019-16 rev.1, chapter 3.6

The following paragraph is blunter still: “In accordance with the principle of layered security, IT security measures foreseen for the operating environment in general should not serve the purpose of compensating security controls for medical device vulnerabilities, unless there is sufficient justification.” Where the device does rely on the environment for an important control, the guidance says that reliance has to be stated in the technical documentation.

Read together with point 17.4, this makes your published minimum requirements a testable claim rather than a disclaimer. If the instructions for use say the device must sit on a segmented network, a reviewer is entitled to ask what happens when it does not, and a test that only ran on an isolated bench cannot answer.

MDCG 2019-16 rev.1: the document the assessment runs on

MDCG 2019-16 was published in December 2019 and revised in July 2020. Rev.1 is still the current revision. It is not a Commission document and it is not legally binding, and it says so on its own first page, but it is the shared reference between manufacturer and notified body for exactly the questions Annex I point 17 leaves open. Its structure maps cleanly onto the file you have to produce.

MDCG 2019-16 rev.1 chapters and what each one asks you to produce

Chapter	Subject	What lands in the file
2.3	Intended use and intended operational environment	The security context: who uses the device, where, and against what assumed environment
3.1	Secure by design	Design rationale, defence in depth, the eight secure-development practices the chapter lists
3.2	Security risk management	A security risk management plan, with analysis, evaluation, control, residual risk and reporting inside the device risk process
3.3	Security capabilities	The capabilities selected as risk controls, drawn from the indicative Table 3 list
3.4 / 3.5	Security risk assessment and benefit-risk analysis	Assessed security risks and the justification where a control is not implemented
3.6	Minimum IT requirements	The point 17.4 statement, and the documented reliance on the operating environment
3.7	Verification and validation	Security testing: feature testing, fuzz testing, vulnerability scanning, penetration testing, code and component analysis
4.1	Documentation	Methods and results of security testing inside the Annex II documentation, kept current from post-market surveillance
5	Post-market surveillance and vigilance	Handling and remediation of cybersecurity incidents and vulnerabilities

Security capabilities: the indicative list

Chapter 3.3 says that security capabilities “may be determined as suitable risk-control measures” and that their design and implementation “need to comply with the state of the art”. Table 3 then gives an indicative list of eighteen. It is not a checklist and it is not a conformity requirement, but it is a useful completeness test for a scope document: if a capability is relevant to your device and no test exercised it, the gap will be visible.

• Automatic logoff, audit controls, authorization, configuration of security features
• Cybersecurity product upgrades, personal data de-identification, data backup and disaster recovery
• Emergency access, personal data integrity and authenticity, malware detection and protection
• Node authentication, person authentication, physical locks, system and OS hardening
• Security and privacy guides, personal data storage confidentiality, transmission confidentiality, transmission integrity

Two of these repay attention because they are easy to leave out of a scope. Emergency access is a clinical requirement that frequently defeats an authentication control, and it should be tested as a bypass rather than assumed as a feature. Physical locks matter because a device pulled out of service and sold second-hand is a realistic attacker starting point, which is also why data-at-rest and factory-reset behaviour belong in the same campaign.

Verification and validation is where testing appears

Chapter 3.7 opens by restating point 17.2, then delivers the sentence the rest of this site depends on.

The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing.MDCG 2019-16 rev.1, chapter 3.7

A footnote defines the last of those: “According to ENISA, penetration testing is the assessment of the security of a system against different types of attacks performed by an authorised security expert. The tester attempts to identify and exploit the system’s vulnerabilities.” The chapter then adds that “additional security testing can be done by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues”.

Two things follow. First, penetration testing is named but not mandated: it is one of four methods, and a manufacturer that can justify a different mix is not in breach of anything. Second, vulnerability scanning and penetration testing are listed as separate items, which means a scanner report does not discharge whatever the penetration test was going to demonstrate. In practice, for a device with a radio, an update path and a backend, the other three methods do not reach the questions a manual campaign is there to answer.

Filing the result

Chapter 4.1 is short and specific. Annex II documentation, it says, must contain information demonstrating conformity with the Annex I requirements, and “shall comprise a justification, validation and verification of the solutions adopted to meet those requirements (e.g. methods and results of security testing described in Chapter 3.7 of this guidance)”. The example in brackets is the filing instruction: methods and results, not a certificate and not a summary.

The Regulation itself is consistent. Annex II section 6, “Product verification and validation”, requires that “the documentation shall contain the results and critical analyses of all verifications and validation tests and/or studies undertaken to demonstrate conformity of the device with the requirements of this Regulation”. Section 6.1(b) names software verification and validation among the areas needing detailed test design, protocols and analysis methods, and requires that the information address “all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer”.

That last clause is a scoping instruction hiding in a documentation requirement. If your instructions for use list three supported operating systems for the companion application, the file has to speak to three, not one.

The file does not stop at market entry

Article 83(1) requires a post-market surveillance system for each device, planned, documented and maintained as “an integral part of the manufacturer’s quality management system referred to in Article 10(9)”. Article 83(3) lists what the collected data are used for, from updating the benefit-risk determination to identifying the need for corrective action, and closes with a single sentence: “The technical documentation shall be updated accordingly.”

For a security file that sentence is the whole cadence. A new attack technique against a component in your stack, a vulnerability published against the operating system your device ships, a report from a hospital that a service interface is reachable from the clinical network: each is post-market surveillance data, each feeds the security risk assessment, and each can make the last test report a description of a device you no longer sell. MDCG 2019-16 chapter 4.1 says the same in its own words, requiring the technical documentation to be updated with information on the handling and remediation of cybersecurity incidents and vulnerabilities.

IVDR: identical text, different numbers

For in vitro diagnostic devices the requirement lives at Annex I point 16 of Regulation (EU) 2017/746. Points 16.1, 16.2, 16.3 and 16.4 are word-for-word the MDR’s 17.1, 17.2, 17.3 and 17.4, checked against the consolidated text of 10 January 2025. MDCG 2019-16 addresses both regulations throughout and gives the paired references in its own text, for example “Annex I, sections 17.2 (MDR) or 16.2 (IVDR)”.

The practical difference is not in the security requirement but in what surrounds it: a laboratory analyser with a middleware layer, an LIS integration and a results portal has a different attack surface from an implantable, and the operating environment statement under 16.4 has to describe a laboratory network rather than a ward.

What the Cyber Resilience Act does not do

It is worth stating the negative, because the assumption costs teams real time. Article 2(2) of Regulation (EU) 2024/2847, the Cyber Resilience Act, provides that the regulation “does not apply to products with digital elements to which the following Union legal acts apply: (a) Regulation (EU) 2017/745; (b) Regulation (EU) 2017/746; (c) Regulation (EU) 2019/2144.” Your device is out of CRA scope.

Three things still reach a device manufacturer. Products in your catalogue that are not devices, such as a gateway, an accessory or a companion application that is not itself a device, are in CRA scope on their own terms. Components you buy will increasingly arrive with CRA-grade vulnerability handling and component transparency, which changes what you can demand of suppliers. And Article 2(5) allows the Commission, by delegated act, to limit or exclude the application of the CRA where sectoral rules achieve the same or a higher level of protection, so the boundary is a policy line rather than a permanent one.

EN IEC 81001-5-1 and the harmonised standards list

Secure-development-lifecycle standards come up in every notified-body conversation, and the honest status is narrow. EN IEC 81001-5-1 is not cited in the Official Journal as a harmonised standard under Regulation (EU) 2017/745. We checked that against Commission Implementing Decision (EU) 2021/1182 and all eleven amendments published to date, the most recent dated 11 June 2026, and against the Commission’s consolidated summary list of harmonised standards for the MDR: none of them references 81001.

No citation means no presumption of conformity. It does not mean the standard is irrelevant, because point 17.2 imports the state of the art whatever the Official Journal says. MDCG 2019-16 Annex III, written before the standard existed, lists EN 62304 for the software life cycle and IEC 62443-4-1 for secure product development as relevant references. If you claim conformance to a lifecycle standard, claim it as evidence of state of the art and be ready to show the activity records, not the certificate.

A workable order of work

The requirement is a sequence, not a shopping list, and doing it in the wrong order produces a test that cannot be filed. A defensible order for a connected device looks like this.

• Write the security context first: intended use, intended operational environment, who the users are, and what you assume the environment provides. This is chapter 2.3 and it bounds everything after it.
• Run security risk management inside the device risk process, as chapter 3.2 requires, and record the security capabilities you selected as controls.
• State the minimum IT requirements under point 17.4 and note explicitly where the device relies on the environment for a control.
• Only then scope the test, using the risk assessment and the capability list to decide what the campaign has to exercise, and the supported configurations from the instructions for use to decide how many builds it covers.
• Run the campaign against a release candidate, remediate, retest the fixes, and freeze the report with its methods and results.
• File the methods and results under Annex II section 6, feed every finding back into the security risk assessment, and record the residual risk decisions.
• Put the retest trigger in the post-market surveillance plan so Article 83(3) has something to act on.

A team that follows this order can answer the question a reviewer actually asks, which is not “did you test” but “how do you know the test covered what your own risk assessment said mattered”.