DAST vs Penetration Testing for FDA Submissions

Published June 11, 2026

Why this matters

The FDA's February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, codifies what reviewers expect inside the Testing portion of a premarket submission. Section 524B requires cybersecurity processes, a postmarket monitoring and disclosure plan, and an SBOM for qualifying submissions; it does not expressly prescribe penetration testing. The guidance recommends penetration testing within broader security testing.

A scanner-only submission can leave hardware, wireless, and workflow risks untested. Document risk-based coverage and any exclusions rather than assuming a particular deficiency or review outcome.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B); CISA Cybersecurity Advisories (including ICS medical advisories).

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.

[GUIDANCE SUMMARY] The FDA recommends four security testing categories: security requirements testing, threat mitigation testing, vulnerability testing, and penetration testing. Select techniques appropriate to the device and document methods, results, and traceability.

Use the applicable eSTAR v7.1 cybersecurity testing prompts. The following is a practical packaging example, not a fixed set of universally mandatory reports:

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.

Justify the selected techniques and exclusions against the device architecture and threat model. VEX is optional and is not mentioned in the FDA guidance.

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.

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

An automated Burp Suite or ZAP report should not be labeled a complete penetration test unless the broader methodology, scope, and manual assessment support that claim.

1. Scope-to-interface failure. The February 2026 guidance recommends risk-based 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.

2. Independence and accountability. Document tester qualifications and organizational independence from the developers. Independent testers may be internal or external; the FDA does not universally require a third party.

3. Threat-model traceability failure. Provide traceability and evidence that risk controls are effective against the supplied threat model. Scanner output alone may not establish coverage; the FDA does not prescribe a manual matrix or a unique test result for every threat.

Insufficient evidence can prompt additional information or deficiency questions. Letter type, clock effects, and remediation time depend on the pathway and review circumstances.

What a compliant Testing package looks like

See also: FDA & AI Pen Testing for Medical Devices, FDA Submission Issue Request: Cybersecurity Q-Submission Guide, and Medical Device Pen Testing: FDA vs EU MDR 2026.

A practical testing package can include the following, as appropriate to the risk-based scope:

• 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 documented vulnerability dispositions; VEX statements are optional for applicable CVEs (not_affected, under_investigation, affected, fixed).
• Independent penetration test report by qualified internal or external testers independent of development, 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 one practical way to organize evidence supporting the February 2026 guidance recommendations. Adequacy depends on justified scope and evidence, not report count.

For the full list of what the FDA expects from a pen test, see FDA penetration testing requirements.

How Blue Goat Cyber approaches Slot 7

If you want this done for your device, see our medical device penetration testing service.

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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

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

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

Related reading: VM Escape in Medical Device Cybersecurity: Risk and Mitigations.

FAQ

Is DAST required for an FDA premarket submission?

DAST is a useful vulnerability-testing technique for applicable running interfaces. The guidance does not establish DAST as a universal statutory requirement; justify the methods chosen for the device.

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?

Not automatically. A scanner-only package may be inadequate if it does not cover the relevant attack surface, but no specific rejection or letter type can be predicted.

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?

The FDA lists fuzz testing within vulnerability testing. Protocol-aware fuzzing may also support a broader penetration-testing engagement. Select tooling and scope for the relevant protocols and threat model.

Does our SaMD need hardware penetration testing too?

Pure SaMD with no hardware component does not need bench hardware testing, but testing should address relevant software, web, API, cloud, and platform risks. For paired accessories or dedicated edge hardware, justify hardware testing scope against the architecture and threat model.

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 commitment. Request a scoping call.

---

Christian Espinosa, Founder, Blue Goat Cyber., ex-military red team. Has led penetration tests on more than 275 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