MDR Annex I Section 23.4 requires the information supplied with the device to state the minimum hardware, IT network characteristics, and IT security measures needed to run the device as intended. In practice that means four cybersecurity statements in the IFU: minimum IT requirements, user responsibilities, recommended operating environment, and the planned end-of-support date. MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022 set the expected depth.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I Section 23.4 is the legal hook: the information supplied with the device must include, where relevant, minimum requirements concerning hardware, IT networks, and IT security measures necessary to run the software as intended.
  • Annex I Section 17.4 is the mirror obligation on the manufacturer side: those minimum requirements must actually be defined, not just written into the IFU.
  • The IFU should carry four cybersecurity sections: minimum IT requirements, user and operator responsibilities, recommended operating environment, and the end-of-support date or policy.
  • MDCG 2019-16 Rev.1 explicitly expects cybersecurity information for the user, and EN IEC 81001-5-1:2022 treats labeling as a verifiable security activity.
  • The end-of-support date is the item most startups either omit or hide. Notified bodies are now asking for it explicitly.
  • In Tibor's experience, a usability test of the cybersecurity section of the IFU is the cheapest way to catch language a typical user cannot act on.

Why this matters (Hook)

A wearable startup ships a Class IIa device with a companion app. The IFU explains how to charge it, how to clean it, and how to pair it. It says nothing about which mobile operating system versions are supported, whether the companion app should run on a rooted phone, what happens when the phone joins a public Wi-Fi, or when the startup plans to stop issuing security patches. A notified body surveillance audit asks the question every startup expects eventually. "Where are your minimum IT requirements under Annex I Section 23.4 and Section 17.4." The startup has them on an internal Confluence page. They are not in the IFU. That is the finding.

Tibor has seen this pattern at multiple notified body engagements. The manufacturer did the cybersecurity work. They ran penetration tests. They maintained an SBOM. They just never fed the results into the document the user actually reads. MDR Annex I Chapter III on the information supplied with the device is the part of the regulation where cybersecurity meets labeling, and startups who treat labeling as a post-development formatting exercise consistently miss it.

Felix has watched the business consequence. A hospital procurement team sees a security questionnaire response that references an IFU. The IFU is silent on the minimum IT requirements. Procurement escalates. The deal slips by a quarter while the manufacturer issues a labeling change and a change notification to the notified body.

What MDR actually says (Surface)

The legal text is compact and pulls from three Annex I sections.

Annex I Section 17.4. 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.

Annex I Section 23.1(f). Each device shall be accompanied by the information needed to identify the device and its manufacturer, and by any safety and performance information relevant to the user.

Annex I Section 23.4. The instructions for use shall contain, where appropriate, any warnings, precautions, or measures to be taken, and any limitations of use regarding the device, including the minimum requirements concerning hardware, IT networks characteristics, and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

In plain language, whatever the manufacturer defined under Section 17.4 must also show up in the information supplied to the user under Section 23.4. The regulation deliberately closes the loop so that a minimum IT requirement defined in engineering cannot disappear before reaching the user.

MDCG 2019-16 Rev.1 reinforces this by treating cybersecurity information for the user as part of the cybersecurity lifecycle, not as a labeling afterthought. EN IEC 81001-5-1:2022 includes labeling and user documentation as security activities that are verified like any other security control.

A worked example (Test)

A Class IIa remote patient monitoring platform runs on a patient-owned Android phone plus a wearable sensor. The manufacturer has done the engineering work. The IFU needs to carry the result in a cybersecurity section that a real user can act on.

1. Minimum IT requirements. The IFU states the supported Android versions (for example Android 12 and later), the minimum screen size, minimum storage, and the requirement that the device is not rooted. It specifies that the companion app must be installed from the official app store and that sideloaded installations are not supported. It names the network requirements, including supported Bluetooth versions and the fact that the paired phone must be protected by a device lock (PIN, biometric, or pattern).

2. User and operator responsibilities. The IFU tells the user to keep the operating system updated, to install security updates promptly, not to share the paired phone, not to install unknown applications, and to report suspected security incidents to a named contact. For platform customers, the responsibilities include user provisioning, access review, and incident reporting.

3. Recommended operating environment. The IFU states that the device should not be paired over public or untrusted Wi-Fi, that Bluetooth pairing should be done in a private environment, and that the companion app should not be used simultaneously with VPN software that interferes with Bluetooth discovery. If the clinical data flow passes through a hospital network, the IFU names the required network segmentation or isolation.

