MDCG 2019-16: Guidance on Cybersecurity for Medical Devices

MDCG 2019-16 Rev.1 (December 2019, revised July 2020) is the European guidance document for cybersecurity under MDR and IVDR. It defines minimum IT requirements, verification and validation expectations for security, the cybersecurity risk assessment approach, and the post-market surveillance and vigilance duties that apply to security incidents. It maps closely onto EN IEC 81001-5-1:2022, and in 2026 notified body practice the two documents are read in tandem.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

• MDCG 2019-16 Rev.1 is the authoritative Medical Device Coordination Group guidance on cybersecurity under MDR and IVDR.
• The document covers minimum IT requirements, cybersecurity risk management, secure design, verification and validation, post-market surveillance, and vigilance.
• MDCG 2019-16 Rev.1 maps closely onto EN IEC 81001-5-1:2022. A process built against the standard will cover almost everything the guidance asks for.
• Cybersecurity is lifecycle, not launch. A device secure on day one can become insecure when a SOUP library publishes a CVE. The guidance makes continuous monitoring explicit.
• In Tibor's audit experience, the most frequently missed sections are the vulnerability disclosure process and the post-market cybersecurity surveillance plan.

Why the guidance exists

MDR Annex I Section 17 is short and dense. §17.2 tells manufacturers to use a state-of-the-art software lifecycle with information security built in. §17.4 tells them to set out minimum IT security requirements. Neither paragraph explains how. That explanation lives in MDCG 2019-16.

The Medical Device Coordination Group issued MDCG 2019-16 in December 2019, shortly after MDR entered into force. Revision 1 followed in July 2020 with clarifications and a few corrections. The document is not legally binding in the strict sense. It is guidance. But notified bodies treat it as the primary interpretation reference for what Section 17 means in practice. A file that ignores MDCG 2019-16 is a file that creates friction with its notified body.

What MDCG 2019-16 Rev.1 actually covers

The document is structured around the full security lifecycle. It is longer than a regulation paragraph but shorter than a standard. A startup should read it end to end at least once. The main sections cover:

Scope and definitions. MDCG 2019-16 Rev.1 defines the cybersecurity vocabulary it uses, aligned with international references. Terms like asset, threat, vulnerability, exploit, and risk are set out so that manufacturers, notified bodies, and authorities speak the same language.

Secure design and manufacture. This is the §17.2 territory. The guidance expects the manufacturer to integrate security into the software development lifecycle, not to bolt it on at the end. Concepts like defence in depth, least privilege, secure coding, and secure architecture are explicitly called out.

Documentation. The guidance expects the technical documentation to show evidence of the secure development lifecycle, the security risk assessment, the verification and validation activities, and the post-market surveillance plan for security. This is what notified bodies look for at file review.

Minimum IT requirements. The guidance is explicit that §17.4 requires the manufacturer to specify the minimum conditions needed for the software to run securely. Hardware, operating system, network, and physical environment assumptions must all be declared. Users must be told.

Verification and validation. Security V&V is not the same as functional V&V. The guidance expects threat-based testing, penetration testing where appropriate, vulnerability scanning, and documented evidence that security requirements have been met.

Risk management integration. Security risks are patient safety risks and must be managed inside the EN ISO 14971:2019+A11:2021 risk management file. The guidance is very clear that a standalone security risk document disconnected from the 14971 file is not sufficient.

Post-market surveillance and vigilance. The guidance covers cybersecurity incidents as post-market events. Manufacturers must monitor, respond to, and where necessary report security incidents under the MDR vigilance framework (Articles 83 to 92).

Information for users. The minimum IT security requirements from §17.4 must reach the user in the instructions for use and, where needed, a dedicated security guidance annex.

How MDCG 2019-16 Rev.1 maps to EN IEC 81001-5-1:2022

In Tibor's practical reading of both documents (and Q3 of the second interview round made this explicit), MDCG 2019-16 Rev.1 aligns closely with EN IEC 81001-5-1:2022 in structure and intent. The mapping is not one-to-one paragraph by paragraph, but the topics match.

The practical consequence for a startup is that building a secure development lifecycle against EN IEC 81001-5-1:2022 will cover almost everything MDCG 2019-16 Rev.1 expects. The reverse is not as clean. Starting from MDCG 2019-16 Rev.1 alone leaves gaps that EN IEC 81001-5-1:2022 fills with concrete clause-level activities.

Minimum IT requirements in practice

The "minimum IT requirements" concept is one of the most practically useful parts of MDCG 2019-16 Rev.1. The idea is simple. The manufacturer has control over the device and the software the manufacturer produces. The manufacturer does not have control over the hospital network, the user's smartphone, or the home router. The guidance acknowledges this and asks the manufacturer to set out what the environment must look like for the software to run as intended from a security perspective.

For a typical connected medical device in 2026, minimum IT requirements look something like this:

• Host platform. Operating system name, minimum version, patch level, security features (for example, platform-level app sandboxing).
• Network. Required transport encryption (for example, TLS 1.2 or higher), required server certificate validation, firewall rules.
• Authentication. User authentication requirements, minimum password or credential policy, session timeout, multi-factor where appropriate.
• Physical environment. Device location expectations, tamper-evidence assumptions, access control around the device.
• Maintenance: who is expected to apply security updates and on what cadence.

These are not preferences. They are conditions of safe use. If the device is operated outside these conditions, the safety case does not hold. The guidance expects these requirements to be declared in the technical documentation and communicated to the user in the instructions for use.

