How Does EU MDR Penetration Testing Identify Risks in SaMD and Class II/III Devices?

Preparing a medical device to meet the EU MDR requirements can be difficult in some cases. It can be challenging when cybersecurity testing doesn’t cover its complete attack surface. The vulnerabilities may not be known until the APIs, cloud services, mobile apps, wireless interfaces, firmware, and hardware are tested. EU MDR Penetration testing makes it possible to identify risks in SaMD and Class II/III medical devices.

Penetration testing is more than just vulnerability scanning because it involves attacking the medical devices and their network components. Testers perform manual testing to simulate attacks, including exploit testing, authentication checks, protocol fuzzing, and firmware analysis. 

In this guide, we will discuss how EU MDR penetration testing is performed to uncover vulnerabilities. We will also discuss penetration testing for Software as a Medical Device (SaMD) and Class II/III medical devices. We will cover what needs to be done to comply with regulations.

Key Takeaways

• The EU MDR penetration testing includes the entire attack surface of connected medical devices.
• Penetration testing uses automated scanning along with manual exploitation and security testing.
• Software as Medical Device testing includes apps, APIs, cloud, and AI, and Class II/III devices include firmware, wireless, and hardware testing.
• Findings are assessed for their impact on device safety, functionality, data, and integrity.
• The test results should comply with ISO 14971 risk management and applicable GSPRs.
• Vulnerabilities should be fixed and retested to ensure that security validation is complete.
• Post-market surveillance ensures continued security of devices as vulnerabilities emerge and software changes are made.

What Is EU MDR Compliance for Connected Devices?

EU MDR compliance for connected devices means it is necessary to satisfy those safety, security, and risk management criteria. The criteria should be relevant to the software, networks, and connectivity of the device during its entire lifecycle.

For connected medical devices, this includes the assessment of cybersecurity risks and the protection of data and functionality. It also covers documentation of security measures and vulnerability management after deployment of the device. Such requirements apply to medical devices utilising cloud services, application programming interfaces (APIs), mobile applications, wireless communication, or other connected components.

The objective is to ensure that any cybersecurity problem does not affect the safety or performance of the device or any personal data collected by it.

What Are the Main Components of EU MDR Compliance?

Obtaining compliance for connected medical devices requires the three operational pillars to be aligned:

• Quality and Risk Management: You will have to ensure that security risk management is directly built into your ISO 14971 process. This proves that the threats associated with security will be reviewed as any physical or biological risks.
• Documentation and Safety Evidence: Notified Bodies will require evidence in totality. In this context, threat models, Software Bill of Materials (SBOMs), logs of vulnerability scans, and penetration testing reports should be made available.
• Technical documentation and safety evidence: Notified Bodies expect complete, verifiable evidence. This means providing threat models, a detailed Software Bill of Materials (SBOM), vulnerability scan logs, and comprehensive penetration testing reports.
• Post-market surveillance: Once you have obtained your CE certification, compliance is not over. Post-market surveillance requires you to track new threats and manage zero-day vulnerabilities in third-party libraries. It also provides security patches for your device throughout its whole lifetime.

Why Does EU MDR Require Cybersecurity?

Cybersecurity is required under the EU MDR to ensure safety and security throughout the medical device life cycle. Connected medical devices are vulnerable to risks through the network, cloud, API, and wireless technologies.

Any security flaw in medical equipment can provide hackers with a gateway to hospital networks or even jeopardize patient health.

Modification From MMD to EU MDR

The modification from the previous Medical Device Directive (MDD) to EU MDR brought compulsory cybersecurity requirements. The requirements are related to software integrity, data security, and security by design.

Requirements of GSPR 14.2 and 17.2

The General Safety and Performance Requirements (GSPR) listed in Annex I of the EU MDR define particular standards for software and linked hardware:

• GSPR 14.2: Emphasises interoperability. Devices meant to interface with other networks or systems must run securely without disrupting performance, data integrity, or user safety.
• GSPR 17.2: Explicitly requires that software be developed and produced in accordance with the state of the art. This includes strong risk management, safe coding techniques, and validated cybersecurity controls throughout the software development life cycle. 

