What cybersecurity requirements apply to a medical device under the MDR?

MDR Annex I requires software development according to the state of the art including information security (section 17.2), the definition of minimum hardware, network and IT security requirements, including protection against unauthorised access (17.4), and for active devices, protection against unauthorised access that could hamper their functioning (18.8). MDCG 2019-16 details implementation.

Does the Cyber Resilience Act apply to medical devices?

No. Regulation (EU) 2024/2847 excludes products covered by the MDR and IVDR from its scope; their cybersecurity is governed by those regulations.

A Software Bill of Materials is the list of a product's software components, including third-party and open-source libraries. It makes it possible to identify quickly whether a device is affected by a published vulnerability. The FDA has required it in submissions for cyber devices since 2023.

Is cybersecurity part of risk management?

Yes. IT security threats are sources of hazards to be addressed in the risk management process (ISO 14971), alongside a dedicated security analysis, and followed after market entry like any other surveillance data.

Medical device cybersecurity: MDR, MDCG and FDA

A connected medical device inherits the risks of any IT system: unauthorised access, malware, a vulnerable third-party library. For a patient, these risks can become clinical. Regulators have built this in: cybersecurity is now a compliance requirement in its own right, in Europe and in the United States. This guide takes stock.

What the MDR requires

The MDR has no "cybersecurity" chapter, but its general safety and performance requirements (Annex I) cover it:

Section 17.2: software is developed and manufactured according to the state of the art, taking into account the life cycle, risk management including information security, verification and validation.
Section 17.4: the manufacturer sets out minimum requirements for hardware, IT network characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.
Section 18.8: active devices are designed to protect, as far as possible, against unauthorised access that could hamper their functioning.

The IVDR contains equivalent requirements.

MDCG 2019-16

MDCG 2019-16, revised in 2020, explains how to meet these requirements. It stresses several points:

security by design and across the life cycle;
the link between security and safety in risk management;
information to provide to users and institutions: required IT environment, measures expected from the operator, end of support;
post-market surveillance of vulnerabilities and patch deployment;
shared responsibility between manufacturer and healthcare provider.

Useful standards

IEC 81001-5-1: secure life cycle processes for health software, complementing IEC 62304.
IEC 62304: medical device software life cycle.
ISO 14971: IT threats are a source of hazards to integrate into risk management.
IEC/TR 60601-4-5: security capabilities of networked medical electrical equipment.
AAMI TIR57: security risk management for medical devices.

Neighbouring EU texts

The Cyber Resilience Act (Regulation (EU) 2024/2847) excludes products covered by the MDR and IVDR: a medical device's cybersecurity remains governed by those regulations.
The NIS 2 Directive (Directive (EU) 2022/2555) covers, depending on their size, manufacturers of medical devices and in vitro diagnostic devices (Annex II). It addresses the security of organisations (governance, incident handling, notification) rather than of products.
The AI Act adds robustness and cybersecurity requirements for high-risk AI systems, which apply to medical devices from 2 August 2028; see our article on the AI Act timeline.

What the FDA requires

In the United States, section 524B of the FD&C Act, introduced at the end of 2022 and applicable to submissions since 29 March 2023, requires for cyber devices (including software, able to connect to the internet and potentially vulnerable):

a plan to monitor, identify and address post-market vulnerabilities, including coordinated disclosure;
processes providing reasonable assurance that the device and related systems are secure, with updates and patches;
an SBOM (Software Bill of Materials), the list of software components, including commercial and open-source ones.

The FDA guidance on cybersecurity in quality systems and premarket submissions details the expected content.

After market entry

Cybersecurity does not stop at CE marking:

monitor vulnerabilities published on the device's components, notably CISA advisories;
assess their impact on safety and performance, within risk management;
fix and communicate, through patches or safety notices, and report through vigilance when a serious incident or field safety corrective action is at stake;
feed these elements into the PSUR and the post-market surveillance plan.

Frequent findings

A risk analysis with no security part, or a security analysis disconnected from ISO 14971.
No up-to-date SBOM, making it impossible to know whether a published vulnerability affects the device.
IT environment requirements missing from the instructions, contrary to section 17.4.
No patch process and no announced end of support.
Vulnerability monitoring left out of the post-market surveillance plan.

Guidance, standards and vulnerability advisories move fast: cybersecurity is one of the topics where medical device regulatory monitoring has the greatest impact.

Medical device cybersecurity: MDR, MDCG and FDA requirements

Key takeaways