How Does MDR Address Medical Device Cybersecurity?
Cybersecurity Is Not a Standalone Requirement — It's Tied to Safety and Performance
Under the MDR framework, cybersecurity is not listed as a separate compliance clause. Instead, it is closely integrated with the device's overall safety and performance requirements. Annex I of the MDR, the General Safety and Performance Requirements (GSPR), requires manufacturers to implement appropriate safety and risk-control measures based on the device's intended use, intended use environment, and reasonably foreseeable risks.
For medical devices that include software, network connectivity, or data-exchange capabilities, this means manufacturers must fully account for cybersecurity factors throughout product risk management and the software development process, ensuring that related risks are properly controlled.
MDCG 2019-16: The EU's Official Cybersecurity Guidance
To help manufacturers implement the cybersecurity requirements embedded in the MDR, the EU Medical Device Coordination Group (MDCG) published MDCG 2019-16: Guidance on Cybersecurity for Medical Devices. This guidance provides specific direction across the different stages of a device's lifecycle, covering:
- Security by design
- Risk management
- Verification and validation
- Post-market surveillance
This makes clear that cybersecurity compliance is not limited to a single pre-market technical test, but must be integrated with the device's software lifecycle and risk management process as a whole.
The Compliance Focus: From "Test Results" to "Process and Evidence"
From a regulatory and audit perspective, manufacturers must be able to demonstrate — through technical documentation and supporting records — three things:
- Whether cybersecurity risks have been adequately identified
- Whether the security measures implemented are proportionate to those risks
- Whether those measures have been properly verified
This means that vulnerability scans and penetration test results are only part of the cybersecurity compliance evidence. What matters more is establishing a complete, traceable process that supports those test results — and this is exactly what auditors and Notified Bodies focus on during review.
IEC 81001-5-1: Embedding Cybersecurity into the Software Lifecycle
If MDR defines the regulatory direction for medical device cybersecurity, then IEC 81001-5-1:2021 provides the concrete process framework for managing the security lifecycle of health software.
The standard does not focus on any single security technology. Instead, it emphasizes how to systematically embed cybersecurity activities throughout the software product lifecycle, generating traceable process evidence through corresponding activities, tasks, and documentation — allowing cybersecurity to align with medical device software development and risk management processes.
Planning Stage: Establishing Security Requirements Early
Cybersecurity should be considered from the very beginning of software development, not bolted on afterward. During the planning stage, manufacturers need to define:
- Cybersecurity-related activities, responsibilities, and resource allocation
- Applicable secure development requirements and coding standards
Building on this foundation, manufacturers should establish specific cybersecurity requirements based on the device's intended use, operating environment, and potential risks — such as:
- Authentication and authorization
- Data confidentiality and integrity
- Logging and audit trails
- Software update mechanisms
- System security and resilience
These requirements then flow into subsequent design and development activities.
Architecture and Design Stage: Implementing "Security by Design"
During the architecture and design stage, the cybersecurity requirements defined earlier must be translated into concrete security architecture and design measures. Common approaches include:
- Threat modeling: identifying potential attack paths and analyzing security risks in relation to trust boundaries, interfaces, and key data flows
- Defense in depth: building multiple layers of protection
- Least privilege: restricting access rights for system components and users
- Attack surface minimization
- Fail-safe design: ensuring the system remains in a safe state during abnormal conditions
In addition, third-party and open-source software components must be properly managed, ensuring that risks introduced through the software supply chain are identified and controlled.
Implementation and Verification Stage: Generating Concrete Security Evidence
Once implementation begins, cybersecurity requirements must be carried through into specific activities such as:
- Secure coding
- Code review
- Third-party and open-source component management
Manufacturers should also establish a Software Bill of Materials (SBOM), which documents software components and their dependencies, providing the foundational information needed for later vulnerability identification and risk analysis.
During the verification and validation stage, appropriate security testing should be conducted based on the device's cybersecurity risk level, including:
- Vulnerability scanning
- Security functional testing
- Penetration testing
The scope and depth of testing should be proportionate to the device's actual cybersecurity risk, rather than a purely formal exercise.
From Threat to Patient Safety: Building Traceable Cybersecurity Risk Management
Once cybersecurity is embedded into the software lifecycle, the next key question becomes: how do identified cybersecurity threats get translated into product risks that can be assessed, controlled, and verified?
From Threat Identification to Risk Assessment
Manufacturers can use threat modeling, vulnerability analysis, and security testing to identify potential cybersecurity threats, attack paths, and software security weaknesses, and analyze their possible impact. Building on this, manufacturers should apply the risk management requirements of ISO 14971 to further evaluate whether a cybersecurity event could lead to a hazardous situation and cause harm to patients or users.
For identified vulnerabilities, CVSS (Common Vulnerability Scoring System) can be used as a severity reference. However, medical device risk determination cannot rely on CVSS scores alone — it must also account for the device's intended use, actual use environment, and its real-world impact on product safety and patient safety.
Building a Traceable "Threat–Risk–Control" Chain
After risk identification and assessment, manufacturers must define corresponding risk control measures for identified risks and confirm — through verification activities — that those measures have been effectively implemented. The entire process should form a clear, traceable chain:
Threat → Vulnerability/Attack Path → Hazardous Situation → Risk → Risk Control → Verification → Residual Risk
This means manufacturers must be able to explain not only "what security measures were taken," but also which specific risk each measure addresses and how its effectiveness is demonstrated. All related analyses, decisions, and verification results should be captured in corresponding technical documentation and records, supporting the overall safety and compliance argument for the product.
SBOM: A Foundation for Ongoing Risk Management
For medical devices that incorporate third-party and open-source components, an SBOM helps manufacturers clearly understand software composition and component dependencies, providing the foundation for subsequent vulnerability identification and impact analysis.
When a new vulnerability or cybersecurity threat emerges, manufacturers can use the SBOM to quickly determine which components and products are affected, and further assess the potential impact on product safety and patient safety. An SBOM is therefore not merely a development-stage inventory — it is a critical data asset supporting cybersecurity risk management across the product's entire lifecycle.
What Happens After Market Launch? Building a Continuous Cybersecurity Management System
Successfully obtaining CE marking and launching a medical device does not mark the end of cybersecurity management work. Once a product is on the market, new vulnerabilities, cybersecurity threats, software component changes, and real-world usage feedback can continue to emerge. Post-market cybersecurity management must therefore be a continuous process spanning the entire product lifecycle.
Continuous Monitoring of Vulnerabilities and Cybersecurity Threats
Manufacturers should establish an ongoing information-monitoring mechanism to track new vulnerabilities, security incidents, and cybersecurity threats — both in their own products and in third-party or open-source components. When security issues are identified, manufacturers should conduct impact analysis based on the actual product context and take appropriate remediation, risk-mitigation, or other response measures. Software composition information should also be kept up to date, enabling rapid identification of affected products and components when new vulnerabilities emerge.
Establishing Security Update and Incident Response Mechanisms
When a vulnerability or cybersecurity event that could affect medical device safety is discovered, manufacturers should have a clearly defined response mechanism in place to promptly conduct analysis, remediation, and, where necessary, risk escalation. For security issues that require a software update, the update itself must be properly verified to ensure it does not introduce new security risks or affect the device's intended performance.
Closing the Loop with PMS and Risk Management
Post-market cybersecurity information should also be linked to the medical device's Post-Market Surveillance (PMS) and vigilance processes. Vulnerability data, security incidents, user feedback, and security updates can all serve as important inputs for reassessing product risk.
When a new cybersecurity risk emerges, manufacturers should promptly update the relevant risk analysis and technical documentation, adjusting risk control measures as needed, ultimately forming a complete closed loop:
Continuous Monitoring → Risk Identification → Response and Remediation → Verification → PMS Feedback → Risk Management Update
Through this closed-loop mechanism, cybersecurity can truly span the entire lifecycle of a medical device — from design and development through post-market operation — rather than remaining confined to pre-market testing and compliance documentation.
Conclusion: Cybersecurity Should Be Embedded from the Product Planning Stage
For medical device manufacturers, cybersecurity should not be treated as an add-on tacked on late in development. It should be embedded from the product planning and design stage onward, spanning risk management, verification, and post-market monitoring.
In practice, companies need to integrate three key elements:
- MDR regulatory requirements
- IEC 81001-5-1 security lifecycle management
- ISO 14971 risk management
At the same time, companies must build continuous vulnerability monitoring and response mechanisms so that cybersecurity risks can be identified, assessed, and addressed in a timely manner. On this foundation, independent third-party assessment, testing, or certification services can evaluate the cybersecurity management processes and evidence a company has established, helping identify potential weaknesses and providing ongoing support for improving cybersecurity management and demonstrating compliance.
Only by truly embedding cybersecurity across a product's entire lifecycle can manufacturers meet EU MDR compliance requirements while more effectively supporting the safety and continuous operation of their medical devices.
