Medical Device Cybersecurity: MDR, CRA and NIS2 Explained

Connected medical devices, cloud platforms and software as a medical device have turned cybersecurity from an IT topic into a core regulatory requirement. At the same time, the landscape has become hard to navigate: the MDR, the Cyber Resilience Act (CRA), NIS2, plus standards such as IEC 81001-5-1. This article clarifies which rules apply to the product, which to the company and which to companion software. It is written for manufacturers as well as for IT teams and software providers working for the medical device industry.

Three levels, three frameworks

The most important distinction first:

Level	Framework	What it covers
Medical device	MDR (EU) 2017/745	Product safety across the entire life cycle, including IT security
Company	NIS2 Directive (EU) 2022/2555 and national implementing laws	Information security of the organisation, risk management, reporting obligations
Other digital products	Cyber Resilience Act (EU) 2024/2847	Cybersecurity of products with digital elements that are not medical devices

A manufacturer can therefore fall under all three at once: under the MDR with its medical device, under NIS2 as a company, and under the CRA with a companion app that is not a medical device.

The MDR: cybersecurity is part of product safety

The MDR barely uses the word "cybersecurity", but it regulates the topic in the general safety and performance requirements of Annex I. The key sections are:

• Section 17.2: software must be developed according to the state of the art, taking into account the life cycle, risk management, verification, validation and information security.
• Section 17.4: manufacturers set out minimum requirements for hardware, IT networks and IT security measures, including protection against unauthorised access.
• Section 18.8: devices must be designed to protect, as far as possible, against unauthorised access that could hamper the device from functioning as intended.
• Sections 14.2 and 14.5: interaction with the IT environment and interoperability with other systems.
• Section 23.4: the instructions for use must state the minimum IT requirements and security measures.

Because cybersecurity is part of product safety, the notified body reviews it as part of the conformity assessment, which means always from class IIa upwards.

MDCG 2019-16 and IEC 81001-5-1

How to implement these requirements is described in the guidance document MDCG 2019-16 Rev. 1. It is not law, but notified bodies use it as their main reference. Its core expectations are security risk management linked to safety risk management under ISO 14971, security by design, testing, information for operators and post-market surveillance.

For the development process, IEC 81001-5-1 has become the state of the art. It extends the software life cycle of IEC 62304 with security activities in every phase: threat modelling, secure implementation, security testing, vulnerability handling and post-market updates. IT teams will find it familiar, as the standard is modelled on IEC 62443-4-1 from industrial IT.

In practice, notified bodies today expect, among other things:

• a threat model and a security risk analysis,
• a software bill of materials (SBOM), i.e. a list of all software components including third-party and open-source libraries,
• a process for vulnerability management and security updates throughout the device's lifetime,
• evidence from security testing, such as penetration tests.

The Cyber Resilience Act: not for medical devices, but for their ecosystem

The Cyber Resilience Act requires manufacturers of products with digital elements to implement security by design, vulnerability management and reporting. Products covered by the MDR or IVDR are explicitly excluded (Article 2(2)). For them, the MDR remains the more specific law.

The CRA is still relevant, however, for everything around the medical device that is not itself a device:

• companion apps without a medical intended purpose,
• gateways, routers or hardware components placed on the market separately,
• software components and libraries that suppliers distribute independently.

The deadlines: reporting obligations for actively exploited vulnerabilities and severe security incidents have applied since 11 September 2026, and the remaining obligations apply from 11 December 2027. For IT service providers and component manufacturers supplying the medical device industry, the CRA is therefore often more directly relevant than for the manufacturers themselves.

NIS2: obligations for the company

While the MDR and CRA regulate products, the NIS2 Directive targets organisations. The manufacture of medical devices and in vitro diagnostic medical devices is listed in Annex II under the "Manufacturing" sector. Manufacturers in scope are therefore important entities, provided they are at least medium-sized, which generally means 50 or more employees, or an annual turnover and balance sheet total each exceeding EUR 10 million.

Implementation happens through national law. In Germany, the NIS2 Implementation Act entered into force on 6 December 2025. The key obligations are:

• Registration with the national authority (in Germany, the BSI). The statutory registration deadline has passed; companies in scope that have not yet registered should do so immediately.
• Risk management measures, for example on access control, backups, crisis management, supply chain security and training.
• Reporting obligations for significant security incidents, with staged deadlines.
• Management accountability: senior management must approve and oversee the measures and undergo training.

Important for IT managers: NIS2 covers the entire corporate IT, from production through ERP and QMS software to email. An existing ISMS according to ISO 27001 is a good foundation but does not automatically cover every obligation.

What lies ahead

In December 2025, the European Commission published a proposal to revise the MDR and IVDR (COM(2025) 1023). Among other things, it provides for more detailed cybersecurity requirements and an obligation to report actively exploited vulnerabilities via EUDAMED, following the logic of the CRA. The proposal is currently being negotiated in Parliament and Council and is not yet law. Manufacturers who already work to IEC 81001-5-1 and run effective vulnerability management are well positioned for this development.

For the US market, Section 524B of the Federal Food, Drug, and Cosmetic Act also applies, under which the FDA requires an SBOM and a plan for monitoring vulnerabilities for "cyber devices", among other things.

Practical checklist

For manufacturers:

1. Build an inventory: which devices have software, interfaces or network access?
2. Link security risk management with ISO 14971 and include it in the technical documentation.
3. Align the development process with IEC 81001-5-1, and create and maintain an SBOM.
4. Define a vulnerability and update process for the entire device lifetime.
5. Check whether NIS2 applies and, if so, complete registration.
6. Check companion products without medical device status for CRA obligations.

For IT service providers and software suppliers:

1. Clarify whether your software is part of a medical device or placed on the market independently (MDR or CRA?).
2. Document secure development practices and be able to supply SBOMs.
3. Agree contractually how vulnerabilities are reported and updates provided.
4. Expect audits: manufacturers must evaluate and monitor their critical suppliers.

Conclusion

Cybersecurity in medical technology is not a single regulation but an interplay of product safety (MDR), corporate security (NIS2) and product security for the digital ecosystem (CRA). Separating these levels clearly allows responsibilities to be assigned and avoids duplicated work. The framework for this is a quality management system that treats security as an integral part of development, supplier control and market surveillance (see also ISO 13485 certification).

We work at the interface of QA, regulatory affairs and IT, so that security requirements are implemented within the system rather than alongside it. Learn more about our MedTech consulting.