CE Marking Cybersecurity Requirements for Medical Devices: EU MDR & Compliance Guide

Cybersecurity can complicate CE marking long before a device reaches the market. For manufacturers, understanding CE mark medical device cybersecurity requirements becomes especially important when a product includes software, connected interfaces, or remote access features.

The risk is already visible across healthcare environments. Claroty’s 2025 research across 351 healthcare organizations found known exploited vulnerabilities in 99% of them. In 89%, medical systems were also exposed to publicly available exploits alongside insecure internet connectivity.

For manufacturers, the difficult part is often knowing what regulators expect you to prove. Vulnerability testing matters, but so do the records, security decisions, lifecycle controls, and technical evidence behind it.

With EU MDR, MDCG guidance, SBOMs, security standards, and postmarket duties all entering the picture, it is easy to lose sight of what actually belongs in your CE marking preparation. This guide sorts that out.

Understanding Cybersecurity Under EU MDR (2017/745)

EU MDR does not contain one standalone section covering every cybersecurity obligation. Instead, EU MDR software security requirements appear across safety, risk management, software development, technical documentation, user information, and postmarket activities.

Some of the key Annex I requirements include:

• GSPR 1 to 4: Establish the safety, performance, benefit-risk, and risk management foundation.
• GSPR 14.2: Addresses risks linked to the operating environment, including negative interaction between software and the IT environment.
• GSPR 17.1: Requires repeatability, reliability, and performance in line with the device’s intended use.
• GSPR 17.2: Covers software lifecycle principles, risk management including information security, verification, validation, and state of the art.
• GSPR 17.4: Requires manufacturers to define minimum hardware, IT network, and IT security requirements, including protection against unauthorized access.

Cybersecurity is not limited to privacy. Altered therapy settings, manipulated alarms, corrupted diagnostic information, or device unavailability can affect safety without exposing patient data. Physical interfaces such as USB can also create attack paths even when a device is not directly connected to the internet.

For medical device CE marking, manufacturers should be able to trace applicable GSPRs to cybersecurity requirements, identified risks, controls, verification evidence, residual risks, and the relevant technical documentation. This provides a clearer conformity argument than relying on a penetration testing certificate alone.

MDR, MDCG Guidance, and Standards Do Not Have the Same Legal Status

Not every document you encounter during MDCG 2019-16 compliance carries the same legal weight. Keeping those distinctions clear helps you understand what is mandatory and what supports your conformity evidence.

MDCG 2019 16 Rev.1 is guidance, not legislation. The European Commission continues to list the July 2020 revision as its medical device cybersecurity guidance and describes MDCG guidance documents as legally nonbinding.

Standards need the same care. A standard gains the MDR presumption of conformity only when its reference has been published in the OJEU, and only for the requirements it covers. The Commission’s current MDR harmonised standards list includes updates published as recently as 17 June 2026.

For that reason, manufacturers should verify the current OJEU status of standards such as IEC 81001 5 1 or IEC 62304 before describing them as MDR harmonised.

The 4 Core Cybersecurity Pillars for CE Marking Compliance

These four pillars provide a practical way to organize cybersecurity work for CE marking. They are not formally defined as four pillars in the MDR.

1. Secure Design and Development

Cybersecurity should be considered while you define the device architecture and security requirements. Annex I 17.2 supports this lifecycle approach by linking software development with information security, risk management, verification, validation, and state of the art.

Start by identifying the attack surface relevant to your device, such as:

• Firmware and software
• APIs, cloud services, and connected applications
• Wireless interfaces
• Maintenance ports, USB, and removable media
• Third-party software components

The controls you choose should match the actual risks. Depending on the device, these can include authentication, access restrictions, encryption, secure communication, protected updates, integrity checks, logging, hardened configurations, and recovery mechanisms.

2. Cybersecurity Risk Management and Its Link to Patient Safety

Cybersecurity risk management should show what a security weakness could do to the device and whether the resulting change could put a patient at risk.

A useful way to document that connection is:

Threat → vulnerability → attack → change in device behaviour → hazardous situation → possible harm

For example, weak authentication in a connected infusion system could allow unauthorized changes to dosage settings. Recording only “unauthorized access” does not capture the full medical device risk. The assessment should consider how the altered dosage affects device operation and what harm could follow.

3. Software Component and SBOM Tracking

An SBOM is a record of the software components and dependencies used by a device. Although EU MDR does not expressly require one for every product, keeping this inventory gives manufacturers much better visibility into what is actually running inside or supporting the device.

It can help you:

• Match newly disclosed CVEs to components you use
• Identify which device versions are affected
• Prioritize patches or other security actions
• Monitor component vulnerabilities after release

