Cybersecurity for Medical Devices: What the MDR, IVDR, and IEC 81001-5-1 Require

Do you have any questions?

Cybersecurity is not an optional extra for medical devices, but rather part of the general safety and performance requirements. The MDR and IVDR require that products containing software be developed using state-of-the-art technology and be protected against unauthorized access. These requirements apply not only at the time of conformity assessment but throughout the entire life cycle, from the concept phase to the end of the support period.

This results in two tasks for manufacturers. Before a product is placed on the market, security requirements must be incorporated into design and development, risk management, and technical documentation. After the product is placed on the market, vulnerabilities must be identified, reviewed, and remedied, in some cases with reporting obligations to regulatory authorities and the Notified Body.

This article outlines the legal framework of the Medical Device Regulation (MDR), Regulation (EU) 2017/745, and the In Vitro Diagnostic Medical Device Regulation (IVDR), Regulation (EU) 2017/746, describes the relevant standards and guidelines, and demonstrates how the requirements can be implemented in practice.

Legal basis in the MDR and IVDR

The key requirements are set forth in Annex I of both regulations. According to Annex I, Section 17.2 of the MDR and Annex I, Section 16.2 of the IVDR, medical devices incorporating software must be developed and manufactured in accordance with the state of the art. Specifically mentioned are the software life cycle, risk management - including information security - as well as verification and validation.

Annex I, Section 17.4 of the MDR and Annex I, Section 16.4 of the IVDR supplement the perspective of the intended use environment. Manufacturers must define and communicate minimum requirements for hardware, the characteristics of IT networks, and IT security measures. For programmable products, both regulations additionally require that the risk of unauthorized access be minimized as much as possible.

These requirements are formulated in general terms. They are specified in more detail through general risk management pursuant to Article 10 of the MDR and Article 10 of the IVDR, through ISO 14971, and through guidelines and standards. It is important to distinguish between the terms “safety” (protection of patients and users from harm) and “security” (protection of the product from unauthorized access and tampering). The two are interrelated. A security issue can become a safety issue.

Distinction from related legal acts

Medical devices and IVDs are subject to several cybersecurity legal acts. The following overview categorizes the key laws.

State of the art: MDCG 2019-16 and IEC 81001-5-1

MDCG 2019-16 is the authoritative European guideline on cybersecurity for medical devices and applies equally to MDR and IVDR products. It describes security-by-design and security-by-default, security-related risk management, and requirements for verification, validation, and the post-placement on the market phase.

IEC 81001-5-1 specifies security activities within the software life cycle for health software. It supplements IEC 62304 with security activities such as threat modeling, secure implementation, security testing, and vulnerability management. As things stand, neither standard is harmonized with the MDR or IVDR. Nevertheless, Notified Bodies consider them to represent the state of the art. While this does not confer a presumption of conformity, their application significantly simplifies the justification process.

In addition, in December 2025, the IEC published the interpretation sheet IEC 81001-5-1:2021/ISH1:2025, which, among other things, clarifies the handling of software components. For specific aspects, the IEC 62443 series of standards is also frequently referenced, particularly IEC 62443-4-1 for secure development processes.

Furthermore, depending on the product type, other MDCG documents may be relevant, particularly guidelines on Medical Device Software (MDSW), classification, PMS, and vigilance. Cybersecurity requirements should always be considered within the overall regulatory context.

Cybersecurity for medical devices: Requirements prior to placing on the market

Prior to conformity assessment, evidence must be presented in a transparent manner in the technical documentation. The following components are standard:

1. Security risk management: a dedicated process integrated with ISO 14971, including a threat model, attack vectors, and a review of the impact on patient safety and data integrity.
2. Security requirements: Derived from the threat model, including authentication, access control, encryption, logging, and secure update mechanisms.
3. Secure Design and development: Security-by-design and security-by-default, secure default configuration, and hardening.
4. Software Bill of Materials (SBOM): A state-of-the-art inventory of all software components, including third-party and open-source components, serving as the basis for subsequent vulnerability monitoring.
5. Verification and validation: Security tests, such as static analysis, fuzz testing, and penetration testing. The tests should be conducted by individuals who did not design the measures themselves.
6. Information for users and Operators: Minimum requirements for the IT environment and network operation; details on the support period; and instructions in the user manual in accordance with Annex I, Chapter III, No. 23 of the MDR or No. 20 of the IVDR.

Special considerations for in vitro diagnostic medical devices

For IVDs, the focus shifts from direct patient contact to the integrity of data and test results. Analytical systems and software are typically connected to laboratory information systems (LIS), middleware, and hospital IT systems. A manipulated or incorrectly transmitted result can lead to an incorrect diagnosis or treatment decision without any error being visible on the device itself. Interfaces, transmission paths, and the correct assignment of samples to patients must therefore be included in the threat model.

The following three scenarios warrant particular attention:

• For software used to interpret results - such as in genomic diagnostics - algorithm and database versions, as well as their updates, should be secured.
• In the case of companion diagnostics, an erroneous result can directly impact drug therapy.
• For devices for self-testing and associated apps, unprotected end devices and cloud connections are additional factors to consider.

For Class C and D products, the Notified Body conducts a more thorough review. For certain types of Class D products, the context of the EU’s reference laboratories also applies. This does not change the substantive security requirements but does increase the requirements for documentation quality.

Cybersecurity for medical devices: Requirements after placing on the market

The obligations do not end with the CE marking. The post-market surveillance process pursuant to Art. 83 et seq. of the MDR and Art. 78 et seq. of the IVDR must also capture safety-related information. This includes the ongoing monitoring of known vulnerabilities in both proprietary and third-party software components, typically based on the SBOM and public vulnerability databases.

Identified vulnerabilities must be reviewed and, where necessary, addressed through updates or other measures. The process should specify the timeframes for review, the decision-making process for corrective actions, and how users are notified. A defined procedure for reporting vulnerabilities by third parties is considered state of the art (Coordinated Vulnerability Disclosure, CVD).

If a serious incident occurs, the reporting obligations under Article 87 of the MDR or Article 82 of the IVDR apply. Field Safety Corrective Actions (FSCA) must then be reported accordingly. It must also be clarified whether a change qualifies as a substantial change and whether the Notified Body must be involved. The end of the support period should also be planned and communicated, as security updates will no longer be provided after that point.

Documentation for the Notified Body

Notified Bodies conduct structured cybersecurity testing. The Association of Notified Bodies (Interessengemeinschaft der Benannten Stellen für Medizinprodukte, IG-NB) publishes questionnaires and position papers on this topic to assist with preparation. Experience shows that the integration of safety and security, threat modeling, SBOM maintenance, and the conduct and effectiveness of security tests are particularly scrutinized. If the manufacturer deviates from EN IEC 81001-5-1, the rationale should be clear and documented.

Practical approach

• First, clarify the legal framework: Determine which requirements from the MDR or IVDR apply and which related regulations affect your product, your components, and your company.
• Establish a security risk management system and link it to risk management in accordance with ISO 14971. This can be done either as a standalone, linked process or as an integrated part of the overall risk management system.
• Implement the SBOM early on and maintain it automatically. The SBOM serves as the basis for vulnerability monitoring after placing on the market.
• Plan security testing as an integral part of verification and document the independence of the testers.
• Establish processes for vulnerability management, updates, and reporting channels before the first incident occurs.

FAQ

Do the MDR and IVDR explicitly require cybersecurity?

Yes. Both regulations require design and development in accordance with the state of the art, considering information security and risk management, along with details on IT security measures.

Does the Cyber Resilience Act apply to medical devices?

No. Medical devices and IVDs covered by the MDR or IVDR are excluded from the Scope of the Act. However, the Act may still be relevant if components are purchased from third parties or products are distributed outside the scope of the MDR and IVDR.

Must EN IEC 81001-5-1 be applied?

There is no formal requirement to do so. Furthermore, the standard is not harmonized. However, it is considered state of the art. Any deviation should be justified and documented.

Do the same requirements apply to IVDs?

Yes, the framework is identical. For IVDs, the focus is more on the integrity of measurement data and test results, as well as on the interfaces with laboratory and hospital IT systems.

How long must security updates be provided?

Neither the MDR nor the IVDR specifies a fixed timeframe. The decisive factor is the support period defined and communicated by the manufacturer, which should be based on the product’s expected service life.

Conclusion

For medical devices and IVDs, cybersecurity is an ongoing process, not a one-time demonstration of compliance. Incorporating security risk management, SBOM, testing, and vulnerability management early on reduces the need for rework during the conformity assessment and helps prepare for post-market incidents.

Would you like to know where your product and documentation stand in these areas? During an initial consultation, we’ll assess your current situation and make the designation of the next logical steps.

Do you have any questions?

This article is intended solely for general informational purposes and does not constitute legal advice. All content was reviewed by experts prior to publication and is regularly checked for currency, completeness, and accuracy. Despite careful preparation and quality control, errors, omissions, or changes in the legal situation that have occurred in the meantime cannot be ruled out.