4. End-of-support date. The IFU names a specific date or a policy such as "security updates will be provided for at least N years after the date of placing on the market" and describes what happens after that date. This is the statement most IFUs are missing. Notified bodies now ask for it explicitly because a device that is silently out of support is a device the user cannot make an informed decision about.

Each of those four statements is traceable back to the cybersecurity risk file, the SBOM, and the EN IEC 81001-5-1 security activities.

The Subtract to Ship playbook (Ship)

Felix's rule on labeling in general applies doubly to cybersecurity labeling. If the text was written by someone who has never sat through a summative usability session, rewrite it before the notified body sees it.

Step 1. Build the cybersecurity IFU block from the engineering artefacts, not from a template. The minimum IT requirements in the IFU are the same requirements already captured in the SBOM, the security risk assessment, and the EN IEC 81001-5-1 activity outputs. Copying them across is a translation exercise, not a fresh writing exercise.

Step 2. Lock the four required items early. Minimum IT requirements, user responsibilities, operating environment, and end-of-support date. Each item gets a named owner. Each item has a single source of truth in the technical documentation.

Step 3. Test the cybersecurity language during summative usability. EN 62366-1:2015+A1:2020 summative evaluation covers the IFU. Give a real user the device and the IFU with no coaching. If the user cannot explain what "minimum IT requirements" means or where to find their Android version, the wording fails and the manufacturer learns it before the notified body does.

Step 4. Decide the end-of-support policy on day one, not year five. Pick a number. Write it into the IFU. Feed it into post-market surveillance so the clock is tracked. A number the manufacturer can defend is better than silence.

Step 5. Tie the labeling into change control. When the cybersecurity risk file changes, for example because of a new supported Android version or a new threat, the IFU change follows automatically through the change control process. The goal is to remove the possibility that engineering changes and IFU text drift apart.

Step 6. For eIFU, do not assume the label is invisible. If the IFU is provided electronically under the eIFU Implementing Regulation, the cybersecurity block is still required content. Electronic delivery changes the distribution method, not the obligation.

Reality Check

  1. Does the current IFU contain a dedicated cybersecurity section, or is the information scattered across chapters.
  2. Can a named person point at the specific paragraph in the IFU that satisfies Annex I Section 23.4.
  3. Do the minimum IT requirements in the IFU match what the security risk assessment actually assumes.
  4. Is there an explicit end-of-support date or policy in the IFU, and is it defensible.
  5. Were the cybersecurity statements tested during summative usability with real users.
  6. When the cybersecurity risk file changes, is there a documented path that updates the IFU automatically.
  7. If the IFU is electronic, does the electronic version carry the same cybersecurity statements as a paper version would.
  8. Could a hospital procurement team answer a security questionnaire from the IFU alone, or does the answer require internal documents the hospital never sees.

Frequently Asked Questions

Do Class I devices need cybersecurity labeling. If the Class I device incorporates software or is software, Annex I Section 17.4 and Section 23.4 apply regardless of class. The depth scales with risk, not with class.

Is the end-of-support date legally required. MDR Annex I Section 23.4 requires the minimum requirements and measures necessary to run the software as intended. A device whose support has ended is not running as intended, so notified bodies treat the end-of-support information as in scope. MDCG 2019-16 Rev.1 reinforces the expectation.

Can the cybersecurity section live on a website instead of the IFU. The authoritative information supplied with the device must meet MDR Annex I Chapter III. A website can supplement but cannot replace the IFU unless the electronic IFU framework under the Implementing Regulation applies.

What if the device is not connected. Annex I Section 17.4 still applies if the device incorporates software. If there is genuinely no wireless or wired connectivity, the IT network text becomes minimal, but the minimum hardware and operator responsibility text still applies.

How long is "long enough" for security support. MDR does not name a number. The manufacturer picks a defensible number based on expected device lifetime and SBOM maintenance capacity, and documents the rationale in the post-market surveillance plan.

Who signs off on the cybersecurity IFU section. In Tibor's audit experience, the cleanest setups have the cybersecurity lead, the regulatory affairs lead, and the usability engineer all named on the approval record.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.4, 23.1, 23.4.
  2. MDCG 2019-16 Rev.1 (December 2019, Rev.1 July 2020). Guidance on cybersecurity for medical devices.
  3. EN IEC 81001-5-1:2022. Health software and health IT systems safety, effectiveness and security. Security activities in the product life cycle.
  4. EN 62366-1:2015+A1:2020. Medical devices. Application of usability engineering to medical devices.