DAST vs Penetration Testing: What the FDA Requires

Published June 11, 2026

Key Takeaways

• DAST ⊂ penetration testing. The FDA's Feb 3, 2026 final guidance lists penetration testing as a distinct deliverable alongside vulnerability scanning, SAST, and SBOM analysis, not as an alias for any of them.
• eSTAR v7.0 Slot 7 (Testing) expects evidence of all four, plus traceability back to the threat model and a named independent tester.
• DAST covers a narrow slice: HTTP/API endpoints, common web vulnerabilities, and some network services. It misses BLE pairing, USB-OTG, JTAG/UART, firmware downgrade, protocol fuzzing of DICOM/HL7/FHIR, and business-logic abuse.
• "We ran Burp" is the single most common Testing-section deficiency we see on connected device submissions.
• A compliant Testing package combines DAST + SAST + SBOM/CVE analysis + an independent penetration test report, all traced to the threat model.

Table of Contents

• Key Takeaways
• Why this matters
• What is DAST, precisely?
• What the FDA expects in eSTAR Slot 7
• Where DAST stops and penetration testing begins
• Why "we ran Burp Suite" fails reviewer scrutiny
• What a compliant Testing package looks like
• How Blue Goat Cyber approaches Slot 7
• FAQ

Why this matters

The FDA's February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, codifies what reviewers expect inside the Testing portion of a premarket submission. Section 524B of the FD&C Act made penetration testing a statutory companion to the broader Secure Product Development Framework (SPDF) for any "cyber device."

The practical consequence: when a reviewer opens eSTAR v7.0 Slot 7 and finds a single automated scan report, they issue a deficiency. Across the deficiency letters we have reviewed since the 2023 final guidance, "Provide evidence that testing exercised the device's actual interfaces, including [BLE / USB / firmware update / radio]" is one of the most repeated phrases. The recognized standards stack, AAMI SW96:2023, AAMI TIR57:2016 (R2023), IEC 81001-5-1, and NIST SP 800-218, all treat dynamic scanning and penetration testing as distinct activities with different rigor and independence requirements.

What is DAST, precisely?

DAST, Dynamic Application Security Testing, is automated runtime scanning of running interfaces, performed without access to source code. In medical device cybersecurity, that almost always means:

• Crawling and probing HTTP and HTTPS endpoints on a cloud back-end, clinician console, or device-hosted web UI
• Testing REST, GraphQL, and SOAP APIs for the OWASP API Security Top 10
• Some network service probing (open ports, TLS configuration, weak ciphers)
• Limited unauthenticated and authenticated scanning of common web vulnerabilities (injection, XSS, SSRF, misconfiguration, outdated components)

Common DAST tools in this space include Burp Suite Professional, OWASP ZAP, Acunetix, Invicti (Netsparker), and Nuclei. These tools are valuable. They are not penetration tests.

DAST is automated, signature-and-heuristic driven, and scoped to interfaces a scanner can reach over a network. That definition is the entire reason it cannot satisfy the FDA's penetration-testing expectation by itself.

What the FDA expects in eSTAR Slot 7

The Feb 3, 2026 final guidance enumerates the categories of security testing reviewers expect inside the Testing attachment. The list is consistent with the recognized standards stack and is broader than any single tool.

In eSTAR v7.0, those activities are filed inside Slot 7 (Cybersecurity | Testing). The reviewer is looking for:

1. A SAST report, source-code-level static analysis covering the first-party code base.
2. A DAST report, runtime scanning of every network-reachable interface.
3. SBOM + CVE + VEX analysis, known-vulnerability triage against the components in Slot 5.
4. An independent penetration test report, methodology-driven manual testing, scoped to the threat model in Slot 3, exercising hardware, radio, firmware, and business-logic attack paths the scanners cannot reach.
5. A traceability matrix, every threat in the Slot 3 threat model mapped to the test(s) that exercised it and the residual-risk argument from Slot 4.

