Medical Device Cybersecurity: EU MDR and FDA Requirements

For a medical device manufacturer, cyber security is not an IT function. It is a regulatory requirement embedded in the device's safety case, and it is assessed before the device reaches the market as well as monitored after it. That makes it a quality and regulatory affairs responsibility, which is not where most organisations instinctively put it. Our CPD course library covers quality, compliance and regulatory training.

Where the EU requirement sits

Under the EU Medical Device Regulation, the general safety and performance requirements in Annex I address software and IT security directly.

GSPR 17.2 requires that software be designed to ensure repeatability, reliability and performance in line with its intended use, with measures taken to eliminate or reduce risks arising from software faults. GSPR 17.4 goes further and requires manufacturers to set out minimum requirements concerning hardware, the characteristics of IT networks, and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

That last requirement is the one teams underestimate. It obliges the manufacturer to specify the security conditions under which the device is safe to operate, and to communicate them. A hospital that connects a device to a flat network is operating outside those conditions, and the manufacturer has to have stated them for that distinction to exist at all.

The Medical Device Coordination Group's guidance on cybersecurity for medical devices sets out how this is expected to be evidenced, covering secure design, verification, and the division of responsibility between manufacturer and operator. The equivalent provisions apply to in vitro diagnostics under the IVDR.

The US position changed in 2023

The Consolidated Appropriations Act 2023 added section 524B to the Federal Food, Drug, and Cosmetic Act, creating explicit premarket cybersecurity obligations for "cyber devices". A submission must include a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits, processes providing reasonable assurance that the device and related systems are cybersecure, including making postmarket updates and patches available, and a software bill of materials covering commercial, open-source and off-the-shelf components.

From 1 October 2023 the FDA began refusing to accept submissions that did not contain this information. That is a procedural gate rather than a review finding: an incomplete submission does not get assessed.

The software bill of materials is the element that most often exposes a gap, because it requires knowing precisely what third-party and open-source components a device contains. Organisations that have never assembled one usually discover the inventory does not exist in any single place.

Why this is a QMS problem, not a security project

Both regimes treat cybersecurity as part of the product lifecycle, which means it lands inside the quality management system rather than alongside it.

Risk management has to treat security threats as a source of harm, not only safety failures. Design controls have to show that security requirements were specified, implemented and verified. Postmarket surveillance has to monitor vulnerability disclosures for the components in the device, not only complaints about its function. And vigilance reporting has to consider whether an exploited vulnerability constitutes a reportable incident.

The competence requirements follow from that. Personnel performing these activities need demonstrable training records, which is the same expectation that applies across the quality system — a point we cover in FDA QMSR and ISO 13485 training and competence requirements.

Who owns it inside the organisation

In the EU, the person responsible for regulatory compliance carries defined duties over conformity, technical documentation and postmarket surveillance. Cybersecurity obligations sit within that scope rather than outside it, which makes the role the natural coordination point between engineering, quality and regulatory affairs. Our guide to the PRRC under MDR Article 15 sets out those responsibilities.

The practical failure mode is predictable. Security work gets done by engineers, documented in engineering tools, and never surfaces in the technical documentation in a form an assessor recognises. The work existed; the evidence did not.

Manufacturers are also in scope as entities

Separately from product requirements, the manufacture of medical devices and in vitro diagnostic devices appears among the sectors covered by the EU's NIS2 Directive. A manufacturer can therefore face organisational cybersecurity and governance duties as an entity at the same time as product obligations under MDR, and the two are assessed by different authorities against different criteria.

That matters for how the work is organised. Board-level approval and oversight duties under NIS2 are not satisfied by a strong product security file, and a strong product security file is not evidence of entity-level governance. We cover the governance side in board cyber governance.

Frequently asked questions

Does a device without network connectivity need cybersecurity documentation?

GSPR 17 applies to devices incorporating software regardless of connectivity, and risks can arise through maintenance interfaces, removable media and service tooling. Connectivity changes the threat profile; it does not determine whether the requirement applies.

Is a software bill of materials required in the EU as well?

An SBOM is explicitly named in the US requirement. In the EU the obligation is framed around demonstrating that risks from software have been addressed, and component inventory is in practice how manufacturers evidence that. Many maintain one for both markets rather than two approaches.

Who is responsible if a hospital runs the device on an insecure network?

The manufacturer must specify the minimum IT security conditions for safe use. The operator is responsible for deploying within them. Disputes usually turn on whether the manufacturer's specification was adequate and clearly communicated, which is why GSPR 17.4 documentation matters commercially as well as regulatorily.

Does legacy equipment have to be brought up to current expectations?

Devices already on the market remain subject to postmarket surveillance and vigilance obligations, so known exploited vulnerabilities cannot simply be left. What is proportionate depends on the risk and the device's remaining lifecycle, and should be reasoned and documented rather than assumed.