Scoping a Medical Device Penetration Test: A Practical Guide

Part of our Medical device penetration testing series. For the full overview, start with FDA Penetration Testing Requirements.

Reviewed September 17, 2026

Most weak penetration tests are weak because of decisions made before anyone touched the device. The scope was set from a budget rather than from the architecture, the hardware arrived without a way to access it, or the testers were given a production unit locked down in ways that hid the interfaces they were supposed to examine.

Scoping well is not complicated, but it requires knowing what your device actually exposes and being willing to include the parts that are inconvenient to test. This is how to do it so the resulting report supports your submission instead of raising questions about it.

Why Scope Is the Decision That Determines Report Quality

The February 3, 2026 premarket cybersecurity guidance expects security testing to reflect the device's attack surface. That is a scoping statement, not a testing statement. A reviewer reading your report is comparing it against your architecture views and your threat model, and the comparison is quick: if the views show a Bluetooth radio and a debug header, and the report covers a web dashboard, the mismatch is obvious on the first pass.

The cost of getting this wrong is measured in review cycles. A deficiency question about testing scope arrives months after the test, when the device has moved on, the lab availability has changed, and the schedule has no slack. Scoping correctly the first time is cheaper than any of the alternatives.

There is also an engineering reason. A test scoped to the easy interfaces tells you your easy interfaces are fine. It does not tell you whether your firmware can be extracted through the debug header, which is what an attacker with the device in hand would try first.

Start From the Architecture Views

The four security architecture views the FDA describes are the natural starting point, because they already enumerate what your device connects to and what can affect multiple patients. Walk each view and list every arrow.

The excuses in the third column are worth reading carefully because each one is an assumption. A sealed enclosure is a delay, not a barrier. A hospital VLAN is someone else's control that you do not administer. A factory test mode that ships enabled is a live interface regardless of its intended purpose.

[KEY REQUIREMENT] If an interface is out of scope, record why in the test plan and carry that rationale into the submission. An interface that is simply absent from the report reads as an oversight; one that is excluded with a stated reason reads as a decision.

What Testers Need From You

The depth of a test is bounded by the access provided. Manufacturers frequently under-supply, then receive a report that is shallower than they wanted.

Providing debug credentials sometimes feels like weakening the test. It does the opposite. A tester who spends three days bypassing a lock to reach a subsystem has spent three days proving the lock is slow, not evaluating the subsystem. Give the access, then test separately whether the lock holds.

Black Box, Grey Box, or White Box

The access model should follow from what you are trying to learn.

Grey box is the usual right answer for a submission. Pure black box testing burns time on reconnaissance you could have supplied and produces less coverage for the same money, while white box testing finds the most issues but is harder to present as a simulation of a real attacker. Many programs do both: white box review during development, grey box testing to produce the submission evidence.

Timing the Test

See also: Medical Device Robustnesss & Fuzz Testing, Medical Device Penetration Testing Post Exploitation, and 25 Use Cases for White-Box Penetration Testing.

Test when the design is stable enough that findings apply to the device you will ship, but early enough that fixing a finding does not mean re-opening a frozen design.

In practice that means after design freeze and before verification and validation close, with enough calendar time for remediation and a retest of anything significant. Teams that test in the final weeks before filing usually end up submitting with findings open, which is a worse position than filing a little later with them closed.

Hardware findings drive this more than software ones. A software fix is a firmware build; a finding that says the debug interface is accessible on the production board may require a board change, and board changes have lead times that no amount of urgency shortens.

Scoping the Ecosystem, Not Just the Device

For most modern devices, the device alone is an incomplete scope. The therapy or diagnostic chain includes a phone app, a gateway or hub, cloud services, and sometimes a clinician-facing portal. An attacker will target whichever link is weakest, and that link is frequently not the embedded device where the security effort was concentrated.

A defensible scope covers the full chain, with the depth on each component proportional to its role. That does not mean equal effort everywhere. It means the cloud API that can push a configuration change to every device in the field gets attention proportional to that capability, because it is the clearest example of the multi-patient harm the architecture views are meant to surface.

How Blue Goat Cyber Approaches This

We scope from your architecture views and your threat model, then tell you plainly where the scope is thinner than the attack surface and what that will look like to a reviewer. Our engagements cover radio, hardware, firmware, application, and cloud layers, and the report is written so each finding maps back to the threat it exercises and the harm it could cause.

Our medical device penetration testing is built for submission evidence rather than for a generic scan report, and our threat modeling work produces the architecture views the scope should be derived from in the first place.

Frequently Asked Questions

What should be included in a medical device penetration test scope?

Every interface that crosses a trust boundary in your security architecture views: wireless radios, physical debug and service ports, network services, the mobile or web application, cloud APIs, and the firmware update path. If your views show an interface and your test report does not mention it, a reviewer will notice the gap and ask about it.

How long does a medical device penetration test take?

It depends on the interface count and the depth required, but a connected device with a radio, an app, and cloud services typically takes several weeks of testing plus reporting time. Hardware-focused work can take longer because physical access, chip removal, and firmware extraction are slower than network testing and sometimes destroy the unit.

Should we give the testers source code?

For development-phase testing, yes, because source access finds more issues per hour than black-box work. For the submission evidence itself, a grey box model with documentation and credentials is usually the best balance. Many manufacturers do both, using white box review during design and grey box testing to produce the report they file.

When in the development cycle should testing happen?

After design freeze, so the findings apply to what you will ship, and before verification and validation close, so there is room to remediate and retest. Testing in the final weeks before filing tends to produce a submission with findings still open, which is a worse outcome than a slightly later filing with them resolved.

Does the FDA require penetration testing?

The February 3, 2026 premarket cybersecurity guidance identifies security testing, including penetration testing, as part of the expected submission content for cyber devices. What matters as much as performing the test is that its scope matches the attack surface you documented, and that the report is specific enough for a reviewer to connect findings to your threat model.

What if we cannot test an interface for safety reasons?

Document the constraint and the alternative you used, such as testing on a simulator, a non-clinical test article, or a bench setup that reproduces the interface. A stated constraint with a reasonable substitute is defensible. An interface that simply does not appear in the report, with no explanation, is the version that generates questions.

Scope It Once, Properly

Bring us your architecture views and we will tell you what a defensible test scope looks like for your device, including the interfaces that are inconvenient to include. Book a strategy session.

---

Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.