A CE compliance certificate may support market access, but it does not make weak security controls stronger. The underlying evidence still has to show that the device meets the applicable safety and cybersecurity requirements.
That evidence now matters beyond the regulatory file. RunSafe Security’s 2026 Medical Device Cybersecurity Index found that 56% of surveyed healthcare organizations had rejected a medical device because of cybersecurity concerns, compared with 46% in 2025.
For manufacturers, technical validation helps turn a security claim into something defensible. If access controls, communications security, update functions, or other protections are part of the design, testing should show that they continue to work when deliberately challenged.
A certificate may record conformity, but credible CE compliance testing provides the technical evidence needed to support the security conclusions behind it.
Defining “State-of-the-Art” CE Compliance Testing
For medical device cybersecurity, state of the art means using security measures and validation methods that reflect current technical knowledge and suit the device’s actual risk profile. MDR Annex I Section 17.2 requires software-based devices to address lifecycle processes, risk management, information security, verification, and validation in line with the state of the art.
It should not be treated as one certificate, pentest, tool, or checklist. Instead, the approach should fit the device’s architecture, intended use, interfaces, operating environment, and potential security impact.
The regulatory hierarchy is also important:
- EU MDR 2017/745: legally binding requirements.
- MDCG 2019 16 Rev.1: non-binding guidance for applying cybersecurity requirements.
- IEC 81001-5-1: a secure health software lifecycle standard, not MDR legislation.
- ISO 14971: Medical device risk management
- IEC 62304: Medical device software lifecycle
- Team NB positions: useful insight into notified body expectations, rather than law.
A functional test might confirm that an authorised clinician can change an infusion setting correctly. Security validation asks a different question: could an unauthorised person bypass authentication, replay a request, gain additional privileges, or manipulate that setting through another interface?
Modern CE compliance testing therefore considers hostile and abnormal interactions, including risks arising from connected systems and environments, especially where confidentiality, integrity, or availability failures could affect therapy, alarms, readings, diagnostics, or access to care.
Why Automated Security Scans Fail Regulatory Audits
An automated security scan can find weaknesses, but it cannot always explain what those weaknesses mean for the medical device. For CE compliance, that difference matters. A scanner report may identify an exposed service, outdated component, weak configuration, or known vulnerability. It may not show whether someone can actually exploit the issue or affect a clinical function.
Take an authorization flaw in a connected device API. The scanner flags the weakness. A manual tester goes further by checking whether a low-privilege user can reach a restricted function, bypass another control, and ultimately change a medical parameter. Now the finding has context. Reviewers can see how the vulnerability could affect device behaviour and patient safety.
Automated tools may also struggle with:
- Clinical workflow abuse
- Privilege boundaries
- Authentication bypasses
- Proprietary protocols
- Hardware interfaces
- Unusual device states
- Weaknesses that span cloud, mobile, API, and device components
MDCG 2019 16 Rev.1 includes vulnerability scanning alongside penetration testing, fuzz testing, security feature testing, and code analysis. That supports using several methods together.
Clear evidence should also show what was tested, the version, scope, findings, remediation, and remaining risk.
The Components of Commercially Viable VAPT
Medical device penetration testing should match the product’s actual architecture and attack surface. Depending on the device, testing may cover firmware, APIs, mobile apps, cloud services, wireless interfaces, connected workstations, update systems, and relevant third-party components. MDCG 2019 16 Rev.1 recognises several complementary testing methods, so cybersecurity assurance should not depend on one test alone.
1. Fuzz Testing
Fuzz testing checks how software behaves when it receives malformed, unexpected, random, oversized, or protocol-invalid input. Instead of confirming that a function works correctly, it looks for failures that appear when the software is pushed outside normal conditions.
It can uncover:
- Crashes
- Memory corruption
- Hangs
- Unhandled exceptions
- Denial of service
- Unexpected state changes
- Unsafe parsing behaviour
Fuzz testing is especially useful for components that process external or structured input. MDCG 2019 16 Rev.1 recognises it as one of several methods that can support cybersecurity verification and validation.
2. Binary and Firmware Analysis
Binary analysis examines the compiled software that actually runs on the medical device. It is especially useful when source code is unavailable, such as with third-party components, or when you need to confirm whether the deployed build contains security weaknesses that are not obvious from design documentation.
Testing can look for:
- Hardcoded credentials and cryptographic keys
- Embedded secrets
- Vulnerable libraries
- Debug functions
- Unnecessary services
- Insecure storage
- Missing security protections
- Exposed configuration data
For embedded and IoT medical devices, testers may also extract firmware and inspect its file system, software packages, services, credentials, and configuration.
3. Protocol Manipulation and Communication Testing
Connected medical devices exchange data through interfaces such as Ethernet, Wi Fi, BLE, NFC, cellular networks, USB, serial connections, and proprietary protocols. Each connection creates another path that may need security testing.
Testers examine whether an attacker can intercept traffic, alter messages, replay valid commands, impersonate a trusted component, or connect without proper authentication. They may also test weak pairing logic, session handling, protocol downgrade conditions, and malformed messages.
For example, a legitimate command sent from a workstation could be captured and replayed later. Testing then determines whether the device accepts it again and whether the result changes a clinical setting or device state.
4. Deep API Penetration Testing
Medical device APIs can become safety-relevant when they control authentication, patient data, telemetry, diagnostics, configuration, or clinical commands. Testing should therefore look beyond whether an endpoint exists.
Key checks can include:
- Broken object-level authorization
- Broken function-level authorization
- Weak authentication
- Token or session abuse
- Injection
- Rate limit failures
- Privilege escalation
- Mass assignment
- Business logic abuse
- Replay attacks
OWASP identifies several of these authorization and authentication weaknesses among its major API security risks.
5. Penetration Testing Across the Complete Connected Ecosystem
System-level penetration testing looks at how an attacker could move between connected parts of the medical device ecosystem. Instead of assessing the device, mobile app, APIs, cloud services, and workstations separately, testers examine how weaknesses in one area may expose another.
Black box, grey box, or white box testing may be used depending on how much system knowledge and access the tester receives. NIST describes these as different types of testing approaches rather than interchangeable labels.
For final pre-release assessment, testing should use a representative setup. The report should identify the firmware and software versions, access provided, interfaces covered, exclusions, assumptions, and relevant environment details so reviewers can see exactly what the assessment covered.
| Component | Relevant testing |
| Firmware | Binary analysis, secrets review, update testing, penetration testing |
| Web portal | Web application penetration testing, access control testing |
| API | API penetration testing, fuzzing, authorization testing |
| Mobile app | Mobile security testing, storage review, token analysis |
| Cloud infrastructure | Configuration review, IAM testing, service and API testing |
| BLE and Wi Fi | Wireless security and protocol testing |
| Third party packages | Software composition analysis, vulnerability review, SBOM verification |
| Update mechanism | Signature validation, authenticity checks, rollback testing, tampering tests |
How a Clean Security Testing Report Accelerates Your CE Certificate
A clean security testing report does not grant a CE certificate or guarantee approval. It can, however, reduce avoidable review questions by giving manufacturers clear evidence of what was tested, what was found, and how security issues were addressed. MDR Annex II requires verification and validation evidence within the technical documentation.
The report should clearly identify the tested software and firmware versions, scope, interfaces, methodology, findings, remediation, retest results, and remaining risk. Version control matters because results from an older build may not represent the release submitted for assessment.
For manufacturers using CE certification services, the vulnerability assessment and pentesting report should also connect with risk management and technical documentation instead of remaining a separate security document.
Risk to Test Traceability
| Cyber risk | Requirement | Control | Validation | Example evidence reference |
| Unauthorized therapy change | Restrict therapy changes | RBAC and authentication | Authorization test | SEC PT 024 |
| Malicious firmware | Allow trusted firmware only | Signed updates | Modified update test | SEC VV 031 |
| Data interception | Protect communications | TLS | Interception test | SEC PT 041 |
| Protocol disruption | Handle malformed traffic safely | Input validation | Fuzz test | SEC FUZZ 009 |
Traceability connects risk, requirement, control, test result, and residual risk decision. Findings that could affect patient safety should also feed back into medical device risk management rather than being judged only by a generic vulnerability score.
What an Audit Ready Pentesting Report Should Contain
An audit-ready penetration testing report should let a reviewer understand exactly what was assessed and reproduce the context of the test without searching through separate documents. MDR Annex II requires technical documentation to include verification and validation results used to demonstrate conformity.
The report should capture:
- Test identification: device name, software and firmware versions, build, test dates, and environment
- Scope: included interfaces, exclusions, assumptions, and access provided
- Methodology: attack surfaces, manual and automated techniques, testing method, and tester access level
- Finding evidence: affected component, reproducible attack path, prerequisites, technical impact, possible safety consequence, supporting evidence, severity, and remediation
- Closure evidence: remediation decision, fixed version, retest outcome, unresolved issues, rationale, and remaining risk
The supporting technical file should also retain relevant cybersecurity artefacts, such as threat models, security requirements, component inventories, vulnerability assessments, validation plans, test results, and remediation records.
Cybersecurity evidence also needs to remain current. New vulnerabilities, software changes, infrastructure changes, or new attack methods can alter the device’s risk profile after testing. Post-market information should feed back into technical documentation, risk management, and corrective action.
Qualysec’s Elite Compliance Testing Services
For CE mark preparation, your documentation explains which cybersecurity controls protect the medical device. Qualysec helps you verify whether those controls actually withstand realistic attacks. Its role is technical cybersecurity validation, not granting the CE mark or performing the Notified Body assessment.
- Define the attack surface: Qualysec reviews the device architecture, applications, APIs, cloud services, communication paths, interfaces, and relevant infrastructure to build a testing scope around the actual product.
- Prioritise critical paths: Testing focuses on weaknesses that could affect authentication, authorization, communications, firmware, connected services, or device functions.
- Test the ecosystem: Qualysec combines manual and automated testing across web, API, mobile, cloud, IoT, healthcare devices, and external networks. Manual assessment helps uncover logic flaws and attack paths that scanning alone may miss.
- Document and remediate: Findings include technical evidence and remediation guidance that manufacturers can use alongside their risk management and technical documentation.
- Retest fixes: Qualysec can verify corrected vulnerabilities and provide remediation support.
Conclusion
Cybersecurity testing gives medical device manufacturers a clearer view of how their controls behave when the product is deliberately challenged. Automated scanning can contribute useful findings, but broader CE compliance testing should reflect the device architecture, attack surface, and identified risks.
MDCG guidance supports using multiple verification and validation methods rather than relying on one technique alone. CE compliance guide explains how manufacturers can combine cybersecurity testing methods to support compliance.
Strong penetration testing evidence should identify the exact version tested, explain the scope and findings, record remediation and retesting, and show how remaining risks were handled. When these results are connected to the manufacturer’s risk management and technical documentation, they provide a much clearer record of the device’s cybersecurity validation.
If you are preparing cybersecurity evidence for EU MDR or IVDR conformity assessment, Qualysec can help you validate the security controls supporting your technical documentation. Request a penetration testing quote to plan the right assessment for your medical device.
FAQs
1. What type of testing is mandatory to receive a medical device CE compliance certificate?
No single cybersecurity test package is mandatory for every medical device. MDR Annex I 17.2 requires appropriate software verification and validation, including information security considerations. MDCG lists methods such as security feature testing, fuzzing, vulnerability scanning, and penetration testing. The right mix depends on architecture, risks, and conformity assessment expectations.
2. Can we perform our CE compliance testing entirely in-house?
Manufacturers can perform substantial security testing internally during development. Independent system-level testing can still add useful objective evidence, particularly for connected or higher-risk devices. Team NB recommends appropriate test depth and coverage, with skilled testers independent of the development team. Your Notified Body and QMS requirements should also guide the approach.
3. How long is a third-party medical device penetration testing report valid for?
MDR does not assign a fixed expiry period to penetration testing reports. A report remains useful while the tested configuration still represents the marketed device. Significant changes to software, firmware, components, architecture, remediation, or threat posture may warrant reassessment, as new vulnerabilities and attack techniques can alter the device’s security over time.
