EU MDR Cybersecurity Requirements: A Practical Roadmap for MedTech

What if your medical device passed all your performance tests, but there are still some security flaws that may impact how well your device runs? These sorts of concerns can become complicated for MedTech manufacturers, both from a regulatory standpoint as well as in terms of patient safety.

The EU Medical Device Regulation (EU) 2017/745 addresses applicable cybersecurity risks as part of device safety and performance. Meeting MDR cybersecurity requirements can be difficult, especially when products depend on connected software, remote monitoring, or cloud services. Manufacturers need to demonstrate that their security decisions are supported by proper assessments, testing, and documentation.

In this guide you will know what the regulation expects, where compliance challenges arise, and how manufacturers can prepare the necessary evidence throughout the device lifecycle.

What Are the EU MDR Cybersecurity Requirements?

The MDR cybersecurity requirements come from Regulation (EU) 2017/745, particularly the General Safety and Performance Requirements (GSPRs) in Annex I. They address security risks that could affect medical device safety, performance, or reliable operation.

These obligations cover different stages of the device lifecycle, from development to postmarket monitoring. Their applicability depends on the device's intended purpose, connectivity, software functions, operating environment, and risk profile.

Manufacturers must identify applicable requirements, document their compliance methods, and justify any provisions considered inapplicable.

Key EU MDR Annex I Cybersecurity Requirements

The table below outlines relevant MDR provisions and examples of evidence manufacturers can prepare.

Manufacturers should link each applicable GSPR to its compliance evidence. Particular attention is necessary for Section 17.2, which explicitly includes information security within software lifecycle development and risk management.

These records must also remain current as relevant device risks, vulnerabilities, and operating conditions change.

How MDCG 2019 16 Guides Medical Device Cybersecurity Compliance

MDCG 2019 16 Rev. 1 helps manufacturers interpret EU MDR cybersecurity obligations and apply them throughout the device lifecycle. It also covers relevant requirements under the IVDR.

The guidance highlights four practical considerations:

• Security by design: Address foreseeable threats during device development
• Risk assessment: Evaluate how security weaknesses could affect patient safety
• Shared responsibilities: Define the security responsibilities of manufacturers, healthcare operators, and system integrators
• Ongoing security: Monitor vulnerabilities and address emerging risks after market placement

Manufacturers must establish suitable device security capabilities and explain the operating conditions needed for safe use. Healthcare organisations and integrators are responsible for relevant safeguards within the systems they manage.

Steps to Achieve EU MDR Cybersecurity Compliance

These 8 practical steps help manufacturers translate MDR obligations into engineering tasks, assigned responsibilities, and documented evidence for compliance.

Step 1. Determine Your Medical Device's Regulatory Scope

First, define your product's intended medical purpose. This determines whether it falls under the EU MDR or the EU IVDR for in vitro diagnostic devices.

Next, identify its risk classification and applicable conformity assessment procedure. Under the MDR, devices fall into Classes I, IIa, IIb, or III. The classification helps determine whether a notified body must participate in conformity assessment.

Once the regulatory scope is clear, document the complete system architecture, including:

• Hardware, firmware, and embedded software
• Mobile applications, cloud services, and APIs
• External communication interfaces and third party components
• Critical functions involving remote access, clinical data exchange, and software updates

Also, establish where the device will operate, whether on hospital networks, clinical workstations, or home monitoring systems. Record any external security dependencies that could influence its operation.

Step 2. Map Applicable MDR Requirements to Cybersecurity Controls

Create a GSPR traceability matrix to connect each applicable MDR cybersecurity provision with the controls and evidence needed to demonstrate conformity.

For every requirement, record:

• Applicability: Whether the provision applies to your device, with justification for exclusions
• Security controls: Relevant software specifications, risk controls, and implementation activities
• Supporting evidence: Document references, verification results, test identifiers, and approval records
• Responsibility: Assigned owners from regulatory affairs, engineering, cybersecurity, risk management, or quality assurance
• Compliance status: Completed, pending, or requiring further action

Ensure each entry clearly connects the regulatory requirement to the implemented measure and its verification evidence.

Keep the matrix updated as development progresses and evidence receives approval.

Step 3. Conduct Threat Modelling and Cybersecurity Risk Assessment

