How to Conduct Medical Device Penetration Testing

To conduct a medical device penetration test that FDA can review, scope the test from your threat model and architecture views, choose testers who are independent from the development team, run device-specific phases that cover firmware, every interface, and the update path, assess every finding in your security risk management process, and write a report with the five elements FDA's premarket cybersecurity guidance (February 2026) lists in Section V.C. Then repeat the test at intervals commensurate with risk, which the guidance illustrates as annually. This post walks through each step.

Where penetration testing sits in FDA's testing expectations

Section V.C of the February 3, 2026 final guidance says cybersecurity controls need "testing beyond standard software verification and validation activities." It then lists the testing types FDA recommends you consider including in a premarket submission:

• Security requirements testing, with evidence that each design input was implemented and evidence of boundary analysis
• Threat mitigation testing, which shows the risk controls in your global system, multi-patient harm, updatability and patchability, and security use case views work
• Vulnerability testing, which includes abuse and misuse cases, malformed inputs, fuzz testing, attack surface analysis, vulnerability chaining, closed box scanning for known vulnerabilities, software composition analysis of binaries, and static and dynamic code analysis
• Penetration testing

Penetration testing is one layer, and it sits last for a reason. It assumes the first three layers exist. A penetration test against a device with no threat model and no security requirements produces a list of findings with nothing to trace them to. Our book chapter on security testing approaches covers how the layers fit together, and the chapter on security testing documentation for eSTAR shows where each report lands in the submission.

The guidance describes the purpose plainly. Penetration testing "should identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product." The word that matters is exploiting. A vulnerability scan tells you a component version has a CVE. A penetration test tells you whether an attacker can reach it, chain it, and affect the device.

Step 1: Scope the test from the threat model

Start with the documents you already have, or should have. The threat model (Section V.A.1) and the security architecture views (Section V.B.2) define the attack surface. The SBOM (Section V.A.4) tells testers which components to target. The scope statement should list, for each item, whether it is in scope and what level of access testers get.

For a connected device, the scope usually includes:

• Network interfaces: Ethernet, Wi-Fi, and cellular, plus every listening service and protocol the device speaks
• Short-range radio: Bluetooth Low Energy pairing, bonding, and characteristic access; proprietary RF; NFC or magnetic inductive links on implant programmers
• Physical ports: USB, serial, JTAG and SWD debug headers, SD cards, and service connectors, because FDA considers a device that can connect to the internet through any of these to be a cyber device
• Firmware: extraction, storage of secrets, secure boot, and the integrity checks between boot stages
• The update path: from the update server to the device, end to end, including the signing and verification steps shown in your updatability and patchability view
• Companion software: mobile apps, clinician workstations, and cloud services, which the guidance treats as "related systems" under Section 524B(b)(2)
• Users and roles: service accounts, clinician and patient roles, and any default or recovery credentials

Write down what is out of scope and why. A hospital network penetration test is a different engagement. If you exclude the cloud backend because it is covered by a separate test, say so and reference that report.

Scope also sets duration, and FDA asks for the duration of testing in the report. A two-day test of a device with eight interfaces is a scan, not a penetration test. Budget time per interface and leave room for exploitation once the first foothold is found.

Step 2: Choose the access model

Black box, grey box, and white box describe how much the testers know going in.

• Black box: testers get the device and nothing else. This simulates an outside attacker. It spends budget on reconnaissance that your own documents could have skipped.
• Grey box: testers get the architecture views, the threat model, the SBOM, and user-level credentials. They do not get source code.
• White box: testers get everything, including source, build artifacts, and debug access.

For a premarket test, grey box or white box is the right default. The purpose is evidence that the controls in your threat model hold, and that evidence is stronger when testers aim at the controls directly. The guidance's own list of analyses, including static and dynamic code analysis and software composition analysis of binaries, assumes testers have access to code or binaries.

Step 3: Decide who runs the test

Section V.C asks you to state in the report "by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices." It adds that "in some cases, it may be necessary to use third parties to ensure an appropriate level of independence."

Independence is about incentive, not employment status. An internal security team that reports outside the product line and had no hand in the design can be independent. A firmware engineer testing their own code cannot. If you use an internal team, document the reporting line and the separation from the design work. If you use a third party, FDA asks for the original third-party report, not a summary written by the manufacturer.

Technical expertise is the other half of the element. Device testing needs skills that general IT penetration testers often lack: embedded firmware analysis, RF and BLE protocol work, hardware debug interfaces, and the ability to reason about patient harm when a finding affects essential performance. Our post on choosing a penetration testing vendor covers what to ask.

Step 4: Run the test in device-specific phases

Generic penetration test methodologies describe reconnaissance, scanning, exploitation, persistence, and reporting. That shape still works, but each phase looks different on a device.

Reconnaissance and attack surface analysis

Enumerate every interface and compare the result to the architecture views. Differences are findings in themselves: an undocumented listening port, a debug header left enabled, a BLE characteristic that is writable without authentication. Record the tools and versions used. The guidance's footnote on testing tools asks for tool name, version, and configuration.

Firmware analysis

