Medical device penetration testing services

What FDA expects from a penetration test

FDA's premarket cybersecurity guidance (final, February 3, 2026) says cybersecurity controls require testing beyond standard software verification and validation. Section V.C lists four types of security testing for a submission: security requirements testing, threat mitigation testing, vulnerability testing, and penetration testing.

The penetration test report has to state who did the testing and how independent and technically expert they were, plus the scope, the duration, the methods, and the results, findings and observations. FDA wants the original third-party report, not a summary, along with the manufacturer's own assessment of every finding.

A finding marked deferred is a recurring cause of deficiency letters. The guidance reasons that if a penetration tester could exploit a vulnerability, a threat actor's ability to do so is likely to grow over the device lifecycle. Deferred items need a plan that says which release fixes them, when, and how the fix reaches fielded devices.

Testing continues after clearance. The guidance expects it throughout the secure product development framework and, after release, at regular intervals commensurate with risk, with annually as FDA's own example.

Three kinds of provider

Providers fall into three groups. The right one depends on how many releases a year the device ships and who inside the company will own the findings.

• Consulting-led manual testing. Specialist firms put engineers on the device by hand. Judgment on novel attack paths and physical access is the strength. Each engagement is a project with its own calendar and quote, and the result is a report at a point in time.
• Lab certification. Testing labs evaluate against a published standard and issue a certificate or conformance report. UL 2900-2-1 is the standard FDA recognized for premarket review in 2018. Confirm that scope also follows the device's own threat model.
• Platform and agentic testing. Software runs repeatable test cases against the device and its connected systems, usually with human review of the results. The draw is rerunning the same tests on every release and at the annual retest. Ask what the humans review, what the platform cannot reach, and how physical interfaces are covered.

What a submission-ready scope covers

Scope should trace to the threat model, interface by interface. FDA's own example of a hostile assumption is a hospital network where an adversary can alter, drop and replay packets, so the tests need a network position as well as access to the device itself.

• Hardware. Debug ports, storage and bus access.
• Firmware. Extraction, analysis and hunting for hardcoded or default credentials.
• Wireless. Bluetooth Low Energy, Wi-Fi, cellular and proprietary radio.
• Apps and portals. Companion mobile apps and clinician or patient portals.
• Cloud and APIs. Every service the device talks to.
• Update path. The end-to-end route software takes to the device, including infrastructure the manufacturer does not control.
• Chains. Lower-severity findings that combine into a patient-safety impact.

Tester independence and duration go in the report. A test run by the team that wrote the code, or compressed into a day for a device with five interfaces, invites questions.

Ten questions to put to every provider

1. Who performs the testing, what are their credentials, and are they independent of the design team?
2. Does the scope follow our threat model, and will each test case map to a named threat?
3. Do you test hardware, firmware, wireless, mobile, cloud and the update path yourselves, or subcontract part of it?
4. How do you test vulnerability chaining, and how is it reported?
5. What does a finding contain: exploitability, patient-safety impact, and a fix specific enough to implement?
6. Will you retest fixes on the shipping build and deliver evidence of the result?
7. Does the report state independence, scope, duration, methods and results, as Section V.C lists?
8. What happens when FDA sends an Additional Information request about the report?
9. Can the same tests be rerun at the next release and at the annual retest, and at what cost?
10. Who owns the raw test cases, logs and artifacts when the engagement ends?

Red flags

• A scanner export dressed as a report. Automated scan output without manual validation of findings.
• Findings marked deferred with no plan. FDA reads these as unmitigated risk.
• No link to the threat model. Test cases that cannot be traced to a threat leave gaps a reviewer will find.
• Generic fixes. Advice such as "follow best practices" does not close a deficiency.
• No retest. A fix that was never verified on the shipping build is still an open question.