A worked example: the hospital-deployed diagnostic software

Consider a Class IIa diagnostic software product deployed on hospital workstations and connected to the hospital imaging archive over DICOM.

A MDCG 2019-16 Rev.1-aligned package for this product includes:

• A security risk assessment integrated into the EN ISO 14971:2019+A11:2021 risk file, identifying assets (patient images, diagnostic results), threats (unauthorised access to results, tampering with diagnostic outputs), and controls (authentication, encryption in transit, audit logs).
• A secure development lifecycle document that references EN IEC 81001-5-1:2022 and EN 62304:2006+A1:2015 together, with security activities traced to lifecycle phases.
• Verification evidence, including penetration test results against the DICOM interface and the user authentication path.
• Minimum IT requirements: supported Windows versions, required TLS configuration, required network segmentation recommendation, required user account policy.
• A post-market cybersecurity surveillance plan that covers CVE monitoring for the SBOM components, a named responsible person, and a communication path to users for security advisories.
• A documented vulnerability disclosure process with a published contact point.
• Instructions for use that communicate the minimum IT requirements in plain language to the hospital IT team.

This is the package a 2026 notified body reviewer will look for when the file lands on the desk.

The Focused Path

Felix frames it this way for startups. MDCG 2019-16 Rev.1 is not a document to comply with by writing another document. It is a checklist to cross-reference against the engineering artefacts that already exist. The Subtract to Ship approach is:

Step 1. Print MDCG 2019-16 Rev.1. Read it end to end once. Mark the sections that apply to the device.

Step 2. For each marked section, identify the single existing document in the technical file that already covers (or should cover) that content. Software development plan. Risk management file. V&V report. PMS plan. Instructions for use.

Step 3. Where the existing document already covers the topic, add a cross-reference to MDCG 2019-16 Rev.1 and the matching EN IEC 81001-5-1:2022 clause. Where the existing document has a gap, close the gap inside that document, not in a new parallel document.

Step 4. Produce one short "cybersecurity conformity matrix" that maps MDCG 2019-16 Rev.1 sections to technical file locations. This is the single document the notified body will thank you for. It is not the evidence itself. It is the map.

Step 5. Treat the vulnerability disclosure process and the post-market cybersecurity surveillance plan as first-class deliverables. These are the two items Tibor sees most frequently missing in startup files.

Produce one short "cybersecurity conformity matrix" that maps MDCG 2019-16 Rev.1 sections to technical file locations.

Practical Implications

1. Has MDCG 2019-16 Rev.1 been read end to end by the person responsible for the security file?
2. Is there a single cybersecurity conformity matrix that maps MDCG 2019-16 Rev.1 sections to technical file locations?
3. Are security hazards represented inside the EN ISO 14971:2019+A11:2021 file, not in a parallel document?
4. Are the minimum IT requirements documented, dated, and communicated to the user in the instructions for use?
5. Has penetration testing been performed by an independent party and are the results closed or justified?
6. Is the software bill of materials updated on every software release and monitored for new CVEs?
7. Is there a named individual responsible for cybersecurity post-market surveillance, with a defined escalation path?
8. Is there a published vulnerability disclosure contact and a documented internal triage procedure?

Frequently Asked Questions

Is MDCG 2019-16 legally binding?

MDCG guidance documents are not legally binding in the strict sense. They express the consensus interpretation of the Medical Device Coordination Group. In practice, notified bodies follow them closely. A file that deviates from MDCG 2019-16 Rev.1 without justification will attract questions.

Does MDCG 2019-16 Rev.1 apply to IVDR as well?

Yes. The document explicitly covers both MDR and IVDR. The cybersecurity expectations are the same whether the device is regulated as a medical device or as an in-vitro diagnostic.

Is Rev.1 the current version?

Rev.1 was issued in July 2020. As of the publication date of this article, it remains the current version of MDCG 2019-16. Any subsequent revision should be checked directly on the European Commission MDCG page before citing.

How does MDCG 2019-16 Rev.1 treat software updates?

Software updates that change the security posture must go through change control. The guidance expects the manufacturer to have a process for evaluating, verifying, validating, and communicating security updates, and for triggering post-market surveillance notifications where relevant.

What is the role of the SBOM in MDCG 2019-16 Rev.1?

MDCG 2019-16 Rev.1 expects manufacturers to know what components make up their software and to monitor those components for vulnerabilities. The SBOM is the practical embodiment of that expectation. EN IEC 81001-5-1:2022 makes the SBOM obligation explicit.

Is a penetration test required?

MDCG 2019-16 Rev.1 expects verification and validation activities appropriate to the security risk of the device. For most connected devices, a penetration test is the most credible way to produce that evidence. In Tibor's experience, notified bodies increasingly expect to see independent pentest results for any Class IIa or higher connected device.

Related reading

• Cybersecurity for Medical Devices Under MDR: A Startup Guide for 2026, for the foundational overview.
• MDR Annex I Section 17: Cybersecurity Requirements, for the underlying regulatory text.
• SBOM for Medical Devices under MDR, for the software bill of materials piece.
• MDR PMS Framework: Articles 83 to 86, for how cybersecurity incidents plug into post-market surveillance.

Sources

1. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices (December 2019, revised July 2020), Medical Device Coordination Group.
2. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2 and §17.4. Articles 83 to 92 (Post-market surveillance and vigilance).
3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle.
4. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.
5. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.