How to Conduct Medical Device Penetration Testing

There's a prevailing belief that medical device penetration testing is solely about finding security vulnerabilities.

It's not.

Another important part of medical device penetration testing is coming to a better understanding of what an attacker might do with vulnerability info as well as how that knowledge could impact device safety or performance.

It's that second part that can be a head scratcher for medical device manufacturers because you have to review your threat model and security architecture before deciding what to test. As such, independent testers will need to participate. These are professionals who understand medical devices, including firmware, communication interfaces, and software updates.

Look at it this way: Finding vulnerabilities is only half the job.

FDA wants manufacturers to evaluate findings through their risk management process. Be aware that Section V.C of its February 2026 premarket cybersecurity guidance also identifies five elements for penetration testing reports.

And yet another thing to remember: Testing doesn't end when the device reaches the market, either. FDA recommends risk-based testing intervals. FDA guidance calls for annual testing (as an example).

If you're looking for guidance on how to conduct penetration testing for a medical device, this article will help you with your approach. We cover the steps from defining the scope to documenting results for FDA reviewers.

Where penetration testing sits in FDA's testing expectations

Understanding FDA penetration testing requirements starts with Section V.C of the agency's February 3, 2026 final guidance. It makes an important point: Cybersecurity controls need "testing beyond standard software verification and validation activities."

The guidance identifies four types of testing manufacturers should consider including in their premarket submissions:

• Security requirements testing: Evidence that each security design input was implemented, including boundary analysis.
• Threat mitigation testing: Evidence that risk controls work across the global system, multi-patient harm, updatability and patchability, and security use case views.
• Vulnerability testing: Abuse and misuse cases, malformed inputs, fuzz testing, attack surface analysis, vulnerability chaining, closed-box scanning for known vulnerabilities, binary software composition analysis, and static and dynamic code analysis.
• Penetration testing: Attempts to discover and exploit security vulnerabilities in the device.

Penetration testing builds on the other three. Without security requirements and a threat model, testers may find vulnerabilities but have no clear way to connect them to specific risks or controls.

Our book chapters on security testing approaches and security testing documentation for eSTAR explain how these activities fit together and where the results belong in a submission.

The distinction between vulnerability scanning and penetration testing is worth emphasizing. A scan might identify a component with a known CVE. A penetration test goes further. Can an attacker reach that vulnerability, exploit it, or combine it with another weakness to compromise the device?

That's what manufacturers need to understand.

Step 1: Scope the test from the threat model

Before testing begins, review the threat model (Section V.A.1), security architecture views (Section V.B.2), and software bill of materials (SBOM) (Section V.A.4).

These documents help identify what needs testing and where attackers might find a way in.

For a connected medical device, the scope typically includes:

• Network interfaces: Ethernet, Wi-Fi, cellular connections, listening services, and communication protocols.
• Short-range radio: Bluetooth Low Energy pairing, bonding, and characteristic access, proprietary RF, NFC, and magnetic inductive links used by implant programmers.
• Physical ports: USB, serial, JTAG and SWD debug headers, SD cards, and service connectors. These interfaces may also factor into whether a device meets the statutory definition of a cyber device.
• Firmware: Extraction, stored secrets, secure boot, and integrity checks between boot stages.
• The update path: Everything from the update server to the device, including code signing and verification.
• Companion software: Mobile apps, clinician workstations, and cloud services, including related systems addressed under Section 524B(b)(2).
• Users and roles: Service accounts, clinician and patient permissions, and default or recovery credentials.

Not everything has to be included in the same engagement. But exclusions need an explanation.

For example, if a separate team is testing the cloud backend, document that decision and reference its report. The same applies to hospital networks or other systems outside the agreed scope.

You'll also need to establish how long testing will take. FDA expects the report to document the testing duration.

Don't underestimate this part. A device with eight interfaces can't be adequately evaluated with a quick scan over two days. Allow enough time to investigate each interface and attempt exploitation when testers uncover a potential weakness.

Step 2: Choose the access model

Next, decide how much information testers should receive.

There are three common approaches:

• Black box: Testers receive the device with little or no supporting information. This simulates an external attacker but can consume considerable time on reconnaissance.
• Grey box: Testers receive architecture views, the threat model, SBOM, and user-level credentials, but not source code.
• White box: Testers have full access, including source code, build artifacts, and debugging tools.

For premarket medical device penetration testing, grey-box or white-box testing is usually the better choice.

Why? Because the objective isn't simply to see whether someone can break into the device. It's to determine whether the security controls identified during development actually work.

Giving testers access to the relevant documentation lets them concentrate on those controls instead of spending valuable time discovering information the manufacturer already has.

