Cybersecurity Requirements for SaMD Under EU MDR

Why cybersecurity is a safety issue, not just an IT issue

This is the reframe that matters most: under EU MDR, cybersecurity is treated as a patient safety concern, not a data security or IT operations concern. A cyberattack that corrupts a diagnostic output, or ransomware that takes a clinical system offline, creates patient safety risk. That's why cybersecurity requirements live in the GSPR — the General Safety and Performance Requirements in Annex I — not in a separate IT annex.

GSPR 17.2 is the specific provision: devices that incorporate software or that are software themselves must be developed and maintained in a way that ensures adequate levels of security for the environments in which they are used, including protection against unauthorised access that could compromise safety and performance. The key phrase is "environments in which they are used" — you need to understand how and where your software runs, what the realistic threat landscape looks like, and build your security measures around that.

MDCG 2019-16 rev.2 — the practical guide

MDCG 2019-16 rev.2 is the guidance document that tells you what "adequate cybersecurity" actually looks like in a technical file. It covers the full device lifecycle: from secure design through deployment to end of life. The document introduced a structured approach that has since become the de facto standard for what Notified Bodies expect.

The key elements the guidance requires you to address:

Threat modelling and security risk assessment — a systematic process to identify threats, assess likelihood and impact, and determine security controls. This is where the integration with ISO 14971 lives. Security threats are hazards; successful exploitation of those threats is a hazardous situation; patient harm is the harm event. Run it through your risk management process.

Security requirements — derived from your threat model. Authentication requirements, access control rules, data integrity protections, audit logging, encryption requirements. These need to be documented as formal requirements and traced through your IEC 62304 development process.

Secure design — architectural decisions that reduce attack surface: least privilege access, input validation, secure communications (TLS, certificate pinning), dependency management. Document design choices and the rationale for them.

Vulnerability management — a process for discovering, assessing, and addressing vulnerabilities in your software and its dependencies across the product lifecycle. This includes monitoring public vulnerability databases (CVE/NVD) for vulnerabilities in third-party libraries you use.

End-of-life planning — when do you stop supporting security updates? What happens to users on older versions? MDR requires you to have a plan.

Integrating cybersecurity into ISO 14971

The most common structural mistake teams make is treating cybersecurity risk as a separate analysis alongside their ISO 14971 risk file. MDCG 2019-16 rev.2 is explicit: cybersecurity risks belong in your main risk management file. The threat model informs the hazard identification. Security controls are risk control measures. Residual risk from cybersecurity threats contributes to the overall benefit-risk conclusion.

In practice, this means:

1. Your risk management plan should explicitly include cybersecurity risks in scope.
2. Your hazard identification should include cybersecurity threats (unauthorised access, data integrity attacks, availability attacks, spoofing, tampering).
3. Security controls should be documented as risk mitigations with verification evidence.
4. Your risk management report should address residual cybersecurity risk and include it in the overall benefit-risk analysis.

If your ISO 14971 file doesn't mention cybersecurity at all, that's a gap. A Notified Body will find it.

What good looks like at different device classes

Class I SaMD: even without Notified Body review, GSPR 17.2 still applies. Document your threat model and security controls in your technical file. It doesn't need to be elaborate, but it needs to be present and proportionate to the threat environment your software operates in.

Class IIa: expect Notified Body questions about your security requirements, how they were derived, and how you tested them. Your V&V records should include security testing.

Class IIb and III: full scrutiny. Your threat model, security architecture, penetration testing evidence, and vulnerability management process will all be reviewed. For software that connects to networks, processes sensitive patient data, or integrates with hospital IT infrastructure, penetration testing by a qualified third party is effectively expected.

The post-market dimension

One thing that surprises teams: cybersecurity obligations don't stop at launch. Your PMS system must include monitoring for new cybersecurity vulnerabilities and threats. If a significant new vulnerability is discovered in a library your software uses, you need to assess it, decide on a response, and act on that response — including patching and potentially issuing a Field Safety Corrective Action if patient safety could be affected.

Build a lightweight vulnerability monitoring process into your PMS from day one. It's much easier to maintain than to retrofit.

A note on the NIS2 and AI Act intersection

If your SaMD is deployed in a healthcare setting covered by NIS2 (Network and Information Security Directive 2), your organisation may have additional cybersecurity obligations beyond MDR. And if your software includes AI/ML components, the EU AI Act's security requirements for high-risk AI systems may also apply. These frameworks don't cancel each other out — you need to satisfy all of them. The resource on AI/ML as a medical device in this category covers the AI Act intersection in more detail.