---
title: Cybersecurity Testing: Pentesting and Vulnerability Assessment
description: How penetration testing and vulnerability assessment fit into MDR cybersecurity evidence under Annex I §17.4 and EN IEC 81001-5-1:2022.
authors: Tibor Zechmeister, Felix Lenhard
category: IVDR & In Vitro Diagnostics
primary_keyword: cybersecurity testing penetration vulnerability medical device
canonical_url: https://zechmeister-solutions.com/en/blog/cybersecurity-testing-penetration-vulnerability
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Cybersecurity Testing: Pentesting and Vulnerability Assessment

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Penetration testing and vulnerability assessment are the external evidence layer of medical device cybersecurity. They do not replace secure development, but they prove it worked. Under MDR Annex I §17.4 and EN IEC 81001-5-1:2022, a well-scoped pentest is one of the most convincing pieces of evidence a startup can offer a notified body, especially when the internal lifecycle still has gaps.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Pentesting is external evidence that a device resists attack. Vulnerability assessment is the broader, more routine practice of finding and tracking weaknesses across the lifecycle.
- EN IEC 81001-5-1:2022 places both activities inside the security lifecycle. MDCG 2019-16 Rev.1 expects manufacturers to use them as part of the cybersecurity evidence package.
- Pentesting rarely wastes money. It is especially valuable when internal process has gaps that the manufacturer wants to compensate for before certification.
- Scope, timing, and provider selection determine whether a pentest produces useful evidence or a box-ticking PDF.
- Good pentests complement responsible development. Bad pentests are used as a substitute for it. Auditors can tell the difference.
- The pentest report becomes part of the technical file and feeds the PMS cybersecurity activities over the lifetime of the device.

## Why testing matters even when development was responsible

Tibor's Round 2 observation is the right starting point. In his experience, even startups that missed EN IEC 81001-5-1 during development can produce a credible pentest result to give the notified body external evidence that development was done responsibly. Pentesting is rarely wasted money. It is external proof where internal process was weak.

That reframes the topic. Pentesting is not a ritual at the end of a perfect process. It is a tool manufacturers use strategically, and it works best when used honestly.

There are two cases where testing produces value. In the first, development was rigorous, EN IEC 81001-5-1:2022 was followed from day one, and the pentest confirms the threat model was right and the controls hold. In the second, development skipped corners and the pentest is being used to rescue the cybersecurity evidence package before the audit. Both can produce a clean report. Only one produces a device that stays safe over time.

Felix's Subtract to Ship view is pragmatic. Startups rarely have the luxury of a flawless development process. What matters is whether the team is honest about where it stands and whether the pentest result becomes a starting point for remediation or the end of the story.

## What MDR actually says about cybersecurity testing

MDR Annex I §17.2 requires that software is developed according to the principles of risk management, including information security, verification, and validation. Verification and validation of security properties is where testing lives. MDR Annex I §17.4 requires that manufacturers define the minimum IT security measures necessary to run the software as intended, and the evidence that those measures actually work comes from testing.

The MDR does not name pentesting by name, just as it does not name specific cryptographic algorithms. It demands state of the art. The state of the art for security testing is captured in EN IEC 81001-5-1:2022, which includes security testing activities across the lifecycle. MDCG 2019-16 Rev.1 interprets these obligations for MDR and is clear that penetration testing, vulnerability assessment, and the ongoing monitoring of known vulnerabilities are part of the cybersecurity evidence base notified bodies expect to see.

In practice, "state of the art security testing" for a connected medical device today includes at least vulnerability scanning of the SBOM-derived component list, static analysis of the codebase, dynamic analysis of running systems, and a penetration test against the full device system from the attacker's perspective.

## Pentesting versus vulnerability assessment: the useful distinction

These two terms get confused often enough that Tibor flags it in most audits. They are not the same activity.

**Vulnerability assessment** is the broad, routine, mostly automated practice of identifying known weaknesses. It runs continuously. The SBOM, generated from the EN 62304:2006+A1:2015 configuration item list, feeds a vulnerability database. Every new CVE against a listed component produces an alert. Static analysis tools flag risky code patterns. The output is a stream of findings that the manufacturer triages, risks, and fixes.

