MDR · IVDR · MDCG 2019-16 rev.1
Engineer cybersecurity as a property of the medical device
Compliance is not demonstrated by one penetration test. The manufacturer must connect architecture, threats, patient risks, controls, verification, user information and vulnerability handling throughout the supported life cycle of the device.
Regulatory foundation
Start with device requirements, not a list of tests
MDCG 2019-16 rev.1 does not create a separate certification route. It explains how the cybersecurity-related requirements in Annex I to the MDR and IVDR connect with technical documentation, post-market surveillance and vigilance.
Regulation (EU) 2017/745
Medical devices
- 17.2
- Development life cycle, risk management including information security, verification and validation
- 17.4
- Minimum requirements concerning hardware, IT network characteristics and IT security measures needed to run the software as intended
- 23.4
- Information for safe use, including requirements for the IT environment and security measures
Regulation (EU) 2017/746
In vitro diagnostic medical devices
- 16.2
- Development life cycle, risk management including information security, verification and validation
- 16.4
- Minimum requirements concerning hardware, IT network characteristics and IT security measures needed to run the software as intended
- 20.4.1
- Information in the instructions for use, including requirements for the IT environment and security measures
Compliance model
Manage security continuously throughout the supported life cycle
Threats and vulnerabilities change faster than the underlying device design. A security conclusion therefore remains valid only when the manufacturer operates effective processes for monitoring, assessment and timely remediation after release.
-
01
Define the context
Architecture, assets, data, users, clinical functions, interfaces, operating environment and support lifetime.
-
02
Model the threats
Trust boundaries, attack surfaces, foreseeable scenarios, exploitability and possible patient impact.
-
03
Reduce risk by design
Least privilege, authentication, segmentation, data protection, logging, resilience and secure updating.
-
04
Control the components
Third-party and open-source software, version provenance, known vulnerabilities, SBOM and controlled replacement.
-
05
Verify the implementation
Code analysis, scanning, fuzzing, interface and update testing, penetration testing and residual-risk verification.
-
06
Maintain security
Threat monitoring, intake of reports, vulnerability assessment, patches, communication, CAPA, PMS and, where needed, vigilance or FSCA.
Technical documentation
Show a traceable path from each threat to verified controls
A standalone cybersecurity report can be useful, but it is not enough. Evidence must remain consistent with the intended purpose, architecture, software requirements, risk management, verification, instructions, PMS and the configuration actually released.
Cybersecurity plan
Roles, processes, criteria, methods, tools, suppliers, change control and post-release activities.
Architecture and data flows
Components, trust boundaries, interfaces, protocols, ports, external services, cloud environment and updates.
Threat model and risk assessment
Assets, attack scenarios, vulnerabilities, exploitability, harm, controls and residual risk.
Components and SBOM
Third-party component identification, versions, licences, sources, known vulnerabilities and supportability.
Verification and validation reports
A justified set of methods, acceptance criteria, results, unresolved anomalies and regression testing after changes.
Information for secure operation
Supported environment, configuration, network requirements, access roles, backup, logging and update installation.
Vulnerability management plan
Reporting channel, triage, timelines, coordinated disclosure, urgent mitigations, patches and user communication.
PMS and vigilance records
Signals, trends, incidents, corrective actions, risk updates and effects on clinical or performance evaluation.
Operating environment
Distribute activities without transferring the manufacturer’s responsibility
Security of a connected device depends on the manufacturer, integrator, healthcare organisation and user. The manufacturer should define reasonable assumptions about the environment and provide relevant information, but cannot transfer risks that should be reduced through device design to the operator.
A secure device and supported life cycle
- Defines the security context and requirements
- Implements and verifies controls
- Maintains components and remediates vulnerabilities
- Provides information and updates documentation
Controlled installation and configuration
- Follows the manufacturer’s requirements
- Checks interfaces and compatibility
- Documents configuration and changes
- Communicates identified problems
Protected infrastructure and operation
- Segments networks and manages access
- Maintains backup and recovery
- Installs agreed updates
- Responds to events and informs the manufacturer
Use within the specified environment
- Follows instructions and limitations
- Protects credentials and physical access
- Does not disable intended safeguards
- Reports failures and suspicious events
After market release
Do not automatically equate a vulnerability with a serious incident
A received signal first requires technical and clinical assessment. Even where vigilance reporting is not required, the decision and actions should remain traceable within PMS, risk management and CAPA.
-
01
Receive and preserve the signal
A researcher, user, supplier, publication, vulnerability database, complaint or internal monitoring process.
-
02
Confirm the affected configuration
Versions, components, operating conditions, attack accessibility and evidence of known exploitation.
-
03
Assess patient safety
Effects on performance, diagnostic or therapeutic decisions, availability and possible harm.
-
04
Determine regulatory actions
Routine remediation, urgent mitigation, user communication, serious incident, FSCA, trend or other reporting.
-
05
Remediate and close the loop
A patch or compensating control, V&V, controlled deployment and updates to risks, PMS and documentation.
Publish a clear reporting channel, acknowledge receipt, protect sensitive information, coordinate remediation and communication timelines, and do not delay measures needed to reduce risk.
Related EU legislation
Separate product conformity from organisational duties
The MDR or IVDR remains the basis for CE marking of the medical device. Other legislation may apply in parallel to data, the manufacturer, a healthcare organisation, an AI system or a separate digital product.
Cyber Resilience Act
Regulation (EU) 2024/2847 does not apply to products with digital elements that fall within the MDR or IVDR. Separate components or platforms outside that scope require their own assessment.
NIS2
Directive (EU) 2022/2555 covers certain manufacturers of medical devices and IVDs. Applicability depends on the category and size of the entity and the national law of the relevant Member State.
GDPR
Personal-data protection does not replace device security. Determine roles, legal bases, data minimisation, data-subject rights, security of processing and breach obligations separately.
Artificial Intelligence Act
For AI-enabled functions, additionally assess system classification, actor obligations, data quality, human oversight, robustness and the interaction with the medical device conformity assessment route.
Primary sources and standards
Justify the state of the art for the particular device
A standard or guidance document should not be applied mechanically. Define its applicability, edition and role, and verify the current harmonisation status before claiming a presumption of conformity.
MDCG 2019-16 rev.1
Core EU guidance on medical device cybersecurity
Regulation (EU) 2017/745
Official MDR text on EUR-Lex
Regulation (EU) 2017/746
Official IVDR text on EUR-Lex
IEC 81001-5-1:2021
Security activities in the health software product life cycle
ISO 14971:2019
Risk management for medical devices
IMDRF N73
Principles and practices for medical device cybersecurity SBOMs
Frequently asked questions
Practical boundaries of the requirements
The scope of work depends on the architecture, intended operating environment, clinical function, supported lifetime and consequences of a loss of confidentiality, integrity or availability.
Do the requirements apply only to connected devices?
No. Even a standalone device may have vulnerable local interfaces, removable media, service access, update mechanisms or third-party components. The assessment should reflect the actual architecture and foreseeable attack paths.
Is penetration testing sufficient?
No. It is one verification method. It does not replace threat modelling, risk management, secure architecture, component control, requirements-based testing, user information or post-market processes.
Is an SBOM mandatory?
The MDR and IVDR do not prescribe one universal SBOM format. MDCG 2019-16 rev.1 nevertheless identifies it as relevant information, while identification of third-party components is necessary to monitor known vulnerabilities and maintain state-of-the-art security.
Must every vulnerability be reported?
Not automatically through the vigilance system. Each vulnerability requires a documented assessment of exploitability and possible harm. Reporting depends on the applicable definitions of an incident, serious incident, public health threat and the need for an FSCA.
Does the Cyber Resilience Act apply to an MDR or IVDR device?
No. Products with digital elements that fall within the MDR or IVDR are excluded from the scope of the Cyber Resilience Act. Separate products or components outside that scope require their own assessment.