What Goes in a Medical Device Penetration Test Report for FDA

An FDA-ready penetration test report needs seven things: the scope and exact device configuration tested, the qualifications and independence of the testers, the methodology and tools used, the test window, findings scored for severity and exploitability, any anomalies observed even if they weren't exploitable, and a disposition for every finding that ties back to your security risk assessment. FDA's premarket cybersecurity guidance (February 2026) lists five report elements in Section V.C: independence and technical expertise of testers, scope, duration, methods, and results. The seven here are those five plus the anomalies and dispositions the same section asks you to assess. Miss one and you're inviting a deficiency letter. This post walks through each section and explains what reviewers look for.

Why does FDA care what's in the report?

Since section 524B of the FD&C Act took effect, cybersecurity evidence stopped being optional for cyber devices. FDA's February 3, 2026 final guidance names penetration testing as one of the testing types it recommends, alongside vulnerability scanning, static analysis, and fuzz testing. Our post on what information FDA expects for cyber devices covers the full documentation set.

The report is how a reviewer, who never touches your device, judges whether the testing was real. A two-page summary that says "no critical issues found" tells them nothing. They want enough detail to convince themselves the testers were qualified, the scope covered the actual attack surface, and the findings were handled honestly.

What sections does the report need?

Scope and system configuration

State exactly what was tested: device model, software version, hardware revision, and the interfaces in scope (BLE, Wi-Fi, USB, cloud APIs, mobile app, physical ports). Just as important, state what was out of scope and why. If the cloud backend was excluded because it's covered by a separate SOC 2 assessment, say so.

Version matters more than teams expect. The report should describe the configuration you intend to ship. If you test build 3.1 and submit with build 3.4, be ready to justify why the delta doesn't affect the results.

Tester qualifications and independence

FDA's guidance asks for "independence and technical expertise of testers," and it's the section most reports are missing. State who performed the test and what level of independence they had from the developers, which is the wording the guidance uses. Our advice is to go one step further and include relevant experience and certifications, so the reviewer doesn't have to guess at expertise. Independence doesn't mean an outside firm is needed, but the testers can't be the same engineers who wrote the code. The guidance notes that in some cases a third party may be needed to get an appropriate level of independence.

Methodology and tools

Describe the approach (black, white, or grey box) and why it fits the device. For most medical devices, grey or white box gives better coverage per testing hour, since the goal is finding vulnerabilities rather than simulating a blind attacker. Our walkthrough of how to conduct medical device penetration testing covers the tradeoffs.

List the tools and frameworks used, with versions and configuration, and reference the standards you aligned to. AAMI TIR57 and the UL 2900 series (UL 2900-1 with the UL 2900-2-1 healthcare requirements) are the usual anchors for medical devices.

Test period and effort

Dates and level of effort. A one-day test of a connected infusion pump reads very differently from a three-week engagement, and reviewers notice.

Findings, scored and traceable

Each finding needs a description, the affected component and interface, reproduction steps, a severity score, and an exploitability assessment. Most teams use CVSS with a medical-device adjustment for patient harm potential; we've written about scoring medical device risk with CVSS separately.

The part reviewers increasingly check: each finding should map to your security risk assessment. A pen test finding that never shows up in the risk file suggests the two documents were produced in isolation, and that's a credibility problem for both.

Anomalies

FDA's guidance asks for anomalies observed during testing, not just confirmed vulnerabilities. Crashes, watchdog resets, unexpected debug output. Include them with an assessment of security relevance. An empty anomalies section in a lengthy engagement can look like the section was skipped.

Remediation and disposition

Every finding gets one of three outcomes: fixed and re-tested, accepted with documented rationale, or scheduled with a timeline. Include the re-test evidence for anything you fixed. Reviewers don't expect zero findings. They expect every finding to be handled.

What gets reports rejected?

The deficiencies we see most often, roughly in order:

• No tester qualifications, or testing performed by the development team with no independence discussion.
• Scope so narrow it dodges the real attack surface. Testing the mobile app but not the BLE link it talks over.
• Findings without severity scores or without any disposition.
• A test on a build that's several versions behind the submitted software.
• Summary-only reports. Some vendors treat the full report as proprietary and hand you a certificate. That certificate is worthless in an eSTAR submission.

That last one is worth screening for before you hire anyone. Our guide on choosing a penetration testing vendor covers the questions that surface it early.

How does the report fit into eSTAR?

The pen test report slots into the cybersecurity testing section of your eSTAR submission, alongside your other verification evidence. It should reference the same threat model and risk assessment IDs used across your cybersecurity file so a reviewer can trace a finding from test report to risk file to mitigation. The book chapter on security testing documentation for eSTAR submissions shows how the pieces fit together.

Getting a report that survives review

We run penetration tests built for FDA submissions: full reports with scope, methodology, tester independence and expertise, CVSS-scored findings, and traceability into your risk assessment, because that's the format reviewers are checking against. If you have a test coming up, or a report you're not sure will hold up, book a call and we'll take a look.

Need help with a penetration test report for FDA? Email us at info@cybermed.ai.

Sources

Primary documents named in this article:

1. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, FDA, February 3, 2026.
2. 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (Section 524B of the FD&C Act), Office of the Law Revision Counsel.
3. Cybersecurity in Medical Devices: Frequently Asked Questions, FDA.
4. eSTAR Program, FDA.
5. Common Vulnerability Scoring System (CVSS), FIRST.Org, Inc..
6. AAMI TIR57:2016/(R)2023, Principles for medical device security: Risk management, AAMI.
7. UL 2900-1, Standard for Software Cybersecurity for Network-Connectable Products, Part 1, UL Standards & Engagement.