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. Miss one of these and you're inviting a deficiency letter. This post walks through each section and explains what reviewers actually 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 premarket cybersecurity guidance names penetration testing as one of the expected testing types, 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 this explicitly, and it's the section most reports are missing. Include who performed the test, their relevant experience and certifications, and their relationship to the development team. Independence doesn't require an outside firm, but the testers can't be the same engineers who wrote the code.

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 and reference the standards you aligned to. AAMI TIR57 and UL 2900-2-1 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 qualifications, CVSS-scored findings, and traceability into your risk assessment, because that's the format reviewers are checking against. Every submission we've supported has been cleared. 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.