Missing any of those four reports, or presenting one as a substitute for another, is a deficiency pattern reviewers know on sight.

Where DAST stops and penetration testing begins

The cleanest way to see the gap is a side-by-side. The left column is what DAST covers well. The right column is what only a human-led penetration test covers, and what FDA reviewers actively look for on a connected medical device.

Attack surface / technique	DAST	Independent penetration test
Web app and API vulnerabilities (OWASP Top 10, API Top 10)	✅ Strong	✅ Verified and extended manually
TLS configuration, weak ciphers, expired certs	✅	✅
BLE pairing, GATT enumeration, link-layer attacks	❌	✅ Required for any Bluetooth device
USB-OTG, USB service modes, mass-storage abuse	❌	✅
JTAG / SWD / UART / SPI flash extraction	❌	✅ Required for firmware-bearing devices
Firmware downgrade, rollback, signature bypass	❌	✅ Section 524B(b)(1) patchability evidence
Cellular, NFC, MedRadio, Wi-Fi protocol attacks	❌	✅
DICOM, HL7 v2, FHIR, ASTM protocol fuzzing	⚠️ Only generic HTTP fuzzing	✅ Medical-protocol-aware fuzzers
Business-logic abuse (workflow chaining, role escalation)	⚠️ Very limited	✅
Physical tamper, side-channel, fault injection	❌	✅ Where threat model requires
Multi-step exploit chains across interfaces	❌	✅
Independence and accountability for the report	⚠️ Tool output	✅ Named tester signs the report

DAST is a single instrument. A penetration test is the engagement that uses DAST output as one of its inputs, and then keeps testing.

Why "we ran Burp Suite" fails reviewer scrutiny

We see this exact submission pattern at least monthly: a sponsor places an auto-generated Burp Suite or ZAP HTML report into Slot 7, sometimes lightly edited, and calls it the penetration test. Reviewers reject it for three concrete reasons.

1. Scope-to-interface failure. The Feb 2026 guidance requires testing scoped to the device's actual interfaces. A DAST tool cannot reach BLE, USB, JTAG, or firmware. A Bluetooth-connected device whose only test evidence is a web scan has, by definition, not been tested across its threat surface.

See also: Penetration Test Case Design for Medical Devices, Does the FDA Accept AI Pen Testing for Medical Devices?, and Docker Containers in Medical Devices: What the FDA Expects You to Test.

2. Independence and accountability failure. A tool report has no qualified tester. The recognized standards (AAMI SW96:2023 §6, IEC 81001-5-1 §9.7) expect a named, independent assessor with documented qualifications. A PDF exported from Burp does not satisfy that.

3. Threat-model traceability failure. Every threat in the Slot 3 model needs a corresponding test result. Scanner output is organized by URL, not by threat. Without a manual traceability matrix, reviewers cannot confirm coverage, and "cannot confirm" is a deficiency.

The deficiency letter that follows is usually a Major Deficiency on a PMA or De Novo, or an Additional Information (AI) request on a 510(k). Either way, the clock either stops or restarts. The cost in calendar time alone, typically 4 to 12 weeks of remediation, often more, vastly exceeds the cost of doing the penetration test correctly up front.

What a compliant Testing package looks like

A Slot 7 package that passes review on first read contains, at minimum:

• SAST report with rule set, scope (modules covered), suppression rationale for each finding marked not-applicable, and a remediation log.
• DAST report covering every network-reachable interface, cloud APIs, mobile back-end, device-hosted UI, with authenticated and unauthenticated runs.
• SBOM-driven vulnerability analysis correlating the Slot 5 SBOM against NVD, CISA KEV, and EPSS, with VEX statements for every applicable CVE (not_affected, under_investigation, affected, fixed).
• Independent penetration test report from a third party with documented medical-device experience, scoped to the Slot 3 threat model, covering every interface the device exposes, network, radio, USB, debug ports, firmware update, and hardware where the threat model requires.
• Traceability matrix that maps each threat → test(s) performed → finding(s) → residual-risk argument, in one auditable thread.