**Penetration testing** is a focused, mostly manual, point-in-time exercise by skilled testers who actively try to compromise the device. They chain weaknesses the way a real attacker would and try to reach goals that matter clinically: change a clinical output, extract patient data, disable a safety control, compromise the update channel. The output is a report with specific findings ranked by exploitability and impact.

Both activities are necessary. Vulnerability assessment catches the long tail of known issues. Penetration testing catches the issues that only appear when creativity is applied to the system as a whole. A manufacturer who does only one has half the evidence.

## Scope: what a good pentest looks at

The single most important decision when commissioning a pentest is the scope. A too-narrow scope produces a report that does not reassure the notified body. A too-broad scope wastes money and dilutes the findings. For a typical connected medical device, the scope worth paying for covers six areas.

The external attack surface, meaning every network interface the device exposes to other systems, including cloud APIs, mobile app traffic, over-the-air update channels, and any wireless protocols.

The device itself, including physical interfaces, debug ports, and the firmware loaded on it. Hardware-level testing matters more for implanted or bedside devices than for pure SaMD, but it should be considered.

The mobile app, if one exists, including local data storage, inter-process communication, and the client half of the authentication flow.

The cloud backend, including authentication and authorisation logic, data access paths, and the identity boundary between the device, the app, and the backend.

The software supply chain, meaning the build infrastructure, the signing keys, and the release pipeline. This is often overlooked and increasingly targeted in real attacks.

The update mechanism specifically. Tibor calls this out in most reviews. The update path concentrates risk, so it deserves a disproportionate share of the pentest budget.

A pentest that covers four or five of these areas well is better than one that scratches all six superficially. The scope decision should be made jointly by the manufacturer, the tester, and ideally with input from someone who has seen a notified body audit recently.

## Timing: when to test

Pentesting early in development is wasted money: the system is not stable enough. Pentesting only at the final hour is dangerous: if something serious turns up, there is no time to fix it without delaying certification.

The useful window is after feature-complete integration, in a production-like configuration, with enough time before submission to remediate significant findings. For most startups that is four to eight weeks before the technical documentation is locked.

A second useful window is after major post-market releases. If an update changes authentication, the update mechanism, or the data boundaries, a follow-up pentest on the affected surfaces produces evidence that the change did not introduce new weaknesses. This sits inside the PMS cybersecurity activities under MDR Articles 83 to 86. For high-risk devices, annual full-scope rounds are a reasonable cadence. For lower-risk devices, a risk-based schedule documented in the PMS plan works.

## Provider selection: who to hire

Not every security firm understands medical devices. Tibor has seen pentest reports clearly written by a team that did not know what a medical device was, citing generic web application findings against a device with no web surface. The notified body rejected the report as evidence.

Three questions separate useful providers from expensive ones. Do they have experience with medical devices or safety-critical systems specifically, backed by references. Can they test the full system (hardware, firmware, mobile, backend, update channel) or only one layer. Will they produce a report a notified body can read: findings linked to threats, severities aligned with the risk framework, remediation guidance connected to engineering reality.

Felix's coaching note: startups sometimes hire a general-purpose firm at junior-engineer rates to save money. The savings are real for thirty days. The cost shows up at the audit when the report does not survive scrutiny.

## A worked example: the compensating pentest

Take Tibor's scenario. A startup has built a connected Class IIa device. Development was earnest but not perfect. EN IEC 81001-5-1:2022 was discovered halfway through the project. The threat model exists but is thin. The manufacturer is three months from submission and the cybersecurity evidence file looks weak.

The honest move is a scoped pentest aimed at the highest-risk surfaces: the backend authentication, the update channel, and the mobile app's local data handling. The tester is briefed with the threat model and the architecture. They spend three weeks in depth. They find a handful of real issues, rank them, and deliver a report.

The manufacturer fixes the critical and high-severity findings, re-tests, and documents the remediation. The lower-severity findings go into the risk file with accepted-risk justifications linked to the EN ISO 14971:2019+A11:2021 framework. The pentest report becomes part of the technical documentation as external evidence that the device resists the threats in the model. The notified body reads the report, sees the remediation loop, and accepts the evidence.

Alternate path: skip the pentest, submit as is, and hope. The notified body finds the gaps, asks for external evidence of resistance, and the startup commissions the pentest under deadline pressure. The total cost is higher. The pentest was never optional, only a question of when to do it.

