MDCG 2019-16: Cybersecurity for medical devices, explained

Who this applies to

This guidance applies to manufacturers of medical devices and IVDs containing software or depending on a networked or otherwise security-relevant environment. That includes software as a medical device, embedded software, mobile apps, connected devices, and devices whose safe operation depends on a hospital network, workstation, cloud service, or third-party component.

It also matters to integrators, healthcare providers, users, authorised representatives, importers, distributors, and notified bodies. Cybersecurity is shared in operation, but the manufacturer cannot transfer its own design and regulatory obligations to the hospital or user.

The core idea: security is part of safety

The MDR and IVDR require devices incorporating software to be developed and manufactured in line with the state of the art, taking information security, verification, validation, risk management, and minimum operating requirements into account. MDCG 2019-16 turns that into a lifecycle process.

A security problem becomes a regulatory safety problem when it can compromise the device's safety, performance, data, or intended operation. The risk analysis therefore needs to cover malicious and accidental causes, not just predictable component failures. A vulnerable network interface, weak authentication, an unsupported operating system, or an unavailable security update may create a hazardous situation even when the software performs correctly in a laboratory test.

The guidance distinguishes two related areas:

Both belong in the technical documentation. A generic statement that the customer is responsible for cybersecurity does not replace either one.

Build cybersecurity into risk management

Start with the intended purpose, intended users, reasonably foreseeable misuse, operating environment, data flows, interfaces, and assets that need protection. Then identify threats and vulnerabilities, estimate how exploitation could lead to harm, select controls, and evaluate the residual risk. The security risk work should connect to the device safety risk-management file rather than live in a separate spreadsheet with no traceability.

The guidance expects defence in depth. Depending on the device, controls may include least privilege, strong identity and access management, protected communications, secure storage, integrity checks, hardened configuration, audit logs, availability and recovery controls, controlled maintenance access, signed software or updates, and mechanisms for deploying security patches safely.

Risk control is not complete when a control is listed. You need objective verification that it works, validation in the intended environment, and evidence that the remaining security risk is acceptable when considered with the device's clinical risks and benefits. Usability matters too: a security control that users routinely bypass may not be an effective control.

Define the operating environment

The instructions for use and other information supplied with the device should describe the minimum hardware, network, and IT-security requirements needed for safe operation. This can include supported operating systems, network architecture, ports and services, account management, backup and restore, antivirus compatibility, update responsibilities, logging, physical access, and what to do after a suspected compromise.

Be precise about the split of responsibilities. The manufacturer controls the device design, disclosed requirements, updates, and device-specific vulnerability response. The operator controls its local network, access administration, deployment, maintenance practices, and implementation of the manufacturer's instructions. Contracts may allocate practical tasks, but they do not change the manufacturer's regulatory responsibility for the device.

Post-market cybersecurity never stops

Security changes after release even when the device code does not. New vulnerabilities appear in operating systems, libraries, processors, protocols, cloud services, and other third-party components. Post-market surveillance therefore needs active sources such as supplier notices, vulnerability databases, researcher reports, threat intelligence, service data, complaints, incidents, and information from users.

For each finding, assess exploitability, affected versions, possible safety impact, existing controls, and whether correction or disclosure is required. Feed the result into risk management, the clinical or performance evaluation where relevant, CAPA, vigilance, technical documentation, and field action processes. A coordinated vulnerability disclosure process gives researchers and customers a safe route to report problems and tells them what response to expect.

Security updates need the same design and change controls as other software changes. Verify that a patch closes the vulnerability without damaging safety or performance, assess whether the change affects conformity, communicate deployment instructions, and track uptake where failure to install could create an unacceptable risk.

What this means for you, practically

1. Create a device security architecture. Map components, trust boundaries, interfaces, data flows, privileged functions, external dependencies, and the controls at each boundary.
2. Connect threat analysis to safety risk. For every credible security scenario, show the path from vulnerability and threat to hazardous situation and possible harm, then trace the control and its verification evidence.
3. Write testable environment requirements. Replace “use a secure network” with supported platforms, required configurations, ports, account rules, update assumptions, backup expectations, and operator responsibilities.
4. Inventory third-party components. Keep versions and support status current so a new vulnerability can be matched to affected devices quickly.
5. Run a vulnerability-response process. Define intake, triage, risk assessment, escalation, coordinated disclosure, correction, vigilance assessment, customer communication, and closure evidence before the first report arrives.

Read the official MDCG 2019-16 Rev.1 guidance.