That is the package the Feb 2026 guidance describes when read end-to-end. Anything thinner is an avoidable deficiency.

How Blue Goat Cyber approaches Slot 7

Our medical-device penetration test always layers DAST inside a broader engagement led by a named, independent tester (CISSP / OSCP / ex-military red team). Automated scanning runs as one workstream, in parallel with manual web and API testing, BLE/RF testing on a calibrated bench, USB and JTAG/UART exercises, firmware extraction and downgrade testing, and protocol fuzzing against DICOM, HL7, FHIR, and BLE GATT services. Every finding is mapped back to the sponsor's threat model and into a traceability matrix the reviewer can read.

We deliver the Slot 7 package, SAST summary, DAST report, SBOM/CVE/VEX correlation, and the signed penetration test report, formatted for direct eSTAR upload. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

See our medical device penetration testing service and our companion guide on scoping a medical device penetration test.

FAQ

Is DAST required for an FDA premarket submission?

DAST is one of the security-testing categories the FDA's Feb 3, 2026 final guidance lists as expected evidence inside eSTAR v7.0 Slot 7 (Testing). It is required in the sense that reviewers expect to see DAST output for any device with web, API, or network-reachable services. It does not, on its own, satisfy the separate penetration-testing expectation.

Can DAST replace penetration testing in an FDA submission?

No. The Feb 2026 guidance and the recognized standards (AAMI SW96:2023, IEC 81001-5-1) list penetration testing as a distinct activity that must be scoped to the threat model, exercise the device's actual interfaces (including hardware and radio where present), and be performed by a qualified independent tester. DAST is one input to that engagement, not a substitute for it.

Will the FDA reject our submission if we only run Burp Suite?

In practice, yes, connected devices submitted with only a DAST scan in Slot 7 routinely receive a deficiency letter requesting evidence that testing covered the device's actual interfaces. For PMA and De Novo this typically lands as a Major Deficiency; for 510(k) as an Additional Information (AI) request. Either way, the review clock is affected.

What tools count as DAST for medical device submissions?

The FDA does not name specific tools. Reviewers expect industry-recognized DAST tooling. The tools we use and see accepted include Burp Suite Professional, OWASP ZAP, Acunetix, Invicti, and Nuclei. What matters in the report is the scope (which endpoints were tested), the authentication state, the rule set or scan profile, the findings, and the remediation log, not the vendor logo.

Where does fuzz testing fit between DAST and penetration testing?

Protocol fuzzing, especially of medical protocols like DICOM, HL7 v2, FHIR, and BLE GATT, sits inside the penetration test, not inside generic DAST. Standard DAST tools fuzz HTTP parameters; they do not understand medical protocols. Fuzzing of those stacks requires specialized tooling and is part of what a qualified independent tester delivers.

Does our SaMD need hardware penetration testing too?

Pure SaMD with no hardware component does not need bench hardware testing, but it does still need the full DAST + manual web/API/cloud penetration test, plus the responsibility split for the underlying platform. SaMD that ships with a paired hardware accessory or runs on dedicated edge hardware needs the hardware testing too.

Ready to build a Slot 7 package that passes review?

If you are preparing a 510(k), De Novo, or PMA submission for a connected device, we will scope the testing to your threat model, run the full DAST + manual penetration test on a calibrated bench, and deliver a Slot 7 package formatted for direct eSTAR upload, with our deficiency-resolution guarantee. Request a scoping call.

---

Christian Espinosa, Founder, Blue Goat Cyber. CISSP, ex-military red team. Has led penetration tests on more than 250 FDA-submitted medical devices, including connected implantables, infusion pumps, IVD analyzers, and SaMD platforms. More on the author.

Related reading

• FDA Cybersecurity Testing Requirements Taxonomy
• The SPDF Playbook
• Penetration Test Case Design for Medical Devices