Cybersecurity for medical devices: MDCG 2019-16 implementation guide

Why cybersecurity has moved to the top of NB review checklists

Three years ago, cybersecurity documentation was often an afterthought in SaMD technical files — a single paragraph in the risk management file acknowledging that software could be vulnerable to attack. Today, Notified Bodies — see our NB selection guide — have dedicated cybersecurity reviewers and structured questionnaires based on MDCG 2019-16. Technical files that treated cybersecurity as a checkbox routinely receive major non-conformities.

The regulatory pressure comes from multiple directions simultaneously. EU MDR GSPR 17.2 explicitly requires manufacturers to address information security. MDCG 2019-16 defines what that means in practice. The EU AI Act (from August 2026) adds cybersecurity governance requirements for AI systems. And IEC 62304's 2015 amendment embedded cybersecurity into the software lifecycle standard. For connected SaMD in 2026, cybersecurity is not optional — it is a first-class certification requirement.

MDCG 2019-16: the framework

MDCG 2019-16 structures cybersecurity for medical devices around a pre-market and post-market framework, consistent with how other medical device safety requirements are structured.

Pre-market: security by design

Security by design means that cybersecurity requirements are defined and implemented during development — not added as a compliance exercise before submission. MDCG 2019-16 expects manufacturers to:

• Define a security architecture that identifies network interfaces, data flows, trust boundaries, and security controls at the design level. For SaMD, this means documenting how data enters and exits the system, what authentication and access controls are in place, and how data is protected in transit and at rest.
• Conduct threat modelling using a structured methodology (STRIDE, PASTA, or equivalent) to systematically identify potential attack vectors, the assets they could compromise, and the clinical harm that could result. The threat modelling must be documented and must connect to the security risk management process.
• Define minimum security requirements — the security features that the device must implement: authentication and authorisation, encryption for data in transit and at rest, audit logging, session management, and vulnerability management. These requirements must appear in the software requirements specification and be traceable to test evidence.

Security risk management

The security risk management process runs parallel to the ISO 14971 safety risk management process and should be documented in the Security Risk Management File. For each identified threat:

• Estimate the likelihood of successful exploitation (considering attacker capability, attack surface, and existing controls)
• Evaluate the potential impact on patient safety, device functionality, and data confidentiality/integrity
• Document security controls that mitigate the threat
• Assess residual security risk after controls
• Conclude on acceptability using pre-defined security risk acceptability criteria

Security testing

MDCG 2019-16 expects manufacturers to conduct security testing appropriate to the device's connectivity and risk profile. For most connected SaMD, this means:

• Penetration testing: Conducted by qualified security testers on a representative production system. The test scope should cover the threat model. Test reports must document scope, methodology, findings, severity ratings, and remediation status.
• Vulnerability scanning: Automated and manual vulnerability scanning of the software codebase and dependencies. OWASP Top 10, CVE database checking for known vulnerabilities in SOUP components.
• Security test cases in the V&V suite: Specific test cases in your software system testing that verify security requirements are met — authentication works correctly, access controls enforce separation of privilege, injection attacks are blocked.

Post-market cybersecurity obligations

Cybersecurity does not stop at certification. MDCG 2019-16 requires ongoing post-market cybersecurity management, which must be integrated into your QMS and post-market surveillance process:

• Vulnerability monitoring: Active monitoring of vulnerability databases (NVD, vendor security advisories, CERT/CC) for newly discovered vulnerabilities in your SOUP components and underlying platforms. Many SaMD teams do not have a formal process for this — and the result is deployed devices running software with known critical vulnerabilities.
• SBOM maintenance: The Software Bill of Materials (or equivalent SOUP list) must be kept current and must feed into vulnerability monitoring. The December 2025 Singapore HSA guidance update explicitly requires OS end-of-life planning — this is increasingly an expectation in EU and UK as well.
• Coordinated vulnerability disclosure: A documented process for receiving and responding to security vulnerability reports from external researchers or customers. MDCG 2019-16 expects manufacturers to have a published security contact and a defined response process.
• Security patch management: A defined process for evaluating, developing, testing, and deploying security patches, integrated with your change control process. Security patches that affect safety-critical functionality require the same change control rigor as clinical functionality changes.

EU AI Act cybersecurity obligations (from August 2026)

For AI-powered SaMD, the EU AI Act introduces additional cybersecurity-related obligations from August 2026 that partially overlap with MDCG 2019-16. Specifically, the AI Act requires high-risk AI systems (which include most Class IIa+ AI SaMD) to be designed with resilience against adversarial attacks — attempts to manipulate model outputs by crafting adversarial inputs.

For AI medical software, this means the security risk management must explicitly address adversarial machine learning attacks: data poisoning (manipulation of training data), model inversion (reconstructing training data from model outputs), and adversarial examples (inputs designed to fool the model). While MDCG 2019-16 does not explicitly address these, the AI Act's requirements mean they must now be included in the security risk assessment for AI SaMD.