Extract firmware from the device, from the update package, or both. Analyze it for the items FDA names directly: credentials that are "hardcoded," default, easily guessed, and easily compromised. Look for embedded private keys, API tokens, and certificates. Run software composition analysis on the binary and compare the result to the SBOM you plan to submit. Mismatches between the binary and the SBOM are a common finding and an easy one to fix before submission.

Check secure boot and the chain of trust. Can a modified image be flashed? Does the bootloader verify the application signature? Does the application verify its own configuration data?

Interface and protocol testing

Test each interface against abuse and misuse cases. Feed malformed and unexpected input to every parser, which is the fuzz testing the guidance lists under vulnerability testing. For BLE, test pairing modes, bonding, and whether characteristics enforce the access levels your threat model claims. For network services, test authentication, session handling, encryption in transit, and certificate validation. For physical ports, test what a person with brief physical access can do, because the guidance counts a service USB connection as internet connectivity.

Exploitation and vulnerability chaining

Take the findings from the first three phases and try to chain them into an impact on the device. The guidance names vulnerability chaining as an analysis to document. A readable debug log plus a weak session token plus a writable configuration file is a different finding from any one of them alone. Document each chain as a path from entry point to effect on safety or essential performance.

Update path and recovery

Test the updatability and patchability view end to end. Can the device be pointed at a rogue update server? Does it accept an unsigned or downgraded image? What happens when the update is interrupted at each stage? Appendix 1 of the guidance asks manufacturers to consider "how update process works in event of communication interruption or failure," so the test should answer that question with evidence. Then test recovery: can the device be restored to a known good state, and can a user tell that it has been?

Persistence and detection

On a device, persistence means whether an attacker's change survives a reboot, a factory reset, or an update. Detection means whether the device logged anything a hospital security team could use. Appendix 1 lists event detection and logging as a control category, so a test that finds no log entry for a successful attack has found a control gap.

Step 5: Assess every finding in your risk process

Section V.C says "vulnerabilities and anomalies identified during testing should be assessed for their security impacts as part of the security risk management process." It also draws the line between security and ordinary software defects. In non-security testing, a low-impact anomaly may be left alone. In security testing, "the exploitability of an anomaly may necessitate that it is mitigated because of the greater, and different type of, harm that it could facilitate."

For each finding, record:

• The exploitability and the severity of patient harm, scored with a consistent method (we recommend the MITRE rubric for applying CVSS to medical devices)
• The affected assets and the threat model entries it maps to
• The disposition: fixed, mitigated by a compensating control, or deferred
• For a deferral, the rationale, because the guidance says manufacturers "should provide their assessment of any findings including rationales for not implementing or deferring any findings to future releases"

Deferrals carry a second obligation. The submission "should contain plans for those releases," including which vulnerabilities each release addresses, anticipated timelines, whether devices shipped in the interim will receive the update, and how long the update takes to reach devices. Build that plan before the submission, not when the reviewer asks.

Retest after fixes. A finding marked fixed with no retest evidence is a finding marked claimed.

Step 6: Write the report FDA can use

The guidance lists five elements a penetration test report should include:

1. Independence and technical expertise of testers
2. Scope of testing
3. Duration of testing
4. Testing methods employed
5. Test results, findings, and observations

Most commercial reports cover items 2, 4, and 5 and skip 1 and 3. Add them. A short section on who tested, their relevant background, and their separation from the design team covers the first. Dates and effort per phase cover the third.

Attach the manufacturer's assessment of findings as a separate document or an appendix. Keep the third-party report unaltered. Our post on what an FDA-ready penetration test report looks like goes through the structure in detail, and our post on what FDA asks for from cyber devices shows where testing sits in the full submission.

Step 7: Repeat at intervals commensurate with risk

Section V.C closes with timing. Testing should occur throughout the development process, because "security testing early in development can ensure that security issues are addressed prior to impacting release timelines." After release, testing "should be performed at regular intervals commensurate with the risk (e.g., annually)."

Annually is FDA's example, not a rule. Set your interval from the device's risk. A life-sustaining implant with a wireless programmer carries a different risk than a connected thermometer, and the guidance uses that comparison when discussing update cycles for cyber devices. In our experience, higher-risk connected devices justify a shorter interval, and the Cybersecurity Management Plan (Section VI.B) is where you commit to one under "periodic security testing."

Test again outside the schedule when something changes. Section VII.D.1 gives examples of changes that may affect cybersecurity: changes to authentication or encryption algorithms, new connectivity features, and changes to the software update mechanism. A new entry in CISA's Known Exploited Vulnerabilities Catalog that touches a component in your SBOM is another trigger.

Testing that produces evidence, not a checkbox

A medical device penetration test earns its place in the submission when it traces back to the threat model, forward to risk decisions, and across to the architecture views that claim the controls work. Scope from your own documents, pick testers who can analyze firmware and radio as well as networks, and write the report to the five elements in Section V.C. The findings list will be shorter at the second test, and the reviewer will have fewer questions at the first.

Need help with medical device penetration testing? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices (21 U.S.C. 360n-2). https://www.law.cornell.edu/uscode/text/21/360n-2
• MITRE. Rubric for Applying CVSS to Medical Devices. October 2020. https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices
• CISA. Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog