Medical Device Cybersecurity in the EU: MDR, IVDR, and IEC 81001-5-1

This guide is for manufacturers placing connected devices or medical device software on the EU market. It explains where the legal duties sit, what a Notified Body will look for, how IEC 81001-5-1 fits, and which other EU laws may touch your product.

Last reviewed: October 2026 against Regulation (EU) 2017/745, Regulation (EU) 2017/746, MDCG 2019-16 Rev.1, IEC 81001-5-1:2021, and Regulation (EU) 2024/2847. This guide is not legal advice; confirm product-specific questions with regulatory counsel.

Why this matters

In the EU there is no separate cybersecurity submission like the FDA's eSTAR section. Cybersecurity is folded into the general safety and performance requirements (GSPRs) in Annex I. That means it shows up everywhere: in your risk file, your software lifecycle records, your technical documentation, your instructions for use, and your postmarket surveillance plan. A Notified Body that finds weak security evidence can hold up your CE certificate the same way it would for an electrical safety gap.

If you also sell in the US, most of the work carries over. Our EU MDR vs FDA cybersecurity crosswalk shows exactly where the two overlap and where they differ.

Where the legal requirements sit

The MDR and IVDR do not use the word "cybersecurity" much, but Annex I sets clear duties for devices that include software or are software. Under the MDR, the main provisions are:

The IVDR contains matching provisions for in vitro diagnostic devices and software. The section numbers differ, so check the IVDR text directly when building an IVD file.

MDCG 2019-16: the EU's cybersecurity guidance

MDCG 2019-16 Rev.1, published by the Medical Device Coordination Group, is the main guidance on meeting those Annex I duties. It is not law, but Notified Bodies use it as their reference point. Its core expectations are:

• Security by design. Build security into requirements and architecture from the start, not after testing.
• Security risk management alongside safety risk management. Treat security risks with their own process and connect them to the ISO 14971 safety risk file, because a security failure can cause patient harm.
• Defense in depth. Use layers of controls rather than relying on one barrier.
• Shared responsibility. Spell out what the manufacturer secures and what the hospital or user must do, and document it in the instructions for use.
• Verification of security. Test controls, including penetration testing where appropriate, before release.
• Postmarket handling. Monitor vulnerabilities, assess them, fix them, and tell users when they need to act.

How IEC 81001-5-1 fits

IEC 81001-5-1:2021, "Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle," describes the security activities a manufacturer should perform from design through maintenance. The European version is published as EN IEC 81001-5-1:2022.

The standard was written to sit next to IEC 62304, so its structure will feel familiar to software teams. It covers:

• Quality management and security risk management that run across the whole lifecycle.
• Development activities such as security requirements, secure architecture and design, secure coding, and security testing.
• Software maintenance, including how security updates are planned, made, and released.
• Configuration management and tracking of third-party and open-source components.
• Problem resolution, including how reported vulnerabilities are received, assessed, and fixed.
• Documentation for users, such as secure configuration guidance and end-of-support information.

For EU purposes, IEC 81001-5-1 is the most direct way to show that your software was developed to the "state of the art" for information security, as Annex I 17.2 requires. Whether a standard is formally harmonized under the MDR changes how much legal weight it carries, so check the current list of harmonized standards in the Official Journal of the European Union before relying on a presumption of conformity. Even without that status, Notified Bodies widely treat it as the reference for secure development.

For more depth, see our IEC 81001-5-1 explainer, the IEC 81001-5-1 vs IEC 62304 comparison, and our guide to security risk assessment under IEC 81001-5-1.

What a Notified Body will look for

Expect a Notified Body to look for cybersecurity evidence in your technical documentation, usually including:

1. A security risk assessment linked to your ISO 14971 risk file, showing how security threats could lead to hazards and harm.
2. A threat model of the device, its interfaces, and the systems it connects to.
3. Security requirements and architecture that trace to the threats you identified.
4. A software bill of materials (SBOM) and a process for monitoring those components for vulnerabilities.
5. Security test evidence, including penetration testing, with findings resolved or justified.
6. Instructions for use covering minimum IT security requirements, secure setup, and user responsibilities.
7. A postmarket plan for vulnerability monitoring, coordinated disclosure, and security updates.

Our EU MDR cybersecurity service builds this evidence in the format Notified Bodies expect.

Postmarket duties

Cybersecurity does not stop at the CE mark. Under the MDR and IVDR, your postmarket surveillance system must cover security issues the same way it covers other safety issues:

• Postmarket surveillance must actively gather information on vulnerabilities and attacks affecting your device and its components.
• Vigilance and serious incident reporting apply if a cybersecurity problem leads, or could lead, to a serious incident. Report under the same timelines as any other serious incident.
• Field safety corrective actions, such as a security patch that users must install, follow the normal field safety notice process.
• Periodic reports (the PSUR or PMS report, depending on device class) should summarize security monitoring and actions taken.

Other EU laws that may apply

Several newer EU laws come up in security discussions. Here is how each relates to medical devices:

Because these laws overlap in complex ways, confirm which apply to your company and product with regulatory counsel.

Common gaps we see

• Security risk kept separate from the safety risk file, with no link between threats and patient harm.
• Instructions for use that skip IT security requirements, even though Annex I requires them.
• An SBOM with no monitoring process behind it.
• Test reports that list findings but do not trace them back to the risk assessment or show how they were closed.
• No plan for end of support, leaving users unsure how long security updates will last.

How Blue Goat Cyber approaches this

We build one cybersecurity evidence base that serves both the EU and the FDA. That includes the threat model, security risk assessment tied to ISO 14971, SBOM and vulnerability monitoring, penetration testing, and the documentation Notified Bodies expect. We have supported 275+ devices, and we focus only on medical device cybersecurity.

FAQ

Is cybersecurity mandatory for medical devices in the EU?

Yes. Annex I of the MDR and IVDR requires devices with software to address information security, protect against unauthorized access, and state minimum IT security requirements. A Notified Body checks this during conformity assessment.

Is IEC 81001-5-1 required under the EU MDR?

The MDR does not name a specific standard. IEC 81001-5-1 is the most common way to show that software was developed to the state of the art for information security. Check the Official Journal for its current harmonized status.

Does the Cyber Resilience Act apply to medical devices?

No, not to products covered by the MDR or IVDR. Separate companion products that are not medical devices may fall under it, so review each product in your system.

What is MDCG 2019-16?

MDCG 2019-16 Rev.1 is EU guidance from the Medical Device Coordination Group on how to meet the MDR and IVDR cybersecurity requirements. Notified Bodies use it as their main reference.

Can I reuse my FDA cybersecurity documentation in the EU?

Mostly. The threat model, SBOM, risk assessment, and test evidence carry over well. The format, the legal references, and some postmarket duties differ. Our EU MDR vs FDA crosswalk shows what changes.

Next steps

If you are preparing an EU technical file, start with a discovery call and we will tell you where your cybersecurity evidence stands. You can also read the EU medical device cybersecurity FAQ.

Sources and primary references

• Regulation (EU) 2017/745 (MDR)
• Regulation (EU) 2017/746 (IVDR)
• MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices
• IEC 81001-5-1:2021
• Regulation (EU) 2024/2847 (Cyber Resilience Act)
• Directive (EU) 2022/2555 (NIS2)
• Regulation (EU) 2024/1689 (AI Act)