Identify which device assets require protection, including therapy settings, clinical measurements, firmware, patient information, and authentication credentials. Examine how attackers could access them through wireless connections, APIs, maintenance ports, cloud services, or external software.

A threat modelling method such as STRIDE helps identify potential attacks and security weaknesses.

The need for this assessment is evident in Claroty's 2025 research, which found confirmed Known Exploited Vulnerabilities in 9% of the IoMT devices analysed across 351 healthcare organisations. These findings highlight why manufacturers should consider known vulnerabilities and realistic attack paths when assessing device security.

Connect identified cybersecurity threats with ISO 14971 safety risk management by examining:

• How an attack could change device behaviour or disrupt essential functions
• Whether the resulting failure could create a hazardous situation and cause patient harm
• Which security controls can reduce the identified risks

Assess the likelihood of exploitation separately from the probability of clinical harm. Finally, verify control effectiveness and document residual risks.

Step 4. Implement Secure by Design Controls Throughout Development

Build security requirements into software specifications, architecture reviews, coding practices, and configuration management. Use change control procedures to ensure software modifications receive appropriate security review before implementation.

Key technical measures include:

• Authentication and authorisation: Limit access to sensitive functions and maintenance interfaces.
• Encryption: Protect transmitted patient information and authenticate critical communications.
• Software signing: Verify the authenticity of firmware and software before installation.
• Secure boot: Check the integrity of software during startup where technically appropriate.
• Security logging: Record relevant access attempts, configuration changes, and security events.
• Safe recovery: Maintain essential clinical functions during security incidents or system faults.
• Secure updates: Authenticate updates and verify their integrity before installation.

Security mechanisms must also work safely in clinical settings. For example, repeated authentication failures should not lock healthcare professionals out of essential treatment functions when immediate access is necessary.

Step 5. Manage Software Components and Third-Party Dependencies

Maintain a Software Bill of Materials (SBOM) to track the software included in your medical device, including commercial components, open source libraries, firmware, and dependencies used by other components.

For each component, record:

• Component name, version, and supplier
• Software identifiers and dependency relationships
• Associated device models and software builds

Recognised formats such as CycloneDX and SPDX help organise this information, although the EU MDR does not explicitly mandate either format.

Use the SBOM to monitor newly disclosed vulnerabilities and identify affected product versions. A vulnerable library does not automatically mean your device is exploitable. Investigate whether the affected code exists in your implementation, whether attackers can reach it, and whether exploitation could affect clinical safety or performance.

When suppliers release software changes, reassess compatibility, relevant security risks, and necessary verification activities. Update the SBOM and supporting documentation to reflect approved changes.

Step 6. Perform Cybersecurity Verification and Validation Testing

Security weaknesses are not always visible during development. Some only appear when software processes unexpected inputs, communicates with external systems, or operates under real clinical conditions.

Verification confirms whether implemented security controls meet their specified requirements. Validation assesses whether the device meets its intended use and relevant user needs, including security considerations.

The following testing methods help manufacturers evaluate different aspects of device security.

Not every device requires the same testing methods. Select the scope and depth according to its architecture, attack surfaces, identified risks, and applicable requirements.

Document the device version, tested configuration, methodology, coverage, findings, severity, potential clinical impact, corrective actions, and retesting results.

A penetration test showing no critical vulnerabilities does not automatically establish EU MDR compliance. The complete verification and validation evidence must demonstrate conformity with applicable regulatory requirements.

Step 7. Prepare Cybersecurity Technical Documentation for Conformity Assessment

EU MDR Annex II requires technical documentation that demonstrates conformity with applicable requirements. Annex III addresses postmarket surveillance documentation.

For cybersecurity, organise the records so reviewers can trace each applicable requirement through the associated risks, implemented controls, and verification results.

The documentation should cover the following evidence categories:

These are practical evidence categories, not mandatory standalone documents with prescribed titles.

Before conformity assessment, conduct an internal documentation review. Check that product versions match across records, outstanding findings have documented dispositions, necessary approvals are complete, and evidence links remain accurate.

Step 8. Maintain Cybersecurity After CE Marking

CE mark does not end your cybersecurity responsibilities. Under MDR postmarket surveillance obligations, manufacturers must continue monitoring device security and managing emerging vulnerabilities.

