Penetration Testing for Medical Devices: A 2026 Explainer

A plain-language guide to medical device penetration testing - what it is, what the FDA actually requires, how it differs by device archetype, and what a submission-ready deliverable looks like. Aligned to the February 2026 final premarket cybersecurity guidance and Section 524B of the FD&C Act.

Last updated: June 2026.

1. What Medical Device Penetration Testing Is (and Is Not)

A medical device penetration test is a time-boxed, exploit-driven evaluation of a real device by independent testers. The tester's job is to behave like a motivated attacker: chain weaknesses, bypass controls, and demonstrate impact - not just list missing patches.

It is not:

• A vulnerability scan (Nessus, OpenVAS) - automated, signature-based, no exploitation.
• A code review or SAST run - source-level, no runtime proof.
• A threat model - paper exercise that defines what could go wrong; the pen test proves what actually does.
• A red team - broader, goal-oriented adversary simulation, often spanning people, process, and physical access.

A pen test sits between the threat model and the red team: narrower than a red team, more concrete than a threat model, and reproducible enough to land in an eSTAR submission.

2. Why the FDA Requires It

Under Section 524B(b)(2) the FDA requires manufacturers of "cyber devices" to provide a reasonable assurance of cybersecurity, including evidence of testing. The February 2026 final guidance operationalizes this in Section V.B.4 - Penetration Testing, which expects:

1. Independent testers (organizationally separate from the development team).
2. Testing against the final or near-final device build.
3. Coverage of every external interface in the security architecture.
4. A report that the FDA reviewer can map back to your threat model and risk file.

Pen testing also appears - implicitly - in the labeling, vulnerability-management, and postmarket sections. If your submission says you'll handle a class of vulnerability, the pen test is where you prove the control works.

3. The Four FDA-Expected Test Categories

The 2026 guidance and AAMI TIR57 / ANSI/AAMI SW96:2023 expect coverage across four overlapping testing modes. A submission that only ticks one box is the most common reason a deficiency letter cites "insufficient testing".

3.1 Vulnerability Chaining

Combining multiple low- or medium-severity findings into a high-impact attack path - e.g. an unauthenticated info-leak plus a weak update signature plus a debug shell. Chaining is where most real exploits live, and it's the category most often skipped by scan-only "pen tests".

3.2 Boundary Analysis

Probing every trust boundary identified in the threat model: USB, serial, BLE, Wi-Fi, cellular, cloud API, mobile companion, service tools, and clinician portals. The deliverable should show that each boundary was exercised, not just the obvious ones.

3.3 Closed-Box (Black-Box) Testing

Testing from the attacker's starting position with no privileged knowledge - reverse engineering firmware, sniffing wireless protocols, fuzzing exposed services. Closed-box testing is how the FDA validates that your security relies on real controls, not on obscurity.

3.4 Manual Exploit Verification

Every finding the team reports must include a working proof-of-concept or a documented reason it could not be exploited (with the conditions that would change that). Scanner output alone is not sufficient evidence under the 2026 guidance.

4. Scope by Device Archetype

The same four test categories apply to every device, but the surface area and tooling differ wildly. Use this table to size an engagement before you scope it.

A credible scoping conversation names the archetype, lists the boundaries from the threat model, and assigns hours to each.

5. The Test Environment Problem

The 2026 guidance expects testing against a production-equivalent configuration. In practice this means:

• The exact hardware revision that will ship (not an early prototype with extra debug headers).
• The release-candidate firmware/software build, signed with production keys where possible.
• Surrogate networks, surrogate patient data, and - for hospital-connected devices - a hospital-network simulator (EHR, PACS, DHCP, NTP).
• Documented deviations from production, with a justification for why each deviation doesn't change the security posture.

If the FDA reviewer can't tell from the report what was tested, the test doesn't count. Include build hashes, hardware serials, and network diagrams.

6. Methodologies the FDA Recognizes

Cite the methodology you actually followed. The 2026 guidance and AAMI TIR57 / ANSI/AAMI SW96:2023 explicitly reference:

• OWASP MASVS / MSTG - mobile companion apps.
• OWASP ASVS - web/cloud backends and clinician portals.
• OWASP IoT Top 10 - embedded device weakness classes.
• ISA/IEC 62443-4-2 - component-level cybersecurity requirements.
• NIST SP 800-115 - overall testing process and reporting structure.
• AAMI TIR57 / ANSI/AAMI SW96:2023 - security risk management linkage between threats, tests, and risk file.

A report that names its methodology, version, and the specific controls tested is far harder for a reviewer to push back on.

7. What a Credible Pen-Test Deliverable Contains

The minimum the FDA expects (and the minimum we ship on every engagement):