## The Subtract to Ship playbook

Startups who want pentest results that hold up at audit follow a small checklist. Felix and Tibor have seen this work across several engagements.

Budget for one full-scope pentest before submission and one scoped follow-up after major post-market changes. Put it in the regulatory plan and the financial model from the start.

Scope the test around the threat model, not the feature list. If the threat model is thin, fix it first, even roughly, so the tester has something to aim at. A pentest without a threat model is a pentest that wanders.

Run vulnerability assessment continuously from day one. SBOM-driven CVE monitoring, static analysis in CI, and basic configuration scanning should be in place months before the pentest. The pentest then focuses on creative attacks, not things a scanner could have found.

Hire specialists. Prefer a firm with medical device references over a generalist at half the price. The report has to survive the notified body, not just your own team.

Remediate critical findings before submission. Document accepted risks against EN ISO 14971:2019+A11:2021 for lower-severity findings. The file should show a loop: test, find, fix, re-test, document.

Make the pentest part of the PMS cycle. Schedule the next round in the PMS plan. Link findings to the risk file and the change control system so post-market issues feed back into device design rather than sitting in a report.

Never use a pentest as decoration. Auditors read reports. They notice when findings are hand-waved, when remediations are promises without evidence, and when the scope was clearly chosen to avoid the hard parts. An honest report with real findings and real fixes is more credible than a clean one with suspicious scope.

## Reality Check

- Do you have a documented threat model that a pentest could actually be scoped against?
- Is vulnerability assessment running continuously against your SBOM, or only occasionally?
- Have you scoped your next pentest to cover the update mechanism specifically?
- Can you name the specialist provider you would hire, or are you still planning to pick cheap?
- If the pentest found a critical issue four weeks before submission, is there room in the schedule to fix and re-test?
- Does your technical file show remediation loops for past findings, not just the original reports?
- Is the next pentest round written into the PMS plan?

## Frequently Asked Questions

**Do we legally have to pentest under MDR?**
MDR does not use the word "penetration testing." It requires state of the art security, and pentesting is part of the state of the art captured in EN IEC 81001-5-1:2022 and expected by MDCG 2019-16 Rev.1. In practice, notified bodies expect pentest evidence for any connected device with a non-trivial attack surface.

**How much does a pentest cost?**
Specialist medical device pentests typically run from low five figures for a scoped engagement to mid five figures or more for a comprehensive full-system test. The cost of skipping one and failing the audit is almost always higher.

**Can our internal team do the pentest?**
Internal testing is useful but cannot fully substitute for external testing. External evidence means the testers are independent of the development team, which is what makes the finding credible. A small internal red team plus an external engagement is a reasonable combination.

**What about bug bounty programs?**
Bug bounty programs are valuable for ongoing vulnerability discovery but do not replace a structured pentest. They complement each other: the pentest covers creative attacks at a point in time, the bounty covers the long tail of issues over the device lifetime.

**Do pentest findings need to be reported to the notified body?**
Critical and high-severity findings that affect the safety posture typically need to be addressed and documented in the technical file. The original report can be included as evidence. Whether a specific finding rises to vigilance reporting under MDR Articles 87 to 92 depends on the impact, not on the fact that a pentest found it.

**Is a pentest report from a previous version still valid after updates?**
Only for the parts of the system that did not change. Significant changes to the authentication, the update channel, or the data boundaries usually warrant a fresh round on the affected surfaces.

## Related reading
- [Cybersecurity Risk Management under MDR](/blog/cybersecurity-risk-management-mdr).  how pentest findings integrate with the main risk file.
- [SBOM for Medical Devices under MDR](/blog/sbom-medical-devices-mdr).  the foundation of vulnerability assessment that pentesting complements.
- [Secure Software Update Mechanisms](/blog/secure-software-update-mechanisms).  the attack surface that deserves the largest share of pentest scope.
- [Data Encryption for Medical Devices](/blog/data-encryption-mdr-gdpr).  the controls whose effectiveness the pentest will try to break.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2 and §17.4; Articles 83 to 86 on PMS.
2. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for Medical Devices, July 2020.
3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, activities in the product lifecycle.
4. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.
5. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.

---

*This post is part of the [IVDR & In Vitro Diagnostics](https://zechmeister-solutions.com/en/blog/category/ivdr) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*