FDA's recommended vulnerability testing activities also include static and dynamic code analysis and software composition analysis of binaries. Those activities benefit from access to code or build artifacts, although they're separate from penetration testing itself.

Step 3: Decide who runs the test

Who performs the penetration test matters almost as much as how it's performed.

Section V.C of FDA's guidance asks manufacturers to identify the testers and explain their level of independence from the people who designed the device.

That doesn't necessarily mean hiring an outside company.

An internal security team can provide sufficient independence if its members weren't involved in designing the device and operate separately from the development team.

But having a firmware engineer test their own code doesn't provide the same level of independence.

If you're using internal testers, document their reporting structure and relationship to the development team.

For third-party testing, FDA asks manufacturers to include the original third-party report rather than a summary prepared internally.

Independence isn't the only consideration, though.

Medical devices require specialized expertise that general IT penetration testers may not have. Depending on the device, that could mean experience with embedded firmware, RF communications, Bluetooth Low Energy, hardware debugging, or security vulnerabilities that could affect patient safety.

Our article on choosing a penetration testing vendor explains what manufacturers should look for.

Step 4: Run the test in device-specific phases

Most penetration testing methodologies follow a familiar sequence: reconnaissance, scanning, exploitation, persistence, and reporting.

Medical device security testing follows much the same process, but there's an important difference. Testers need to account for the device's hardware, software, communications, and potential effects on patient safety.

Reconnaissance and attack surface analysis

Start by identifying every interface an attacker might reach. Then compare what testers find against the security architecture views.

Pay particular attention to anything that doesn't match the documentation.

An undocumented listening port, an enabled debug header, or a Bluetooth characteristic that accepts unauthenticated writes could indicate a security weakness worth investigating.

Document these findings, even if they don't lead to a successful exploit.

Also record the tools used during testing, including their names, versions, and configurations. FDA's guidance specifically calls for this information in its discussion of testing documentation.

Firmware analysis

Start by extracting the firmware from the device, the update package, or both.

Look for the security weaknesses FDA specifically identifies, including hardcoded credentials, default passwords, and credentials that are easy to guess or compromise. Check for embedded private keys, API tokens, and certificates that could give an attacker access.

Next, run software composition analysis on the firmware binary and compare the results with your software bill of materials (SBOM).

If the binary contains components missing from the SBOM, investigate and correct the discrepancies before submission.

You'll also want to test secure boot and the chain of trust. Can someone install modified firmware? Does the bootloader verify the application's signature? And does the application check the integrity of its configuration data?

These tests help determine whether an attacker could introduce unauthorized changes without the device detecting them.

Interface and protocol testing

Every interface needs to be tested against the abuse and misuse cases identified in your threat model.

That includes feeding malformed or unexpected inputs into parsers to see how they respond. FDA identifies this technique, known as fuzz testing, as part of vulnerability testing.

For Bluetooth Low Energy (BLE), check pairing, bonding, and access permissions. Do the characteristics enforce the restrictions documented in your threat model?

Network services need similar attention. Test authentication, session management, encryption in transit, and certificate validation.

Don't overlook physical ports, either. A USB service connection or exposed debug interface could give someone with brief physical access a way into the device.

The goal is to determine whether the interfaces behave securely under conditions they weren't necessarily designed to encounter.

Exploitation and vulnerability chaining

Finding individual vulnerabilities is important. But what happens when an attacker combines them?

That's the purpose of vulnerability chaining, which FDA identifies among its recommended vulnerability testing activities.

For example, an exposed debug log might reveal information that helps an attacker exploit a weak session token. That access could then allow unauthorized changes to a configuration file.

Individually, those weaknesses might seem manageable. Together, they could create a much more serious problem.

Testers should investigate whether identified vulnerabilities can be combined and document the resulting attack paths.

For each successful chain, explain how the attacker gained access, which weaknesses were exploited, and whether the outcome could affect device safety or essential performance.

Update path and recovery

Software updates are another potential entry point for attackers.

Test the entire update process, from the server delivering the update to the device installing it.

Can an attacker redirect the device to an unauthorized update server? Will it accept an unsigned or older firmware image? What happens if the connection drops halfway through installation?

That last question is particularly important. Appendix 1 of FDA's guidance asks manufacturers to consider how the update process handles communication interruptions or failures.

Don't stop once you've identified a problem.

Test whether the device can recover from a failed or compromised update. Can it return to a known good state? Will the user know whether recovery succeeded?

Document the results so reviewers can see how the device handles both normal updates and unexpected failures.

Persistence and detection

An attacker who gains access to a medical device may try to make unauthorized changes permanent.

Test whether those changes survive a reboot, factory reset, or software update.

Then look at what the device records.