1. Executive summary - one page, risk-rated, non-technical.
2. Scope statement - device, build, environment, dates, in/out of scope.
3. Methodology - which standards were followed, which tools used.
4. Boundary coverage matrix - every threat-model boundary mapped to the tests run against it.
5. Findings - each with CVSS v3.1, EPSS, exploitability narrative, screenshots/PoCs, remediation guidance, and a CWE.
6. Chained attack paths - at least one end-to-end narrative per device.
7. Retest results - findings that were fixed and re-verified.
8. Residual risk statement - aligned to your ISO 14971 risk file.
9. Tester attestation - independence, qualifications, hours.

If your current vendor's report is a Nessus export with a cover page, you do not have a submission-ready deliverable. See our companion piece, 12 Critical Findings from Medical Device Penetration Tests, for what the body of a real report looks like.

8. Pen Test vs Red Team vs Tabletop vs Threat Model

Most manufacturers need a threat model and a pen test for premarket; red teams and tabletops belong to the postmarket cybersecurity program.

One more distinction matters for the submission: a penetration test is validation of the built device, while security requirements testing is verification against your own design inputs, complete with boundary analysis and the rationale behind those boundary assumptions. The FDA expects both, filed separately. See security requirements testing vs penetration testing.

9. Cost and Timeline Ranges

Transparent ranges so you can budget. Actual quotes depend on archetype and number of interfaces:

Quotes below these ranges almost always omit one of the four test categories. Quotes above usually include premarket consulting, re-test, and FDA Q-response support.

10. How Blue Goat Cyber Approaches Medical Device Penetration Testing

We run pen tests specifically for FDA-regulated devices - the scope, evidence format, and threat coverage reviewers actually want to see. Here is the model behind every engagement.

• Threat-model-driven scope. We ingest your STRIDE model and design documentation first, so the test targets interfaces and data flows tied to declared risks - not a generic OWASP checklist.
• Full device attack surface. Firmware, hardware interfaces (JTAG/UART/USB), radios (BLE/Wi-Fi/cellular), cloud APIs, mobile companion apps, and clinician web portals - tested as one connected system.
• Independent testers. Our pen-test team does not also engineer your device. FDA reviewers increasingly expect this separation, and we run it as a default.
• Reviewer-ready deliverables. Every finding includes CVSS + FDA patient-safety severity, exploit narrative, reproduction steps, and remediation guidance mapped to AAMI TIR57 / ANSI/AAMI SW96:2023 hazards.
• Retest included. Fixing findings without a documented retest is a common deficiency trigger. Retest is part of the engagement, not an add-on.
• Timeline aligned to submission. We plan pen testing after design freeze with enough runway to remediate and retest before eSTAR lock.

Our Medical Device Penetration Testing engagement is the entry point.

11. Where Automation Helps, and Where It Doesn't

Automated tooling does a defined job well. Port and service discovery, protocol fuzzing, static analysis, SBOM generation, and triage of known CVEs against the component inventory are all faster and more consistent when a tool runs them, and every credible test plan uses them.

What tooling cannot do is reason about purpose. A scanner does not know that an infusion rate field should never accept that value, that a service technician role should not be able to reach patient data through a legitimate maintenance workflow, or that three individually low findings chain into a path that ends in patient harm. Business logic flaws, authorization bypasses, clinical workflow abuse, and multi-step exploit chains are found by people, not by signatures.

That is why the majority of a credible medical device engagement is manual penetration testing, with tool output treated as an input rather than as the report. It is also why reviewers react badly to a test report that is visibly a scan export: it demonstrates coverage of the known and silence on everything else. If you are weighing automated vs manual security testing, plan for tool-assisted breadth and manual depth, and say in the test plan which findings came from which.

Frequently Asked Questions

Does the FDA actually require a pen test?

Is your testing automated or manual?

Can our internal security team do it?

When in the development cycle should we test?

Does a pen test cover SBOM / [vulnerability management](/services/fda-compliant-sbom-services-for-medtech "FDA-compliant SBOM services")?

Do we need a new pen test for every software update?

How does this differ for Class III / PMA devices?

13. Where to Go Next

• Service overview: Medical Device Penetration Testing
• Requirements deep-dive: Medical Device Pen Test Requirements
• Field findings: 12 Critical Findings from Medical Device Penetration Tests
• Premarket roadmap: FDA Premarket Cybersecurity Submission Checklist
• Standards context: The MedTech Cybersecurity Standards Decoder
• Verification side: FDA Security Requirements Testing - the design-controls evidence a pen test does not replace.
• FDA Penetration Testing Scope for 510(k) - how to bound scope so the report satisfies review.

Ready to scope a pen test against the February 2026 guidance? Contact Blue Goat Cyber for a fixed-scope, fixed-price proposal.

References

Primary sources cited or relied on in this guide:

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 2026 final), U.S. FDA
• ANSI/AAMI SW96:2023, Standard for Medical Device Security, AAMI/ANSI
• IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness, and security, IEC/ISO
• OWASP Application Security Verification Standard (ASVS), OWASP
• Section 524B of the FD&C Act (Consolidated Appropriations Act, 2023, §3305), U.S. Congress