SBOM tracking goes a step further. The inventory should be updated when components are added, removed, upgraded, or replaced. Version information should stay linked to the corresponding device or software release. When a new vulnerability appears, teams can then check which released products contain the affected version and follow the response through remediation.

The inventory should not stop at open source libraries. Operating system packages, SDKs, cryptographic libraries, firmware dependencies, APIs, commercial software, and relevant cloud components can also matter.

4. Post-Market Vulnerability Management and Vigilance

After release, new vulnerabilities need a defined process for investigation and response. MDCG 2025 10, published in December 2025, provides broader Commission guidance on postmarket surveillance for medical devices and IVDs.

When a vulnerability is confirmed, the response can follow:

Validate → assess exploitability → evaluate safety impact → select remediation → verify → deploy → communicate → monitor effectiveness

Patches should go through controlled change management. Before deployment, manufacturers need to confirm that the correction addresses the security issue without affecting device safety, performance, or intended operation.

The outcome should also be reflected in the relevant PMS, risk management, corrective action, and vigilance records where applicable.

Why Risk-Based Third-Party Penetration Testing Matters for CE Cybersecurity Evidence

Annex I 17.2 requires software security to be verified and validated, but it does not prescribe the same test programme for every device. For medical device penetration testing under EU MDR, scope should reflect the architecture, exposed interfaces, and identified risks.

Penetration testing is especially useful for connected products, exposed APIs, wireless interfaces, cloud services, mobile applications, update mechanisms, privileged maintenance access, and complex authentication paths.

A useful penetration test report identifies the exact release tested, scope, interfaces, methodology, findings, exploitability, security and safety impact, remediation, and retest status. Testing an unspecified build weakens traceability.

An external specialist can add an adversarial perspective, but independent testing alone does not guarantee CE conformity.

Step-by-Step Roadmap to Achieve CE Cybersecurity Compliance

Step 1: Define the Device, Intended Environment, and Cybersecurity Scope

First, establish exactly what the cybersecurity assessment covers.

Document the device purpose, intended users, architecture, software components, data flows, trust boundaries, connected systems, network connections, local interfaces, and update mechanisms. These details define the product configuration that later risk analysis and testing will refer to.

Do not assume an offline device has no cybersecurity exposure. USB connections, removable media, service ports, and maintenance tools can still provide access to software or data.

A clear scope prevents different teams from assessing different versions or boundaries of the same product and gives the technical documentation a consistent reference point.

Step 2: Map Applicable MDR Requirements

For CE marking, medical device manufacturers should create an applicability map rather than work from a generic compliance checklist.

Record each relevant GSPR and state whether it applies to the product, along with the reasoning. Software-containing devices deserve particular attention under Annex I 17.1, 17.2, and 17.4, while cybersecurity risks should also be connected to the wider safety and risk management requirements.

Next, document the sources you will use to support conformity, including applicable standards, MDCG guidance, technical frameworks, and other credible state-of-the-art references. This creates a clear basis for the security requirements and evidence developed in the following steps.

Step 3: Perform Cybersecurity Risk and Threat Analysis

Use threat modelling suited to the device architecture to examine credible attack scenarios and the weaknesses that could enable them.

The findings should feed into the existing medical device risk management records rather than becoming a separate security file with no connection to safety documentation. Link relevant cyber risks to the corresponding hazards, controls, and residual risk decisions.

Step 4: Define and Implement Security Requirements

Convert the risks identified earlier into specific security requirements that can be implemented and verified. Each requirement should state what the control must achieve and provide a clear basis for later testing.

Also document the operating conditions the software relies on. Annex I 17.4 requires manufacturers to specify the minimum hardware, IT network characteristics, and IT security measures needed for intended operation, including protection against unauthorized access.

Keep these requirements linked to the relevant risk records and design documentation so the implemented controls can be traced during verification and conformity assessment.

Step 5: Build the Cybersecurity Technical Documentation Package

By this stage, the work should come together as a traceable evidence package rather than a collection of separate security files.

For CE certification of medical devices, the documentation can include, where relevant:

• GSPR mapping, security requirements, architecture, interfaces, and data flows
• Threat modelling, cyber risk records, and links to safety risk management
• Component inventories, development records, and vulnerability assessments
• Security testing, penetration testing, remediation, and retest evidence
• Residual risk decisions, update procedures, and operating environment requirements
• User security information, vulnerability monitoring, and postmarket security procedures

There is no universal cybersecurity document bundle that applies unchanged to every medical device. 

Step 6: Verify and Validate the Implemented Security Controls

Choose security tests according to the device architecture, exposed interfaces, and identified risks. Verification should confirm that individual controls work as intended, while broader testing should examine whether several weaknesses could be combined into a realistic attack path.

