Medical devices are getting more connected every day. This makes them easier to use and manage. It also brings new risks. A cyberattack could change test results, make a device stop working, or put safety in danger.
In Europe, the MDCG cybersecurity guidance helps medical device manufacturers understand how to address cybersecurity rules under the MDR and IVDR. The guidance, called 2019 16 Rev.1, does not create new laws. Rather than it explains what is already required by law.
Cybersecurity is about finding security flaws in a device. It means thinking about security from the start of development. Manufacturers must stay alert to threats. Fix problems even after the device is on the market.
In this guide, you will learn what manufacturers need to know about the guidance. It also tells you how to follow its recommendations in real situations.
What Is MDCG 2019-16 Cybersecurity Guidance?
The Medical Device Coordination Group released 2019 16 Rev.1 in July 2020. 2019 16 gives clear recommendations for applying cybersecurity rules under EU Regulations 2017/745 (MDR) and 2017/746 (IVDR).
Two sections of MDR Annex I are particularly relevant:
Section 17.2 Covers :
- Software development
- Risk management
- Information security
- Verification
- Validation
Section 17.4 requires manufacturers to:
- Specify the hardware
- Network conditions
- IT security measures needed for the device to operate as intended
The IVDR addresses requirements in sections 16.2 and 16.4.
Manufacturers can refer to standards and current technical practices when deciding how to meet these requirements and document their work.
The document also discusses the roles of integrators, healthcare organisations, operators, healthcare professionals, and patients.
Which Medical Devices Need to Consider MDCG Cybersecurity Guidance?
The MDCG guidance on cybersecurity for medical devices applies to cybersecurity risks that could affect a device’s safety, performance, or data security. It is relevant to several types of medical devices, including:
Medical software
- Standalone medical software
- Mobile medical apps
- IVD software
Devices with built-in software
- Medical equipment that uses software to control its functions
Connected medical devices
- Patient monitors
- Diagnostic equipment
- Devices connected to hospital networks
Cloud-based systems
- Medical devices that rely on cloud services
- APIs, or external software
Devices using third-party software
- Products that contain external software libraries or open source components.
To deal with cybersecurity risks, devices do not need an internet connection. Attackers can exploit USB ports, Bluetooth connections, local networks, service ports, or software update systems.
How MDCG Cybersecurity Requirements Apply Across the Medical Device Lifecycle
Define the Device, Assets, and Operating Environment
Before assessing security risks, manufacturers need a clear picture of the device and everything it relies on to function. Start by recording its technical architecture and the information that needs protection.
Include the following details:
System components
- Hardware
- Firmware
- Software
- Databases
- Mobile apps
- Cloud services
- External APIs
Access points:
- Communication interfaces
- Administrator accounts
- Privileged functions
- Software update systems
Data flows:
- How information moves between components
- Where it enters or leaves the system
- Which connections cross trust boundaries
Critical assets:
- Patient records
- Diagnostic results
- Treatment settings
- Credentials
- Encryption keys
- Audit logs
- Software files
You also need to specify the conditions in which the device is expected to operate. These may include supported operating systems, hardware specifications, network ports, protocols, firewall settings, access permissions, backup arrangements, and physical security.
Perform Threat Modelling and Attack Surface Analysis
Threat modelling helps manufacturers identify how attackers could exploit weaknesses in a medical device. The MDCG cybersecurity recommendations call for assessing possible threats and their effects on device security.
Consider threats such as:
Unauthorised access
- Stolen credentials
- Account misuse
- Privilege escalation
Software attacks
- Malicious firmware
- Vulnerable dependencies
- Compromised updates
Network attacks
- API misuse
- Intercepted communications
- Denial of service
Data tampering
- Unauthorised changes to clinical data
- Treatment settings
- Device commands
External threats
- Compromised cloud services
- Remote support systems
The review should cover all possible entry points, including open ports, wireless connections, service interfaces, update servers, and removable media.
Connect Cybersecurity Risk to Medical Device Safety Risk
A security breach can become a safety risk when it affects how a medical device works. Manufacturers need to assess both risks together, using ISO 14971 for safety risk management.
Consider an infusion pump with a software vulnerability:
Attacker exploits a vulnerability
↓
Unauthorised change to infusion settings
↓
Incorrect medication delivery
↓
Possible patient harm
The security issue is unauthorised control. The safety concern is the harm that incorrect medication delivery could cause.
Other security failures may involve stolen patient data, altered diagnostic results, disabled alarms, or unavailable treatment.
Under MDCG guidance, manufacturers should:
- Assess how each relevant security failure could affect device safety
- Include possible harm in the ISO 14971 risk assessment
- Use security controls to reduce the chance of an attack
- Consider separate safety measures to limit harm if an attack succeeds
- Check whether safety controls introduce security problems, or vice versa
Define Risk-Based Security Requirements and Controls
Once manufacturers know which risks need attention, they decide how to address them. All security requirements should clearly state what the device must do and how its effectiveness will be checked. For medical devices, including in vitro diagnostic (IVD) devices under the EU IVDR, these requirements should address applicable cybersecurity risks.
Depending on the risks, requirements cover:
Access control
- User authentication
- Permissions
- Account management
- Session timeouts
Data protection
- Encryption
- Secure communication
- Integrity checks
System protection
- Secure boot
- Input validation
- Configuration security
Monitoring
- Audit logs
- Security event detection
- Accountability
Recovery
- Data backups, secure updates, and protection against unauthorised software changes
Requirements must be specific. Instead of stating that passwords should be strong, define the password rules and account lockout conditions
Choose controls based on the device’s clinical use, operating conditions, identified risks, and current security practices. Each requirement should link to the risk it addresses and have clear acceptance criteria for verification
Verify That Cybersecurity Controls Actually Work
A security control needs to work as intended, not just appear in the device specifications. Manufacturers must verify its effectiveness through suitable testing.
Depending on the device, testing may include:
- SAST: Checks application code for security weaknesses
- DAST: Tests running applications for vulnerabilities
- SCA: Identifies known vulnerabilities in third-party software
- Vulnerability scanning: Finds known security flaws in systems and services
- Penetration testing: Checks whether attackers could exploit weaknesses
- Fuzz testing: Checks how software handles unexpected or invalid inputs
- Functional security testing: Verifies access permissions, API security, software updates, and recovery functions
For each test, manufacturers should record the results and any unresolved issues. The findings should connect back to the original risk and security requirement.
What Cybersecurity Evidence Should Be in the Medical Device Technical Documentation?
Under MDCG guidance, manufacturers need to document their cybersecurity decisions and provide evidence that the required security measures have been implemented.
The technical documentation may include the following records, depending on the device and its risks.
| Purpose | Evidence to maintain |
| Plan security activities | Cybersecurity management plan |
| Describe the system | Architecture and data flow diagrams |
| Identify assets | Asset inventory |
| Assess security threats | Threat model and security risk assessment |
| Connect security risks to patient safety | ISO 14971 risk management records |
| Define protection measures | Security requirements and control specifications |
| Track software components | Software Bill of Materials (SBOM) |
| Review external software | Third-party dependency assessment |
| Document testing | Security verification plans and reports |
| Record security weaknesses | Vulnerability assessment and penetration test reports |
| Evaluate remaining risks | Residual risk assessment and justification |
| Manage software updates | Security update procedures |
| Monitor vulnerabilities | Vulnerability monitoring records |
| Receive vulnerability reports | Coordinated vulnerability disclosure procedure |
| Respond to incidents | Security incident response plan |
| Monitor released devices | Cybersecurity surveillance records |
| Explain secure installation | Security configuration instructions |
| Define support arrangements | Security support and end-of-support policy |
All these documents should connect identified risks to the measures taken and the evidence that supports each decision.
Manufacturers also review and update relevant records when new vulnerabilities or security changes affect previous assessments.
How Post-Market Cybersecurity Monitoring Works Under MDCG
CE marking does not mean a medical device is free from future security risks. New vulnerabilities can appear in software that was considered secure when the product was released.
Manufacturers should include cybersecurity monitoring in their post-market surveillance process. Useful sources include:
- Vulnerability alerts: CVE records and security advisories from CERTs or CSIRTs
- Software suppliers: Notices about weaknesses in third-party components
- Security researchers: Reported vulnerabilities and new attack techniques
- Device users: Customer complaints and reports of unusual behaviour
- Internal findings: Security assessments and incidents involving devices already in use
When a new issue is reported, manufacturers should follow a clear process:
- Identify the affected devices and software versions
- Check whether the weakness can be exploited
- Assess possible effects on patients and device performance
- Decide whether regulatory reporting or corrective action is necessary
- Develop and verify the required fix
- Inform affected users when necessary
- Update the relevant risk assessments and surveillance records
How Should Manufacturers Handle Cybersecurity Patches and Updates?
Manufacturers should plan how to update medical devices before releasing them. The MDCG guidance addresses timely patching while ensuring that updates do not affect device safety or compatibility.
A patch management process should cover:
- Patch development: Identify affected device versions and prepare the fix
- Update security: Verify that the update comes from an authorised source and has not been altered
- Delivery: Decide how users will receive and install the patch
- Failed updates: Provide recovery procedures and rollback options where appropriate
- Testing: Check that the patch fixes the weakness without affecting essential device functions
- Communication: Tell customers when action is required and prioritise urgent fixes
Track third-party components. Record their versions and suppliers along with known vulnerabilities. A SBOM can help identify which device versions contain an affected component.
Device Lifetime vs Cybersecurity Support Lifetime
These four terms have different meanings:
| Term | Meaning |
| Device lifetime | How long the device is expected to perform its intended function safely |
| Cybersecurity support period | How long the manufacturer commits to providing defined security support |
| Third party support lifetime | How long external software or hardware suppliers provide security support |
| End of support | Manufacturer stops providing the stated security support |
The medical device could be running if the device’s operating system or a critical element is not updated with security patches. A number of well-understood vulnerabilities can therefore be unpatched.
Manufacturers should consider these support periods when selecting components and planning the product’s expected lifetime. If a dependency becomes unsupported, they need to assess the risk and determine suitable measures to protect affected devices.
Is MDCG 2019 16 Enough to Represent the State of the Art in 2026?
No. MDCG 2019 16 Rev.1 remains useful, but its 2020 publication date is important. Manufacturers consider newer standards and technical developments when assessing current cybersecurity practices.
The term state of the art refers to the generally accepted level of technical knowledge and practice at a given time. It does not automatically mean using the newest technology.
ISO 14971:2019
This standard remains current following its confirmation in 2025. It provides the established medical device risk management standard.
IEC 62304:2006 + A1:2015
It provides requirements for medical device software lifecycle processes. This is not a complete cybersecurity standard. It should not be used as one.
IEC 81001-5-1:2021
This version is relevant because it addresses security activities throughout the health software lifecycle.
Provides a structured approach to:
- Security management
- Secure software design
- Security requirements
- Secure implementation
- Security verification
- Vulnerability handling
The difference between the two documents is their purpose.
| MDCG guidance | IEC 81001-5-1 |
| Explains EU regulatory expectations | Provides technical security lifecycle requirements |
| Addresses MDR and IVDR compliance | Focuses on health software security engineering |
| Provides regulatory context | Supports implementation through defined processes |
They complement each other.
SBOM and Current International Practice
MDCG 2019 16 does not establish the detailed SBOM framework found in newer international guidance. It should not be interpreted as imposing the US FDA’s SBOM expectations on every European medical device.
How Qualysec Can Support Medical Device Cybersecurity Testing
Qualysec offers penetration testing services to help medical device manufacturers identify security weaknesses and obtain independent testing evidence for their cybersecurity assessments.
Our testing services cover:
- Web applications: Authentication and access control weaknesses
- Mobile applications: Insecure data storage and application vulnerabilities
- APIs: Broken authorisation and business logic flaws
- Cloud infrastructure: Misconfigurations and exposed resources
- External networks: Vulnerable services and unauthorised access paths
- IoT devices: Insecure communication and device interfaces
Our security experts combine manual testing with automated tools to identify vulnerabilities that automated scans may miss.
Following the assessment, you receive a report with severity ratings, technical reproduction steps, and recommendations for fixing the identified issues. Retesting can help confirm whether the fixes are effective.
These findings can support your cybersecurity verification records. However, responsibility for MDR and IVDR compliance remains with the manufacturer.
Conclusion
A security assessment completed before product release cannot account for every risk a medical device may face throughout its lifetime. Manufacturers need to keep reviewing their security measures as new threats emerge and technology changes.
The MDCG cybersecurity guidance remains relevant in 2026, but newer standards and technical practices also deserve attention. Following the guidance alone does not guarantee that every security risk has been addressed.
What matters is having clear records that explain your security decisions, reliable evidence that supports them, and a process for keeping devices secure throughout their intended use.
Contact Qualysec to discuss your product architecture, testing scope, and compliance objectives with our security team.
FAQs
1. Is MDCG 2019 16 legally binding?
No. MDCG 2019 16 is guidance rather than law. The legal requirements come from the MDR and IVDR. However, manufacturers should not ignore it when deciding how to meet those requirements.
2. Is MDCG 2019- 16 still current in 2026?
Yes. The July 2020 revision remains current. However, cybersecurity practices have changed since then. Manufacturers should also refer to newer standards such as IEC 81001 5 1 when reviewing their security measures.
3. Is penetration testing mandatory under MDR cybersecurity requirements?
Not every medical device needs the same level of penetration testing. The testing should match the risks involved. A device with several external connections may need more extensive testing than one with limited access.
4. Does MDCG 2019 16 require manufacturers to maintain an SBOM?
No. The document does not make an SBOM compulsory for every manufacturer. However, keeping a record of software components makes it easier to find affected devices when a supplier reports a vulnerability.
