Key Takeaways –
- EU MDR Regulation (EU) 2017/745 embeds cybersecurity within the General Safety and Performance Requirements (GSPR) under Annex I.
- Annex I clauses 14.2(d), 17.2, and 17.4 include cybersecurity requirements that connected or medical device manufacturers need to comply with.
- The modern healthcare device manufacturer must implement cybersecurity in the complete product lifecycle from the beginning to post-market surveillance.
- The technical documentation under MDR GSPR cybersecurity requirements recommends Software Bill of Materials (SBOM), a cybersecurity risk management file, and security test evidence.
- Although penetration testing is not mentioned specifically in MDR guidelines, the regulatory authorities expect it for evidence purposes.
Introduction:
Did you know that around 100+ million individuals were affected by healthcare industry cyberattacks in 2023? The more surprising fact is that it doubled, as it was around 44 million in 2022. The majority of manufacturers worldwide consider cybersecurity a one-time or last-stage concern. However, the reality is little different; cybersecurity is a core part of the processes and systems. That’s where the MDR GSPR cybersecurity requirements come into play, which establish the core responsibilities and frameworks for addressing hacking or exploitation attempts.
EU MDR Regulation (EU) 2017/745 sets clear regulations for medical device manufacturers under cybersecurity rules by General Safety and Performance Requirements (GSPR). It involves the processes around safety, security, and protection from unauthorised access. In case these regulations find a medical manufacturer to be in non-compliance, they may lead to non-conformities, delays, or failure in conformity assessment.
Our 2025-2026 audit observations show that the organisation have advanced its compliance assessment methods beyond check-box compliance. They now seek to obtain Information Gain by examining how manufacturers use their threat models to protect against actual cyber threats that have been documented during the last 12 months.
In this detailed blog, let’s dig deep into the expectations of the MDR GSPR cybersecurity requirements. Keep reading till the end to understand what to implement and what regulatory authorities expect while evaluating the EU MDR compliance.
What Are MDR GSPR Cybersecurity Requirements?
According to ENISA’s Health Threat Landscape report (2023), healthcare is one of the most targeted sectors in cybersecurity incidents. The figure highlights the importance of EU MDR GSPR cybersecurity regulations.
The General Safety and Performance Requirements (GSPR) involve the basic requirements for medical devices to get the CE marking and sell in the European market. In simple terms, these regulations bind the medical manufacturers to cover everything from mechanical safety to clinical performance.
Nowadays, more and more connected and software-driven medical devices are becoming common in the clinical space. That’s where cybersecurity entered the GSPR framework to implement security approaches. The older Medical Device Directive (MDD) had security practices that were only at the manufacturer’s discretion.
A single loophole (like a compromised device) can directly impact the patients. EU MDR GSPR cybersecurity practices require medical device manufacturers to consider IT security with maximum importance. The GSPR cybersecurity requirements are applicable to any device that has software ( SaMD), network connections (Wi-Fi, Bluetooth, or cellular), remote access, data processing, and data storage.
Note: The EU AI Act states that Medical devices which use Artificial Intelligence (MDAI) will receive high-risk AI system status because of their AI capabilities from 2026 onwards. The new harmonised framework requires you to change your GSPR 17.2 documentation by adopting data governance and human oversight requirements established by the AI Act to prevent multiple audit failures.
Overview of MDR GSPR Cybersecurity Obligations
| GSPR Clause | Requirement Summary | Applies To |
| Clause 14.2(d) | Software must not introduce unacceptable safety risks | All software-based devices |
| Clause 17.2 | Software must be developed per state-of-the-art principles covering lifecycle, risk management, and information security | Connected and software devices |
| Clause 17.4 | Manufacturers must define minimum hardware, IT network, and IT security requirements to run software as intended. | All software-based devices |
| Annex I (General) | Ongoing post-market surveillance of security vulnerabilities | All CE-marked devices |
Connect with our specialists to learn how to meet MDR GSPR cybersecurity requirements, strengthen your device security, and avoid regulatory penalties
Talk to our Cybersecurity Expert to discuss your specific needs and how we can help your business.
What are the Key MDR Annex I Cybersecurity Requirements?

Clause 14.2(d): Software Safety Performance
As per this clause of medical device cybersecurity MDR regulations, a medical software needs to perform as intended with no safety risks or threats. In reality, this means that the medical device manufacturers need to validate and verify the medical software across the development lifecycle, instead of just considering it during deployment. Some of the core responsibilities under this clause are documented testing, test results, and traceability between requirements.
Clause 17.2: IT Security for Software-Based Devices
Clause 17.2 requires that medical device software be developed and manufactured in accordance with state-of-the-art principles, covering the full development lifecycle, risk management, information security, and verification and validation processes. This makes the cybersecurity practices implemented throughout the software design phase as well. All medical manufacturers are required to perform structured threat modelling to figure out the potential attack vectors.
Clause 17.4: Protection Against Unauthorised Access
Clause 17.4 applies to all software-based medical devices, regardless of whether they are network-connected or accessed remotely. Manufacturers must define minimum hardware, IT network, and IT security requirements to run software as intended.
In 2026, the State-of-the-Art requirements state that organisations must now meet all EN IEC 81001-5-1:2022 standards because these standards serve as their new baseline requirements, which extend beyond basic lifecycle requirements of IEC 62304.
MDR Annex I Clause vs. Cybersecurity Control Mapping
| Annex I Clause | Cybersecurity Control Required | Supporting Standard |
| Clause 14.2(d) | Software validation, verification, and security testing | IEC 62304 |
| Clause 17.2 | Threat modelling, cybersecurity risk assessment | MDCG 2019-16, STRIDE |
| Clause 17.4 | Protections such as secure boot and firmware integrity validation to prevent unauthorised modification of device software. | IEC 81001-5-1, ISO/IEC 27001 |
| Post-market (Annex III) | Vulnerability disclosure process, patching timelines | MDCG 2022-21 |
Is Penetration Testing Required for MDR GSPR Compliance?
MDR doesn’t specifically mention the requirement of penetration testing anywhere in the regulation. However, it is important because the Notified Bodies commonly expect higher-risk or connected devices.
Security Testing Types Expected Under MDR GSPR
| Testing Type | Purpose | MDR Relevance |
| SAST (Static Analysis) | Identify code-level vulnerabilities before execution | Clause 14.2(d) — software safety |
| DAST (Dynamic Analysis) | Test a running application for exploitable flaws | Clause 17.2 — IT security |
| Penetration Testing | Simulate real-world attacks on the full device | Clause 17.4, MDCG 2019-16 |
| Vulnerability Scanning | Ongoing monitoring of known CVEs in components | Post-market surveillance |
| Fuzz Testing | Test input handling robustness and edge-case behaviour | Software safety validation |
Based on our observations, organisations require Class IIb submissions to submit independent penetration test reports, which must contain a Vulnerability Exploitability eXchange (VEX) document as proof that particular SBOM legacy CVEs do not pose security threats to the device’s operational setup.
Download a free sample pentesting report and understand how security testing supports MDR GSPR compliance.
Get a Free Sample Pentest Report

EU MDR GSPR Cybersecurity Compliance Checklist
For a medical software and device manufacturer, meeting the EU MDR Annex I compliance checklist requirement is not a one-time exercise. The company or individual manufacturer needs to integrate these into the entire device lifecycle. From initial risk assessment to post-market surveillance, the checklist below covers the comprehensive areas that regulatory authorities consider during conformity assessment.
The table below can be a practical reference to figure out gaps between your medical device manufacturing and CE marking barriers.
| Compliance Area | Requirement | Status |
| Risk Management | ISO 14971-aligned cybersecurity risk management file | Mandatory |
| SBOM | Full inventory of software components and dependencies | Mandatory |
| Threat Modelling | STRIDE or equivalent methodology documented | Expected by Notified Bodies |
| Secure SDLC | Security integrated into the IEC 62304 lifecycle processes | Mandatory |
| Penetration Testing | Independent third-party test report available | Expected (not named explicitly) |
| Patch Management | Defined vulnerability handling and patch processes | Mandatory (post-market) |
| CVD Policy | Published coordinated vulnerability disclosure process | Mandatory |
| Incident Reporting | Mechanism for reporting serious incidents in place | Mandatory (Article 87) |
What Are Common Mistakes Manufacturers Make With MDR Cybersecurity Compliance?

When it comes to compliance with medical device cybersecurity MDR regulations, even the most experienced manufacturers miss things. Here are some of the common gaps for medical devices in accordance with the conformity assessments:
1. The majority of the medical device or connected software manufacturers consider cybersecurity as a one-time task. However, the MDR regulations require continuous surveillance for security activities to continue after CE marking as well.
2. A lot of medical device manufacturers fail to implement an organised process for tracking third-party software components. Incomplete SBOM requirements, as per the expectations, can lead to immediate misses in the documentation.
3. Medical software updates are continuous processes with timely software upgrades. These are the scenarios with loopholes that the modern-day hackers would prefer. There should be proper updates in the technical documentation after security upgrade patches.
4. All the medical devices placed on the EU market after May 2021 need to comply with the MDR GSPR cybersecurity requirements.
5. Some medical device manufacturers end up missing the CVD policies that are for receiving and acting on vulnerability reports.
How Does QualySec Help Medical Device Manufacturers Meet MDR GSPR Cybersecurity Requirements?
In order to comply with the EU MDR GSPR cybersecurity regulations, manufacturers need more than just the intent. They need to follow the rules as per the required documentation, testing, and auditable evidence reports.
That’s where Qualysec Technologies, the best cybersecurity company, can bring in its deep experience and expertise to the table. With our expert security specialists and compliance experts, you can get CE marking across the EU while following the required guidelines.
What Does QualySec Deliver for MDR Compliance?
1. We conduct medical device penetration testing to check the network, application, APIs, and, more specifically, as per the MDCG 2019-16 requirements. With us, you can get structured reports that can be submitted to the Notified Body review.
2. Our VAPT (Vulnerability Assessment and Penetration Testing) identifies the vulnerabilities that pose hacking or exploitation risks.
3. As per medical device cybersecurity MDR guidelines, we review all software components for known CVEs, license risks, and unpatched dependencies.
4. Our cybersecurity experts perform Cybersecurity risk management to create documentation aligned with ISO 14971, IEC 62304, and IEC 81001-5-1.
5. Not just with the medical device manufacturer CE markings, the Qualysec team also supports ongoing vulnerability monitoring, policy drafting, and post-market surveillance.
At Qualysec, we create structured reports that align with the expectations of the Notified bodies in the EU. Our experience across EU MDR, FDA cybersecurity guidance (2023 final guidance), and IEC 81001-5-1, our team understands the regulatory contexts.
Contact Qualysec if your medical device is going for conformity assessment or if you are unsure about the cybersecurity documentation in the EU.
Conclusion
Hence, the MDR GSPR cybersecurity requirements are mandatory obligations instead of guidelines for healthcare device or software manufacturers. The clauses under this cover the specific security expectations for software-based and connected devices in the European Union market.
These regulations bind smart medical manufacturers to treat cybersecurity as a constant cycle. They need to plan for early threat detection, safety practices, and deep testing against the set rules. Further, the device developers need to keep a watch on the potential risks after the EU market release.
Partnering with reliable cybersecurity partners will ensure that the technical documentation and process are handled correctly from the beginning. It will be the best decision to ensure the launch of secure medical software without any delay or legal trouble.
Find Your Perfect Security Partner

Frequently Asked Questions
1. What are MDR GSPR cybersecurity requirements?
The MDR GSPR cybersecurity requirements involve the set of expected responsibilities under Annex I of EU MDR 2017/745. In simple words, these regulations are for the medical device manufacturers to address IT security as a core part of the device security practices. Under various clauses mentioned above, these cybersecurity requirements cover safety performance, risk control, and safety against unauthorised access.
2. Which MDR Annex I clauses cover cybersecurity?
Clause 14.2(d) involves the safety of the medical software and validation against various checklists. Similarly, Clause 17.2 requires that developers and manufacturers create software in medical devices in accordance with state-of-the-art principles, covering the development lifecycle, risk management, information security, and verification and validation. Clause 17.4 safeguards the hardware and software against any unauthorised access to steal the sensitive patient information.
3. How do manufacturers demonstrate cybersecurity compliance in GSPR?
As per MDR essential safety requirements, the manufacturers showcase the compliance standards with technical documentation in the conformity assessments. In reality, this includes cybersecurity risk management, SBOM (Software Bill of Materials), design security controls, penetration testing, and proof of security testing as expected from the Notified Bodies.
4. Is penetration testing required for MDR GSPR compliance?
Penetration testing is not mentioned as a specific requirement in the MDR GSPR cybersecurity requirements. However, this needs to be expected as supporting evidence by the Notified Bodies for connected devices or remote healthcare products.
5. What documentation is needed for cybersecurity in MDR?
The core documents, as per the EU MDR Annex I compliance checklist, include a risk management file, a complete SBOM, security architecture, design documentation, and security test reports. Further, the documentation needs to have a CVD (Coordinated Vulnerability Disclosure) policy and process to include cybersecurity incidents in the Periodic Safety Update Report (PSUR).


















































































































































































































































































































































































































































































































































































































0 Comments