Any finding needs a documented outcome. Record whether it was fixed, accepted with justification, or addressed through another control, and keep that decision linked to the exact software, firmware, or device release tested.

When penetration testing identifies a vulnerability, retest the relevant fix before closure. The resulting evidence should show that the issue was addressed in the release intended for conformity assessment, not merely corrected in an unspecified build.

Step 7: Prepare for Conformity Assessment and Lifecycle Monitoring

Before conformity assessment, check that every cybersecurity requirement can be followed through to the controlled document containing its supporting evidence. Annex II expects manufacturers to cross-reference this evidence within the technical documentation.

Notified Body involvement depends on the device classification and the conformity assessment route under Article 52. Where one is involved, your team should be ready to explain:

• The security architecture
• Risk decisions
• Test coverage
• Unresolved findings
• Residual risks, and the controls planned for continued oversight after release.

Once the device enters the market, keep the relevant surveillance, patching, PMS, and vigilance processes active throughout its lifecycle. MDCG 2025 10 provides current Commission guidance on postmarket surveillance under the MDR and IVDR.

How Qualysec Supports MedTech Companies Preparing Cybersecurity Evidence for CE Marking

Security testing becomes more useful when the results can be connected to the device version, the identified risk, and the evidence your team is already preparing.

Qualysec tests firmware, communication protocols, hardware interfaces, authentication, cloud connections, update mechanisms, and external integrations relevant to CE mark medical device requirements. Its work can support cybersecurity activities informed by MDCG 2019 16 Rev.1 and secure lifecycle practices described in IEC 81001-5-1.

The assessment model can be chosen according to the evidence you need:

• Black Box: examines exposure from an external attacker perspective.
• Gray Box: allows closer testing of authenticated functions and internal paths using limited system knowledge.
• White Box: gives testers access to source code, firmware, APIs, and architecture, which can support deeper verification of implementation and design weaknesses.

Qualysec documents findings, reproduction details, remediation guidance, and retest results. These records can contribute to the verification evidence included in MDR technical documentation and can inform the manufacturer’s ISO 14971 risk management records. They do not replace the manufacturer’s responsibility for conformity, risk management, or regulatory documentation.

Preparing a connected medical device or healthcare software product for assessment? Talk to Qualysec’s cybersecurity team or request a penetration testing quote.

Conclusion

For a medical device manufacturer, cybersecurity evidence needs to hold up beyond a single test or submission milestone. The MDR expects technical documentation to show which requirements apply, how conformity was demonstrated, and where the supporting evidence can be found.

That evidence will look different from one device to another. MDR obligations come first, while MDCG guidance, harmonised standards, and other technical practices help shape how you address them. MDCG guidance itself is not legally binding.

Independent penetration testing can add useful evidence when the device risk and architecture justify it, particularly when findings are fixed and retested. For CE Marking of medical devices under the EU MDR, cybersecurity evidence should support the device’s safety, performance, risk management, and applicable regulatory requirements.

If your security records clearly show what was identified, what was done about it, and how it was verified, the conformity assessment has a much stronger technical basis.

FAQs

1. What are the core EU MDR cybersecurity requirements for medical devices?

EU MDR addresses cybersecurity through several requirements rather than one dedicated rule. For software-containing devices, Annex I 17.2 covers information security, verification, validation, lifecycle development, and state of the art, while 17.4 covers operating conditions and protection against unauthorized access. Wider risk management, documentation, and postmarket duties also apply.

2. Is compliance with MDCG 2019 16 legally mandatory for a CE Mark?

No. MDCG 2019 16 Rev.1 is not legislation and does not carry the same legal force as the MDR. The Commission describes MDCG documents as nonbinding guidance intended to support consistent application of MDR and IVDR requirements. Manufacturers should still consider it when shaping and explaining their cybersecurity approach.

3. Do Notified Bodies require penetration testing and fuzz testing for CE approval?

Not as a universal rule for every device. MDR Annex I 17.2 requires appropriate verification and validation, but the testing approach should reflect the product architecture and security risk. Penetration testing, fuzzing, code analysis, scanning, or other methods can contribute where they provide relevant evidence.

4. What is a Software Bill of Materials SBOM, and why is it used for CE Marking?

An SBOM is an inventory of software components and dependencies associated with a product. It helps manufacturers identify affected components when vulnerabilities emerge, track CVEs, plan updates, and support postmarket monitoring. MDR does not expressly name an SBOM as a mandatory document for every medical device.

5. How do security patches and updates affect an existing CE Mark?

A vulnerability fix does not automatically invalidate an existing CE mark. Manufacturers should assess the affected versions, safety implications, change significance, and any regulatory consequences before deployment. The fix also needs verification, documentation, configuration control, and continued monitoring. Cyber events meeting serious incident criteria must be evaluated under MDR vigilance rules.