MDCG 2019-16 Recommendation

The Medical Device Coordination Group issued the MDCG 2019-16 document that gives guidance on the aspect of cybersecurity in medical devices under the EU MDR. The recommendations include:

• Development security: Incorporate cybersecurity at all phases of the software development lifecycle, including design, risk analysis, testing, and release.
• Security testing: Conduct independent penetration testing as well as other forms of security testing to detect and verify vulnerabilities in the device attack surface.
• Vulnerability management: Have processes for vulnerability disclosure, vulnerability assessment, remediation, and security updates in place.

How Does EU MDR Penetration Testing Work?

Penetration testing involves much more than just using automated tools to test for vulnerabilities. Security experts try to defeat authentication, break through communication methods, and abuse system weaknesses. They do testing in the same manner as an actual attacker would. 

EU MDR penetration testing services use a proven 5-stage process:

EU MDR penetration testing follows a five-step process of risk assessment, vulnerability scan, manual testing, interface testing, and remediation with retesting.

1st Step: Identification of Risks on the Device

• Threat modelling: Testers develop an ecosystem model of the device to gain information about data paths, trust boundaries, and targets.
• Critical safety functionality: Critical aspects are identified by testers in which malfunction or data manipulation can result in direct harm to the patient. For example, dosage calculation algorithms or emergency alerts.
• Data and communication pathways: Testers document all points of access, which include REST API, WebSockets, BLE, Wi-Fi, and physical ports.

2nd Step: Scanning for Vulnerabilities

• Automated vulnerability scan: Automated systems detect vulnerabilities in the form of misconfigurations, open ports, and poor cryptographic settings in the system.
• Vulnerable libraries and dependencies: The tester checks the device’s Software Bill of Materials (SBOM) against publicly available vulnerabilities (CVEs).

 3rd Step: Conducting Manual Security Tests

• Authorisation: The testers try to control the user’s session, bypass the login screen, and increase their privileges from low levels to administrative control.
• Exploitation and penetration testing: The testers run safe exploits in order to check whether the detected vulnerabilities. This allows executing remote code or manipulating the system.

4th Step: Testing Device Interfaces

• Protocol fuzzing: Testers attack the communications protocol with vast quantities of unexpected data in order to observe the response of the software.
• Unexpected inputs and malformed inputs: The testing is performed to determine if an abnormal or corrupt input, such as a buffer overflow, will result in system failure. This test also determines if the abnormal inputs lead to system freezing.

5th Step: Fix and Retest Vulnerabilities

• Test remediation effectiveness: Once your engineering team has applied patches to improve security, testers will attempt to re-exploit these vulnerabilities. This ensures the vulnerabilities have been adequately patched.
• Identify potential regressions: Testers ensure that patches have not affected the functionality of core medical functions.

How Does Penetration Testing Identify Risks in SaMD?

A Software as a Medical Device (SaMD) runs on generic platforms such as smartphones, web browsers, and cloud computing. Because generic platforms have open network access by default, SaMD poses its own security challenges.

What unique vulnerabilities exist in standalone medical software?

SaMD applications depend a lot on external libraries, sockets, and local databases. The problems revealed by penetration testing include unencrypted local storage, incorrect session timeouts, hard-coded API keys, and poor code obfuscation. These vulnerabilities make it possible for hackers to reverse engineer proprietary algorithms.

How are cloud backend systems and medical APIs evaluated?

Cloud backends that combine patients’ information and conduct remote diagnostic services are top priorities to be tested. Web APIs are being checked for vulnerabilities such as BOLA, meaning Broken Object Level Authorization. This allows the user to access another patient’s information by changing only the ID number.

How do testers identify flaws on consumer smartphones?

Consumer smartphones operate in an untrusted environment where users can root or jailbreak their smartphones. The bugs found in mobile apps include poor runtime security, lack of sandboxing, leakage of sensitive information in system logs, and vulnerability to dynamic analysis tools such as Frida or Objection.

How do security teams test AI and machine learning diagnostic models?

