Medical Device Penetration Testing and FDA Scope: Why the Threat Model Comes First

A medical device penetration test can come back completely clean and still trigger an FDA deficiency letter. The report is not wrong. The scope was.

Premarket cybersecurity review is not a pass or fail grade on a vulnerability count. Reviewers are checking whether your security testing exercised the same attack surface your threat model claims to have analyzed. When those two documents do not line up, the submission stalls, no matter how good the testing was.

This article is about that gap. If you want the broader submission walkthrough, start with our 2026 FDA 510(k) medical device penetration testing guide and come back here for the scoping detail.

What a passing pentest actually proves to a reviewer

A penetration test proves one narrow thing: within the boundary you defined, a tester with a defined level of access could or could not achieve a defined impact. That is it. It says nothing about the parts of the system you left outside the boundary.

FDA reviewers read the report alongside your threat model, your architecture views, and your risk assessment. The question they are answering is not "did the device pass" but "was the testing sufficient to support the security risk conclusions this submission makes."

So a report with zero critical findings can read as weak evidence if the boundary excluded the cloud backend, the mobile companion app, the update mechanism, or the service technician interface.

The scope gap that produces deficiency letters

The recurring pattern looks like this. The threat model is written at the system level. It describes an attacker on the hospital network, an attacker with physical access to the device, a compromised update server, and a malicious app on a paired phone. Good, thorough work.

Then the penetration test statement of work is written at the device level. It covers the embedded firmware and the local wireless interface. Also good work, but narrower.

Nothing in the package explains why the other threats were not tested. Reviewers are left to assume they were not analyzed at all. That assumption is what generates the deficiency.

The fix is rarely more testing. It is usually explicit traceability plus a defensible rationale for anything intentionally excluded.

Five scope boundaries you need to define on paper

1. The device itself

Firmware, bootloader and secure boot chain, debug and JTAG interfaces, local storage and key material, sensor and actuator inputs, and any physical port that survives into the shipped product.

2. The connectivity layer

Bluetooth Low Energy, Wi-Fi, cellular, NFC, or proprietary radio. Pairing and bonding flows are where a lot of real findings live, and they are frequently scoped out because they feel like a protocol concern rather than a device concern.

3. The backend and API surface

The cloud services the device talks to are part of the system a reviewer is evaluating. Authentication, authorization between tenants, device identity provisioning, and telemetry ingestion all belong in scope. Our API penetration testing work on connected device backends usually surfaces more exploitable issues than the embedded side.

4. Companion and clinician applications

The mobile app, the web portal, and the clinician dashboard are how most people actually touch the device. If a clinician portal allows one hospital to read another hospital's patient data, that is a device system vulnerability regardless of where the code runs.

5. Update and supply chain paths

Signed update verification, rollback protection, and the integrity of the distribution channel. This ties directly to your SBOM and postmarket patching commitments, so a gap here is visible in two places at once.

Threat modeling is the scope document

Teams often treat the threat model as a regulatory artifact and the pentest as an engineering activity, run by different people, on different timelines, in different tools. That separation is the root cause of the scope gap.

Run it the other way around. Build the threat model first, then derive the test plan from it directly, so that each identified threat has one of three outcomes:

• Tested. There is a test case, a result, and evidence.
• Mitigated by design. There is a control, and a rationale for why exploitation is not feasible.
• Accepted. There is a documented risk acceptance with clinical impact reasoning.

A threat with none of those three attached to it is an open question in your submission. Reviewers find those quickly.

Use a consistent method

STRIDE per data flow, or a structured attack tree per clinical harm, both work. What matters is that the method is stated, applied uniformly, and produces threats granular enough to write test cases against. "Attacker gains access to device" is not testable. "Attacker on the adjacent hospital VLAN reaches the unauthenticated diagnostic service on TCP 8080 and writes a therapy parameter" is testable.

Anchor every threat to patient harm

Medical device security risk is not measured in CVSS alone. A medium severity technical finding that changes an infusion rate outranks a high severity finding that leaks a device serial number. Map each threat to the clinical consequence, and let that drive test prioritization. This is also the language reviewers use, so it makes your rationale easier to accept.

AI and machine learning enabled devices

Software as a Medical Device with a model in the loop adds attack surface that traditional device scoping misses entirely:

• Input manipulation against the inference path, where crafted inputs push the model toward a clinically wrong output.
• Prompt injection and tool abuse in devices that use language models for triage, summarization, or clinician-facing guidance.
• Data poisoning exposure in any pipeline that retrains or fine tunes on field data.
• Model and weight extraction where the model itself is the regulated function.
• Guardrail bypass that lets the system produce output outside its cleared indication for use.

These belong in the threat model and in the test plan. If your device includes a model, see how we approach AI and LLM penetration testing for the specific test cases involved.

Writing a scope statement that survives review

A defensible scope statement answers five questions in plain language:

1. What is in scope, by component and interface. Name versions and build identifiers.
2. What is out of scope, and why. Silence reads as an oversight. A stated rationale reads as a decision.
3. What access the tester started with. Black box, credentialed, physical possession, debug enabled, or production equivalent.
4. What environment was tested. Bench unit, production representative hardware, staging backend, or production. Differences from the shipped configuration need to be called out.
5. How results map back to the threat model. A simple traceability table is enough, and it is the single highest value page in the package.

If a reviewer can read those five items and reconstruct what you did without calling you, the scope is doing its job.

How hybrid testing closes the gap faster

System level scope means more surface: firmware, radios, APIs, web portals, mobile apps, and update infrastructure. Covering all of it with a purely manual team is slow and expensive, which is exactly why so many teams quietly narrow scope instead.

StealthNet runs medical device engagements as a hybrid: AI agents enumerate and probe the full system surface continuously, and a senior US based tester validates, chains, and writes up what is actually exploitable. Breadth from the agents, judgment from the human, one report that maps to your threat model.

Practically, that means you can keep the wide scope reviewers expect without a proportional increase in budget or calendar time, and you can retest after remediation without paying for a whole new engagement.

Common scoping mistakes to avoid

• Testing a bench unit that does not match production. Debug interfaces disabled in shipping units but open on the bench unit invalidate the result in both directions.
• Excluding the backend because a different team owns it. Organizational boundaries are not regulatory boundaries.
• Running the test after the submission is drafted. Findings then become schedule risk rather than design input.
• Reporting only technical severity. Without clinical impact framing, reviewers cannot evaluate your risk conclusions.
• No retest evidence. "Fixed" without verification is an assertion, not evidence.
• No traceability table. This is the cheapest artifact to produce and the most frequently missing.

A practical sequence

1. Build or refresh the system level threat model, including cloud, mobile, and update paths.
2. Derive a test plan where every threat is tested, mitigated by design, or formally accepted.
3. Scope the penetration test to the full system, with written exclusions and rationale.
4. Execute, then map each finding to the threat it validates and the clinical harm it enables.
5. Remediate, retest, and include retest evidence in the package.
6. Carry the same model into postmarket monitoring so the artifact stays alive after clearance.

Done in that order, the penetration test stops being a checkbox at the end of the project and becomes the evidence layer under your entire cybersecurity submission.

If you are scoping a submission now, our FDA medical device penetration testing page covers how we structure these engagements, and the FDA cybersecurity checklist gives you the artifact list to work against. Teams handling PHI on the backend should also review our HIPAA penetration testing requirements, since the same infrastructure usually falls under both.