Establish a process to:

1. Collect vulnerability reports from researchers, suppliers, databases, and users.
2. Identify affected devices, software versions, and configurations.
3. Assess exploitability and potential patient harm.
4. Select mitigations or corrective measures.
5. Validate patches, compatibility, and clinical performance.
6. Notify relevant healthcare operators.
7. Update risk and surveillance records.

Plan security support and review unsupported components or changing environments.

How Does EU MDR Cybersecurity Relate to Other EU Regulations?

MedTech manufacturers using connected devices, cloud platforms, patient data, or AI systems must consider several EU regulations. Each addresses different responsibilities.

• EU MDR: Covers medical device safety, performance, risk management, and conformity assessment.
• EU IVDR: Establishes safety and performance requirements for in vitro diagnostic medical devices.
• Cyber Resilience Act (CRA): Excludes products covered by the MDR or IVDR from its product scope.
• GDPR: Regulates personal data protection and security. GDPR compliance does not establish medical device safety, while MDR conformity does not automatically satisfy privacy obligations.
• NIS2 Directive: Establishes organisational cybersecurity obligations for qualifying entities, depending on their activities and applicable national legislation.
• EU AI Act: Introduces additional obligations for qualifying AI systems, including certain medical device applications.

For example, manipulated input data or unauthorised changes to an AI diagnostic model could affect clinical results. Manufacturers must assess these risks and determine which AI Act obligations apply.

MDCG 2025- 6 provides guidance on how the MDR, IVDR, and AI Act interact.

How Medysec Helps Manufacturers Meet EU MDR Cybersecurity Requirements

Meeting MDR cybersecurity requirements involves demonstrating that your medical device's security risks have been properly assessed, addressed, and verified. Medysec helps manufacturers prepare the technical evidence needed to support regulatory conformity.

Our specialists conduct medical device penetration testing, threat modelling, and security assessments across firmware, medical software, APIs, connected applications, and cloud environments. We also assist with vulnerability analysis, remediation verification, and cybersecurity documentation relevant to EU MDR, IVDR, and CE conformity assessment.

Medysec helps you identify gaps in existing security evidence and address them before conformity assessment. Responsibility for regulatory compliance remains with the manufacturer.

Preparing your medical device for the EU market? Contact Medysec to discuss your device architecture, existing documentation, and cybersecurity testing requirements with our specialists.

Is Your Medical Device Secure?

Check your medical device security risks and find the right steps to protect patient data and meet cybersecurity requirements.

Speak with Our Experts →

Conclusion

Eu mdr cybersecurity requirements depends on how well manufacturers connect regulatory requirements with device risks, secure development practices, testing, and technical documentation. General security policies, certifications, or penetration testing reports alone cannot demonstrate that a device meets all applicable requirements.

Your evidence must show how security controls address risks specific to your device and support its intended performance and patient safety. This responsibility continues after CE marking, as new vulnerabilities, software updates, and changes in operating environments require ongoing attention.

Review your existing cybersecurity documentation, identify missing evidence, and resolve compliance gaps before your regulatory assessment.

FAQs

1. Is cybersecurity mandatory under the EU MDR?

Yes. The EU MDR requires manufacturers to address applicable cybersecurity risks that could affect medical device safety and performance. The specific security measures depend on the device's intended purpose, software functionality, connectivity, and associated risks.

2. What is the difference between EU MDR and MDCG 2019 16?

EU MDR 2017/745 is legally binding legislation establishing requirements for medical devices marketed in the EU. MDCG 2019 16 provides nonbinding guidance to help manufacturers understand and implement cybersecurity expectations under the MDR and IVDR.

3. Does EU MDR require penetration testing for every medical device?

No. The EU MDR does not explicitly require penetration testing for every medical device. Manufacturers must select appropriate verification methods based on applicable requirements and device risks. Penetration testing can provide supporting evidence where relevant.

4. Is a Software Bill of Materials (SBOM) mandatory under EU MDR?

No. The EU MDR does not explicitly mandate a document called an SBOM for every device. However, maintaining software component information helps manufacturers identify vulnerable dependencies, assess security risks, and support ongoing cybersecurity maintenance.