AI-powered SaMD is highly dependent on the integrity of the model used. In testing processes, one may evaluate a machine learning pipeline for data poisoning, manipulation, and model inversion.

Want a Sample Security Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report →

How Does Penetration Testing Identify Risks in Class II and III Devices?

High-risk equipment, including infusion pumps, monitors, surgical equipment, and cardiac implant devices, involves physical circuitry, firmware, and wireless connections. In this case, the breach is not just data exposure; there is a risk of physical injury to the user.

I. How do testers uncover vulnerabilities in low-level firmware?

The process of testing firmware includes the extraction of binary code from hardware chips or update files. Testers reverse-engineer the code in order to find hardcoded passwords, internal communication without encryption, and potential memory corruption issues. In addition to that, testers check secure boot processes to prevent the execution of malicious firmware.

II. How are physical hardware interfaces tested for vulnerabilities?

Class II and Class III devices are tested physically. Security researchers physically connect them to the board interfaces such as JTAG, UART, and SWD debugging ports. It helps to find out whether an adversary can dump the memory, perform lockout attacks, and extract keys with physical access.

III. How are wireless communication risks identified?

Connected gadgets use wireless communication technologies such as Bluetooth Low Energy (BLE), Wi-Fi, or custom RF signals. Radio packet sniffing, man-in-the-middle, and replay attacks are conducted to ensure the telemetry data and remote commands are encrypted and authenticated.

What Should Your Penetration Testing Report Include?

Security auditors will never accept a standard IT audit document from an organisation. For your technical documentation under the EU MDR, your report should include:

• Executive summary: An overview of the security of the medical device and the remaining risk for executives and regulators to understand.
• Scope and methodology: A detailed outline of the test parameters, target environments, testing software utilised, and applicable reference models. For example, MDCG 2019-16 and OWASP Top 10.
• Risk ratings mapping: All identified risks need to be categorised and rated according to CVSS standards and then mapped to your ISO 14971 risk management matrix.
• Remediation guidance: Clear technical guidance that will help your engineers to address the identified security vulnerabilities.
• Re-testing attestation: Proof of testing of the security improvements and confirmation of fixing all critical risks.

How Can You Maintain Post-Market Security After Launch?

Compliance with the MDR EU is a continuous life cycle activity and not a one-time activity. You need to conduct a continuous security process even after your product goes into the market.

I. How to integrate testing findings into continuous surveillance?

The results of penetration testing, SBOMs, and threat intelligence feeds should be directly fed into your PMS and QMS systems. If any zero-day vulnerability is found within the open-source components, the engineering team can evaluate the risk to the deployed devices promptly.

II. How to update medical software without breaking compliance?

Security patches should be rolled out seamlessly without any disruption to device validation. Creating an Over-The-Air (OTA) system using robust cryptographic code signing will enable you to roll out these security patches immediately with full auditing capabilities.

III. What triggering events legally require a device retest?

Security retesting can be required under the EU MDR guidelines when:

• You perform any significant architecture changes in your software or hardware.
• There is a disclosure of any Critical or High-level vulnerability in one of your key dependencies.
• Significant changes in the operating system or deployment environment, such as major iOS or Android version changes.
• Your scheduled annual post-market surveillance review dictates a routine security audit.

How Do You Choose a Medical Device Penetration Testing Partner?

Not all cybersecurity companies have the knowledge of medical devices and European regulatory requirements. Choosing a vendor that is familiar with EU MDR penetration testing guarantees proper technical reports instead of generic ones.

The key capabilities include:

• MedTech experience: Select partners with proven skills in hardware debugging, embedded firmware development, and medical communication protocols like DICOM, HL7, FHIR. They should also be capable of mobile SaMD platforms.
• Regulatory familiarity: Make sure that the company has a complete understanding of MDCG 2019-16 recommendations, ISO 14971 risk integration, and EU MDR submissions.
• Manual testing expertise: Stay away from companies whose approach is dominated by automated scanning tools. Insist on manual testing, protocol fuzzing, and physical board probing.
• Audit-ready deliverables: Make sure that test reports include CVSS scores, ISO 14971 risk maps, and CEO sign-offs for Notified Bodies’ reviews.

