MDCG 2019- 16 Guidance on Cybersecurity for Medical Devices

MDCG stands for Medical Device Coordination Group, an EU advisory group made up of representatives from Member States and chaired by the European Commission. It provides guidance to help manufacturers understand and apply medical device regulations consistently.

The MDCG 2019 16 guidance on cybersecurity for medical devices explains cybersecurity expectations under EU Regulation 2017/745 (MDR) and Regulation 2017/746 (IVDR). First published in December 2019 and revised in July 2020, it addresses security throughout the medical device lifecycle. The July 2020 revision, Rev. 1, remains listed in the European Commission's guidance directory.

This article explains the key recommendations and how manufacturers can apply them to protect device functionality, address patient safety risks, and support regulatory compliance.

Who Does MDCG 2019 16 Apply To?

The MDCG 2019- 16 guidance primarily addresses manufacturers of medical devices containing programmable electronic systems and software regulated as medical devices under the MDR or IVDR. Its recommendations are relevant to several categories of medical technology, regardless of whether a device connects directly to the internet.

These include:

• Software as a Medical Device (SaMD): Independent medical software used for diagnosis, qualifying clinical decision support applications, and medical imaging analysis tools.
• Connected medical devices: Infusion pumps, patient monitoring systems, connected diagnostic equipment, and implantable devices with communication capabilities.
• In vitro diagnostic devices: Laboratory analysers, automated diagnostic platforms, and software used for qualifying diagnostic purposes under the IVDR.
• Devices with embedded software: Medical equipment that relies on firmware, operating systems, communication modules, or software components supplied by external vendors.
• Devices without internet connectivity: Medical devices with USB connections, maintenance interfaces, local network access, or removable media used for software updates. These interfaces can still expose devices to security threats.

Applicability depends on the product's intended medical purpose and its qualification under the relevant EU regulation. Software used only to store, archive, or transfer health information does not automatically qualify as a medical device. 

Key Cybersecurity Requirements Under MDCG 2019 16

The MDCG 2019 16 guidance explains how existing cybersecurity provisions under the EU MDR and IVDR apply to medical devices. It does not establish separate certification requirements.

Annex I of both regulations sets out the General Safety and Performance Requirements (GSPRs). These cover risk management, software security, system interactions, protection against unauthorised access, and information supplied to users.

MDR and IVDR Cybersecurity Requirements Mapping

Manufacturers should determine which provisions apply based on the device's intended purpose, operating environment, architecture, and identified risks. Each applicable requirement should be linked to implemented controls and supporting verification records.

What Security Practices Does MDCG 2019 16 Recommend?

The security practices outlined in MDCG 2019 16 cover eight key areas to help manufacturers manage medical device cybersecurity throughout the lifecycle.

For example, a network-connected patient monitor could combine authenticated access, encrypted communication, security event logging, and controlled software updates. Each measure addresses a different potential weakness, reducing dependence on any single safeguard.

These 8 practices describe recommended security processes rather than eight separate legal controls that every medical device must implement identically.

Cybersecurity Risk Management and Patient Safety Under MDCG 2019 16

A cybersecurity vulnerability becomes a patient safety concern when its exploitation could affect the safe performance of a medical device. The guidance considers threats to data confidentiality, integrity, and availability, with particular attention to their potential clinical consequences.

Manufacturers need to distinguish between two related assessments:

• Cybersecurity risk assessment: Examines potential attackers, vulnerabilities, attack paths, exploitation conditions, and the consequences of a security incident.
• Safety risk management: Identifies hazardous situations, assesses possible patient harm, determines necessary safeguards, and evaluates remaining safety risks.

These assessments inform each other, but the likelihood of a successful cyberattack should not be treated as equivalent to the probability of clinical harm.

Identifying Security Threats That Affect Patient Safety

Begin by identifying assets whose compromise could affect device performance or patient care. These include medication settings, clinical measurements, firmware, authentication credentials, patient records, and communication interfaces.

Threat scenarios can involve manipulated treatment parameters, altered software, compromised remote access, weaknesses in external components, or interrupted device functions.

Each scenario needs to be assessed for its effect on normal operation and the hazardous situations it could create.

How to Implement MDCG 2019 16 Cybersecurity Guidance

Manufacturers can follow these steps to organise cybersecurity activities, assign responsibilities, and collect evidence needed to demonstrate regulatory conformity.

Step 1. Identify Applicable Regulatory Requirements and Device Security Scope