Does it log unauthorized access attempts, configuration changes, or other suspicious activity? Would those records give a hospital security team enough information to investigate an incident?

FDA's guidance identifies event detection and logging as an important security control category in Appendix 1.

If an attack succeeds without generating the expected security logs, that's a finding worth documenting.

After all, detecting a security incident can be just as important as preventing one.

Step 5: Assess every finding in your risk process

Finding vulnerabilities is one thing. Deciding what to do about them is another.

Section V.C of FDA's guidance says manufacturers should evaluate vulnerabilities and anomalies identified during testing as part of their security risk management process.

And there's an important distinction between security vulnerabilities and ordinary software defects.

A minor software defect might have little effect on device performance. But a seemingly minor security weakness could give an attacker access to something far more serious.

That's why every finding needs an assessment.

For each one, document:

• Exploitability and potential patient harm: Use a consistent scoring method. We recommend the MITRE rubric for applying CVSS to medical devices.
• Affected assets: Identify the systems or components involved and connect the finding to the relevant threat model entries.
• Disposition: State whether the vulnerability was fixed, addressed through a compensating control, or deferred.
• Rationale: If you're deferring a fix, explain why. FDA expects manufacturers to justify findings they choose not to address immediately.

Deferring a fix also means documenting what happens next.

FDA expects manufacturers to provide plans for future releases, including which vulnerabilities will be addressed, anticipated timelines, whether devices already shipped will receive the update, and how long deployment should take.

Have those answers ready before submitting. Otherwise, you may find yourself responding to additional FDA questions.

And remember to retest after making changes. Without retest evidence, there's no confirmation that the fix actually worked.

Step 6: Write the report FDA can use

When preparing a penetration test report, FDA expectations go beyond simply listing vulnerabilities.

Section V.C of the agency's guidance identifies five elements manufacturers should include:

1. Tester independence and technical expertise: Who performed the testing, what qualifications they have, and how independent they are from the development team.
2. Scope: What systems, components, and interfaces were tested.
3. Duration: How long the testing took.
4. Methods: Which testing approaches and techniques were used.
5. Results: The vulnerabilities, findings, and observations documented during testing.

For manufacturers preparing a 510(k) submission, cybersecurity testing documentation helps FDA reviewers understand how the device's security controls were evaluated. The penetration test report is one part of that evidence, along with security requirements testing, threat mitigation testing, and vulnerability testing.

Some commercial penetration testing reports focus heavily on scope, methods, and findings but provide little information about tester independence or duration.

If those details are missing, make sure they're included.

You should also provide the manufacturer's assessment of the findings, either as a separate document or an appendix.

If a third party performed the testing, preserve the original report rather than replacing it with an internal summary.

Our article on what an FDA-ready penetration test report looks like explains the reporting structure. You can also review what FDA asks for from cyber devices to see how penetration testing fits into the broader submission.

Step 7: Repeat at intervals commensurate with risk

Penetration testing shouldn't be something you do once before submitting a device to FDA.

Section V.C recommends testing throughout development so manufacturers can identify and resolve security issues before they delay a product's release.

Testing should continue after the device reaches the market.

FDA recommends regular intervals based on risk, with annual testing given as an example.

But annual testing isn't a universal requirement.

A life-sustaining implant with wireless connectivity may need more frequent testing than a connected thermometer. The appropriate schedule depends on the device, its vulnerabilities, and the potential consequences of an attack.

Document your planned testing intervals in the Cybersecurity Management Plan under Section VI.B, which addresses periodic security testing.

You should also consider additional testing whenever significant changes occur.

Section VII.D.1 identifies several examples of changes that could affect cybersecurity, including:

• Changes to authentication or encryption algorithms
• New connectivity features
• Modifications to the software update mechanism

Newly discovered vulnerabilities can also justify testing outside the regular schedule.

For example, if a component in your SBOM appears in CISA's Known Exploited Vulnerabilities Catalog, evaluate whether the vulnerability affects your device and whether additional testing is needed.

The important thing is to make testing an ongoing part of cybersecurity risk management rather than a one-time regulatory exercise.

Testing that produces evidence, not a checkbox

A successful medical device penetration test does more than uncover vulnerabilities. It gives manufacturers evidence that their security controls work and helps them understand where improvements are needed.

That starts with a well-defined scope based on the threat model and security architecture. It also requires testers who understand the device's technology, whether that involves firmware, wireless communications, or network interfaces.

Just as important, the findings need to feed into the manufacturer's risk management process.

When the testing is complete, document the results using the five reporting elements FDA identifies in Section V.C.

Do that consistently, and you'll have more than a penetration testing report. You'll have evidence that supports your cybersecurity decisions and gives FDA reviewers a clearer picture of how you've addressed the risks.

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