Quick Checklist Before an EU MDR Audit

Make sure you are ready for regulatory cybersecurity testing with these simple checks:

• Threat model documentation covers all endpoints, communication flows, and data.
• Software Bill of Materials listing all third-party and open-source code.
• Penetration test conducted by professional engineers specialising in EU MDR medical device penetration testing.
• Clear traceability matrix linking test evidence to GSPR 14.2 and 17.2 requirements.
• All High and Critical vulnerabilities fixed, tested again, and validated.
• Vulnerability disclosure process and patch management embedded in QMS.

How does Qualysec perform EU MDR Penetration Testing for SaMD and Class II/III Devices?

Qualysec is a CREST-accredited penetration testing company helping with EU MDR compliance. We streamline medical device cybersecurity compliance to be understandable, efficient, and geared towards patient safety. We work with device manufacturers to offer practical testing that complies with the European regulatory requirements without unnecessary terms and delays.

As a human-led, AI-powered EU MDR penetration testing company, we focus on:

• Deep SaMD Cloud & App Security Testing: You will receive manual review of your medical APIs, mobile app runtime protection, and local storage encryption. This will ensure your software is completely hardened from reverse engineering.
• Firmware & Hardware Security for II/III Class Medical Devices: If your medical device is a physical or embedded device such as an infusion pump or monitor, you get proper analysis. These include secure boot verification and hardware-level inspection (JTAG/UART) to find hidden credentials and vulnerabilities.
• Custom Remediation Guidance for Engineers: You should not worry about getting a huge list of false positives from automatic scan results. Get clear vulnerability repro steps, technical background information, and concrete coding fixes tailored for medical software.
• Post-Market & SBOM: We go beyond initial testing and help analyse your Software Bill of Materials (SBOM). We also monitor CVEs to facilitate Post-Market Surveillance (PMS).
• Retesting & Audit Proof: We re-evaluate all applied patches to confirm your security fixes work, providing an official Attestation of Retesting ready for your Technical File submission.

Conclusion

Securing modern medical technologies needs constant effort. By performing extensive EU MDR penetration testing, you will be able to detect and mitigate any potential security vulnerabilities in SaMD or Class II/III devices before any problems occur for patients. Being compliant with the MDCG 2019-16 document in your security validation process is key to your success on the European market.

A complete approach should cover the device’s entire attack surface, from software and APIs to wireless interfaces and firmware. Regular testing, remediation, and retesting also help manufacturers maintain security as the device evolves. 

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Frequently Asked Questions

1. Does EU MDR require penetration testing?

The EU MDR cybersecurity guidance document requires independent penetration testing for vulnerability discovery and verification on a device’s attack surface. Testing offers technical proof of the effectiveness of security measures put in place.

2. When should medical devices undergo penetration testing?

The first stage of testing should be done at the time of final verification and validation once the system architecture is complete, before making any submissions. The second stage of testing will be after major software changes, serious disclosure of CVEs, or annually for Post-Market Surveillance.

3. What should be included in an EU MDR penetration test?

Penetration testing needs to be performed on all aspects of the attack surface for the device. It includes web and mobile application programming interfaces (APIs) and cloud-based back-end systems. Wireless communication protocols such as BLE and Wi-Fi, embedded software and hardware, and physical interfaces like JTAG/UART are also included.

4. Does EU MDR penetration testing apply to all medical devices?

The testing approach depends on the device’s software, connectivity, risk, and attack surface. It is important for connected SaMD and Class II/III devices with APIs, wireless interfaces, firmware, or physical access points. 

5. What documentation should manufacturers maintain after penetration testing?

Manufacturers need to maintain a technical test report with CVSS vulnerability scores against the ISO 14971 risk matrix. They should also maintain a detailed log of actions to mitigate the issue and an Attestation of Retesting report. This document should be included in the Technical File and Quality Management System (QMS).

6. Can penetration testing help with CE marking? 

Yes, penetration testing offers proof of risk identification and validation of cybersecurity controls. That could be used as part of the EU MDR technical documentation. It ensures that the security risks identified have been dealt with.