MDCG 2019-16 — Medical-device Cybersecurity

The guidance explains cybersecurity within EU device regulation

MDCG 2019-16 rev.1, published in July 2020 and still listed as current, provides manufacturers with guidance on fulfilling the cybersecurity requirements of the MDR and IVDR. It also describes expectations for other actors, including integrators, healthcare providers and users.

The guidance is not a separate cybersecurity law or certification scheme. It interprets how lifecycle risk management, general safety and performance requirements, technical documentation, information supplied and post-market obligations apply to cybersecurity.

The MDR and IVDR provide the binding foundation

Annex I requires risk reduction, consideration of the generally acknowledged state of the art, control of programmable systems and software, protection against unauthorised access, and definition of minimum IT-network, hardware and security conditions necessary for intended operation.

Apply these requirements through the manufacturer's quality and risk-management systems. Cybersecurity evidence should support conformity assessment and remain connected to the product's GSPR checklist, technical documentation and post-market surveillance.

MTL-307 — EU MDR and IVDR General Safety and Performance Requirements explains the complete Annex I framework.

Cybersecurity is a total-product-lifecycle activity

Plan security work alongside the software and system lifecycle. Retrospective threat modelling or a late penetration test cannot repair architectural assumptions that make the device difficult to secure or update.

Use MTL-108 — Medical-device Cybersecurity for the general process and MTL-213 — Cybersecurity Engineers in Medical-device Development for specialist responsibilities.

Security risk and safety risk are linked but distinct

Identify security assets, threats, vulnerabilities and attack paths, then determine how loss of confidentiality, integrity or availability could affect device safety, performance, privacy or regulatory conformity. Translate credible security events into system states and possible hazardous situations.

Security risk evolves with exposure, attacker capability and vulnerability information. Safety risk addresses the probability and severity of harm. Maintain explicit connections between the analyses without forcing them into one incompatible scoring scale.

• Define security objectives for device functions, data and services.
• Model interfaces, trust boundaries and external dependencies.
• Identify threats, vulnerabilities and foreseeable misuse.
• Assess exploitability and technical impact.
• Evaluate possible patient, user or wider system harm.
• Derive, verify and monitor risk-control measures.

MTL-302 — ISO 14971 Risk Management provides the safety-risk framework.

Secure design needs layered, proportionate controls

Select controls from the risk analysis and state of the art. Document important assumptions and explain how controls work together rather than presenting an unprioritised checklist.

Define the intended operating environment and external controls

Manufacturers must specify the minimum network, hardware and IT-security conditions needed for intended operation. Consider healthcare networks, home use, mobile platforms, cloud services, service infrastructure, identity systems and physical access.

External controls can contribute to risk reduction only when they are realistic, communicated and verifiable. Do not transfer unmanageable product risk to a hospital through vague statements such as “use on a secure network”. Describe necessary segmentation, accounts, ports, certificates, time services, backup, monitoring and administrator responsibilities.

MTL-121 — Data, Connectivity and Interoperability supports interface definition.

Technical documentation should show a connected security case

Cybersecurity evidence should cover the device and system context, risk-management process, threat analysis, security requirements, architecture, detailed controls, verification, software components, residual risks and lifecycle plans.

• Security planning and responsibility records
• System, data-flow and trust-boundary views
• Threat modelling and security-risk analysis
• Security requirements and architecture
• Traceability to implementation and verification
• Third-party component and vulnerability evidence
• Secure-update, recovery and support strategy
• Residual-risk evaluation and information supplied
• Post-market monitoring and incident-response plans

Organise the wider evidence chain through MTL-104 — Design Controls and Technical Documentation.

Information supplied is part of the security control system

Provide users and integrators with information necessary for secure installation, configuration, operation, maintenance and disposal. Identify supported environments, accounts, interfaces, ports, network services, logging, backup, updates, security events and residual responsibilities.

Information must be usable by its intended audience. Separate operational guidance for clinical users from technical guidance for IT administrators and service personnel where appropriate. State support periods and communicate when components or security controls are no longer maintained.

Verification should challenge the security claims

Combine architecture review, code analysis, component assessment, configuration review, vulnerability scanning, interface testing, fuzzing, misuse-case testing and penetration testing as appropriate. Cover production-equivalent configurations and relevant external systems.

Record scope, tools, versions, competence, environment, findings, remediation, retest and residual conclusions. Explain exclusions and limitations. A pass result from one scanner or test supplier does not establish complete cybersecurity conformity.

Monitor vulnerabilities and maintain security after release

Establish processes to gather security information, receive reports, monitor components, assess exploitability and impact, determine reportability, develop remediation and communicate with authorities, customers and other stakeholders.

Updates must be authentic, integral, compatible and recoverable. Evaluate safety, performance and regulatory effects before deployment, while retaining the ability to act quickly when risk requires it. Include cybersecurity signals in post-market surveillance and periodic reporting.

Use MTL-111 — Post-market Support and MTL-127 — Configuration and Change Management for the surrounding lifecycle controls.

Stakeholders share tasks, but the manufacturer retains accountability

Healthcare providers maintain secure infrastructure and local controls; users follow instructions and report issues; integrators configure interfaces; suppliers manage components and notify changes. The manufacturer must understand these dependencies and provide actionable information.

Contracts and labels cannot transfer away the manufacturer's responsibility to design a conforming device. Where an external measure is essential to safety, ensure it is feasible in the intended environment and define how its presence is established.

Common misconceptions

Practical conformity checklist

• Are applicable MDR or IVDR cybersecurity GSPRs mapped?
• Does the security scope include the complete system and lifecycle infrastructure?
• Are threat and safety analyses explicitly connected?
• Do requirements and architecture implement layered controls?
• Are external-environment assumptions realistic and documented?
• Can controls be traced to risk and verification evidence?
• Are third-party components and vulnerabilities actively managed?
• Can the device be updated securely and recovered safely?
• Does information supplied enable secure integration and use?
• Are post-market monitoring, disclosure and response responsibilities operational?