Start by confirming the device's intended medical purpose, regulatory status under the MDR or IVDR, and applicable Annex I provisions. Then establish exactly which components and external systems fall within the cybersecurity assessment.

Document the following:

Device architecture

• Identify hardware
• Firmware
• Applications
• Wireless connections
• Communication protocols
• APIs
• Cloud services

External dependencies 

• Record supplier components
• Connected equipment
• Supporting software services

Operating conditions

• Describe expected network environments
• Maintenance access points
• Reasonably foreseeable misuse

Regulatory traceability

• Create a matrix connecting applicable GSPRs to security requirements
• Planned implementation activities and supporting evidence

Accountability

• Assign cybersecurity tasks to engineering
• Quality management
• Regulatory affairs
• Relevant external suppliers

The output should be a documented security scope, an initial regulatory traceability matrix, and clearly assigned responsibilities for subsequent activities.

Step 2. Implement Risk Based Cybersecurity Controls

Once the security risks are identified, convert them into clear requirements and select controls that can be tested for effectiveness. Section 3.3 of the guidance discusses security capabilities manufacturers can consider based on the device's functions and exposure to threats.

Key controls include:

• Authentication: Verify user and device identities before allowing access to protected functions.
• Access control: Limit permissions according to user roles and authorised activities.
• Data security: Protect sensitive information using appropriate encryption and secure communication protocols.
• Audit logging: Maintain records of security events, access attempts, and important configuration changes.
• Software integrity: Detect unauthorised modifications to firmware, software, and critical system components.
• System hardening: Remove unnecessary services, restrict exposed interfaces, and configure secure default settings.
• Recovery mechanisms: Support the restoration of essential functions and information following a security incident.
• Secure updates: Verify the authenticity and integrity of software updates before installation.

Not every device requires the same protections. Consider its clinical purpose, physical access points, connectivity, and operating conditions when choosing suitable measures.

Document the reasoning behind each control, including the requirement it addresses and how remaining security risks will be managed.

Step 3. Conduct Cybersecurity Verification and Validation Testing

Security testing should confirm that implemented controls function correctly and identify weaknesses that attackers could exploit. Functional verification checks whether individual safeguards meet their requirements, while broader security assessments examine how vulnerabilities could be exploited across the device and its connected systems.

Manufacturers can select from the following testing methods according to the device's architecture and identified risks.

Testing should cover relevant hardware interfaces, embedded firmware, wireless connections, applications, and supporting infrastructure. The selected scope must reflect how the device operates and where attackers could gain access.

Maintain test records that identify the device version, assessment scope, methodology, findings, severity, corrective actions, and verification results.

Step 4. Prepare Cybersecurity Technical Documentation

Manufacturers must maintain technical documentation showing how their devices meet applicable cybersecurity requirements. MDR and IVDR Annexes II and III establish requirements for technical documentation and postmarket surveillance records.

The cybersecurity evidence should include:

Device architecture: 

• System diagrams
• Software interfaces
• External connections
• Relevant technical specifications

Regulatory records: 

• Applicable security requirements
• References to supporting evidence

Risk documentation: 

• Threat models
• Cybersecurity assessments
• Decisions concerning identified risks

Security specifications: 

• Details of the protective measures incorporated into the device

Testing reports: 

• Verification
• Validation
• Penetration testing results
• Including the status of identified findings

Software components: 

• Component inventories
• Supplier information
• Relevant software dependencies

Vulnerability records: 

• Security issues
• Investigation findings
• Completed corrective actions

Operational documentation: 

• Minimum IT requirements
• Supported environments
• Security maintenance procedures
• Update arrangements

A Software Bill of Materials (SBOM) can support vulnerability management by helping manufacturers identify products containing affected software components. Its inclusion in the guidance does not, by itself, create a universal SBOM obligation for all medical devices.

The instructions for use should also explain secure configuration, compatible IT environments, available security updates, relevant residual risks, and actions required from healthcare operators.

For regulatory traceability, maintain an evidence matrix with three columns: Applicable requirement, Supporting evidence, and Verification method. This makes it easier to locate the documentation supporting each relevant requirement.

Step 5. Establish Postmarket Cybersecurity and Vulnerability Management

A medical device that passes security testing before release can develop new vulnerabilities during its service life. Manufacturers need a process for detecting and addressing these weaknesses as software dependencies, connected environments, and attack techniques change.

Security information can come from public vulnerability databases, supplier notifications, researchers, healthcare facilities, and incident reports. Once a concern is reported, the manufacturer should:

1. Identify the affected device models, components, and software versions.
2. Investigate whether the vulnerability can be exploited and how it could affect clinical functions.
3. Choose an appropriate response, such as a patch, configuration adjustment, or temporary protective measure.
4. Test the proposed correction and assess whether the modification has regulatory implications.
5. Inform affected healthcare operators about necessary actions and record the outcome.

Findings that affect device safety or performance must be considered within the postmarket surveillance system and ongoing benefit and risk assessment.

Not every cybersecurity vulnerability triggers regulatory incident reporting. Under MDR Article 87 and IVDR Article 82, manufacturers must report serious incidents and qualifying field safety corrective actions when the relevant criteria are met. An identified weakness without a reportable incident or qualifying corrective action does not automatically trigger those obligations.

Does MDCG 2019 16 Fully Address Modern Medical Device Cybersecurity Risks?

The guidance provides a foundation for managing medical device cybersecurity, but it does not cover every technical threat in equal detail.

A peer-reviewed study published in July 2025 in the Computational and Structural Biotechnology Journal compared MDCG 2019 16 Rev. 1 with FDA premarket cybersecurity guidance. Researchers created a reference framework containing 73 security requirements across 12 categories. They identified 156 requirements and recommendations in the MDCG document, including items concerning documentation and communication.

The comparison identified three areas where MDCG guidance provided less detailed coverage:

• Cryptography: Limited technical direction on certain encryption and cryptographic protection requirements
• Authentication and access control: Gaps in guidance covering identity verification and access restrictions
• Source code and software development: Less comprehensive recommendations for specific secure coding and development requirements

These findings concern the guidance's coverage, not the actual security of devices developed using it. The researchers also found that recommendations in both documents could help address vulnerabilities examined in their study.

Manufacturers should supplement regulatory guidance with relevant current standards, emerging threat information, established security engineering techniques, and testing suited to their devices.

How Medysec Helps Manufacturers Address MDCG 2019 16 Cybersecurity Expectations

Medysec helps medical device manufacturers address cybersecurity requirements under the EU MDR and IVDR through security assessments, penetration testing, and regulatory documentation support. Our services cover medical device hardware, firmware, communication interfaces, SaMD, healthcare applications, APIs, and connected cloud environments.

Our security assessments identify vulnerabilities that could affect device functionality, patient safety, or sensitive medical information. We provide detailed testing reports, vulnerability findings, and remediation recommendations to support cybersecurity documentation and conformity assessment activities. Our team also conducts verification testing to confirm whether identified weaknesses have been resolved.

If you need assistance evaluating your device's security or preparing technical evidence for regulatory review, contact Medysec to discuss your cybersecurity testing and documentation requirements.

Conclusion

MDCG 2019 16 provides manufacturers with a practical reference for addressing cybersecurity expectations under the EU MDR and IVDR. Although the guidance is not legally binding, manufacturers remain responsible for demonstrating conformity with applicable requirements.

Effective cybersecurity depends on connecting identified risks with suitable safeguards, testing evidence, regulatory documentation, and continued monitoring. These activities must remain relevant as medical devices evolve. Regular security reviews and timely responses to emerging vulnerabilities help manufacturers maintain device safety, protect patient information, and meet their ongoing regulatory responsibilities.

Secure Your Medical Device for EU Compliance

Need help verifying your device’s cybersecurity or preparing regulatory evidence? Contact Medysec Today to schedule a security assessment.

Speak with Our Experts →

FAQs

1. Is MDCG 2019 16 legally binding?

MDCG guidance is advisory rather than legally enforceable. Manufacturers can use different approaches to meet cybersecurity expectations, provided they can demonstrate compliance with the applicable requirements established under the EU MDR or IVDR.

2. Does MDCG 2019 16 apply to software as a medical device?

Standalone software developed for a qualifying medical purpose falls within its scope. Whether the MDR or IVDR applies depends on the software's intended function, such as supporting clinical decisions or performing in vitro diagnostic analysis.

3. Does MDCG 2019 16 require penetration testing for every medical device?

Penetration testing is not universally mandated by the guidance. The need for this assessment depends on the device's architecture, accessible interfaces, potential vulnerabilities, and identified risks. Manufacturers must justify their chosen verification methods.

4. Is an SBOM mandatory under MDCG 2019 16?

The document recognises the value of maintaining software component information for vulnerability management. It does not independently impose a universal SBOM requirement, although separate applicable regulations or contractual obligations could require one.