On this page
Published: · Updated:
Key Takeaways
- The Feb 2026 guidance defines four required categories of security testing: vulnerability scanning, software composition analysis, static/dynamic analysis, and penetration testing.
- Each category must be documented with methodology, scope, tester independence, findings, and remediation status.
- Penetration testing must be performed by testers independent of the design team, reviewers now flag lack of independence as a Major deficiency.
- Findings must be mapped to the threat model and security risk assessment so patient-safety impact is visible.
- Testing evidence must be regenerated for material software changes, not carried forward indefinitely.
What cybersecurity testing does the FDA require for medical devices?
The FDA's February 2026 final premarket cybersecurity guidance expects evidence from roughly ten testing families: static and dynamic analysis, software composition analysis with VEX, vulnerability scanning, fuzz testing, independent penetration testing, abuse and misuse case testing, patch and update mechanism testing, authentication and access control testing, and cryptographic implementation testing. Each result must trace to the threat model filed in eSTAR v7.0, since untraceable testing is generally not credited by reviewers.
The FDA's February 3, 2026 final premarket cybersecurity guidance does not list a single "security test." It expects a portfolio. Reviewers know the portfolio on sight and issue deficiency letters when entries are missing or mislabeled. This guide is the complete taxonomy: 10 testing families, what each one covers, what it misses, the tools the FDA's reviewers commonly accept, where each result lives in eSTAR v7.0, and the deficiency pattern that follows when it's absent.
Last updated: June 2026 · Aligned to the FDA's February 2026 final guidance and Section 524B of the FD&C Act.
How the FDA frames "security testing" in the 2026 guidance
The Feb 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions and Section 524B of the FD&C Act both require security testing as a deliverable inside the Secure Product Development Framework (SPDF). The guidance enumerates the categories of testing reviewers expect to see and ties them to the recognized standards stack: AAMI SW96:2023, AAMI TIR57:2016 (R2023), AAMI TIR97:2019, IEC 81001-5-1, IEC 62304, NIST SP 800-218 (SSDF), and OWASP ASVS / MASVS for software-as-a-medical-device (SaMD).
The submission should include security testing documentation that demonstrates the cybersecurity of the device, including (but not limited to) vulnerability testing, penetration testing, SBOM analysis, software composition analysis, static application security testing (SAST), and dynamic application security testing (DAST), with results traced to the threat model and architecture views.
In eSTAR v7.0, testing evidence is filed inside Slot 7 (Cybersecurity | Testing), with supporting evidence anchored in Slot 5 (SBOM) and Slot 6 (Controls). For the full slot map, see our eSTAR v7.0 mapping guide.
The rest of this page walks each of the 10 families.
1. Static analysis (SAST)
What it is. Automated analysis of source code (or compiled bytecode/IR) to surface known defect patterns: buffer overflows, taint flows, injection sinks, insecure API usage, hardcoded secrets, weak random number generation, dangerous compiler flags.
What it catches. Defects that are visible in code structure: input → sink flows, memory-safety patterns in C/C++, deserialization sinks, hardcoded credentials, weak crypto primitives, dangerous functions (strcpy, system, eval).
What it misses. Anything that depends on runtime state or external configuration: authentication logic bugs, business-logic abuse, race conditions in distributed systems, vulnerabilities in third-party binaries you don't have source for, and every hardware or radio attack path.
Tools the FDA's reviewers commonly accept. Coverity, Fortify, Checkmarx, Semgrep, SonarQube, CodeQL, MISRA-aware tools (LDRA, Polyspace) for safety-critical embedded code.
Where it lives. eSTAR v7.0 Slot 7 (Testing). The SAST report should cover the first-party code base with documented scope, rule set, suppression rationale for every "not applicable," and a remediation log.
Common deficiency pattern. "Provide SAST results for the [module] code base and rationale for suppressed findings." This usually means the submission included SAST output for one module but not the connected-device firmware, or included a tool summary with no suppression log.
Standards anchor. IEC 81001-5-1 §5.6; NIST SSDF PW.7; AAMI SW96:2023 §6.
2. Software composition analysis (SCA) / SBOM vulnerability analysis
What it is. Identification of third-party and open-source components in the device (the SBOM), correlated against known-vulnerability feeds (NVD, GitHub Advisory Database, vendor advisories, CISA KEV, EPSS), with a VEX (Vulnerability Exploitability eXchange) statement for each applicable CVE explaining its status: not_affected, under_investigation, affected, or fixed.
What it catches. Known CVEs in third-party components, the single largest source of post-clearance vulnerabilities. EOL/end-of-support components. License-derived risk where it overlaps with security (unmaintained projects).
What it misses. Zero-days, custom first-party code (that's SAST/DAST), and configuration mistakes when a component is integrated insecurely.
Tools the FDA's reviewers commonly accept. Anchore, Snyk, Dependency-Track, Black Duck, Mend (WhiteSource), Trivy, Grype, Syft. The format must be CycloneDX or SPDX, machine-readable, with NTIA minimum elements (superseded by CISA's 2026 Minimum Elements for an SBOM, published July 29, 2026).
Where it lives. SBOM itself in eSTAR v7.0 Slot 5; the vulnerability analysis and VEX statements live in Slot 7 (Testing). See our SBOM vulnerability management guide and CycloneDX vs SPDX comparison.
Common deficiency pattern. "SBOM submitted without VEX statements for [CVE-XXXX-XXXX]. Provide exploitability assessment in the device's context." This is one of the most-cited deficiencies under Section 524B(b)(3).
Standards anchor. Section 524B(b)(3); NTIA minimum elements; AAMI TIR97:2019 for postmarket triage.
3. Dynamic application security testing (DAST)
What it is. Automated runtime scanning of network-reachable interfaces: HTTP/HTTPS endpoints, REST/GraphQL/SOAP APIs, and some network services, performed without source-code access.
What it catches. OWASP Top 10 and API Top 10 patterns (injection, XSS, SSRF, broken auth, misconfiguration, outdated components), TLS configuration issues, weak ciphers, expired certs, default credentials reachable over the network.
What it misses. BLE, USB, JTAG, UART, SPI, firmware, cellular, NFC, MedRadio, business-logic abuse, and any multi-step exploit chain. DAST scopes itself to whatever a scanner can reach over a network.
Tools the FDA's reviewers commonly accept. Burp Suite Professional, OWASP ZAP, Acunetix, Invicti (Netsparker), Nuclei.
Where it lives. eSTAR v7.0 Slot 7. The report must document scope (which endpoints were tested), authentication state (unauthenticated + each role), the scan profile or rule set, findings, and the remediation log.
Common deficiency pattern. Submissions that present a DAST report as the penetration test. Reviewers issue a deficiency requesting evidence that testing covered the device's actual interfaces. See our deeper post: DAST vs penetration testing.
Standards anchor. OWASP ASVS / MASVS; IEC 81001-5-1 §9.7.
4. Vulnerability scanning
What it is. Network-, host-, and configuration-level scanning to baseline the device and its environment against known CVEs and misconfigurations. Distinct from DAST in that it scans the system, not the application logic.
What it catches. Missing OS patches on the device and any companion systems, dangerous open ports and services, weak service banners, default OS credentials, insecure network protocols (Telnet, SMBv1, anonymous LDAP), TLS/SSH version and cipher posture.
What it misses. Application-layer bugs (DAST/pen test territory), hardware, radio, and any vulnerability not yet in a public feed.
Tools the FDA's reviewers commonly accept. Nessus, OpenVAS / Greenbone, Qualys VMDR, Rapid7 InsightVM, Nuclei (with vulnerability templates).
Where it lives. eSTAR v7.0 Slot 7, often bundled into the penetration test report appendix.
Common deficiency pattern. Vulnerability scan output included without remediation log or suppression rationale; high-severity findings present with no disposition.
Standards anchor. NIST SP 800-115; ISO/IEC 27001 Annex A.12.
5. Fuzz testing
What it is. Generation of malformed, unexpected, or randomized inputs to a protocol or interface to find crash, hang, memory-corruption, and state-confusion bugs. For medical devices, this almost always means protocol-aware fuzzing (generic byte-flipping does not exercise DICOM, HL7, FHIR, or BLE GATT meaningfully).
What it catches. Memory-safety bugs in protocol parsers, state-machine confusion in pairing or session setup, denial-of-service paths, malformed-input crashes that translate directly into patient-safety hazards.
What it misses. Anything that requires understanding intent: authorization bugs, business-logic abuse, missing controls. Fuzzing finds crashes, not policy gaps.
Tools the FDA's reviewers commonly accept. AFL++, libFuzzer, Honggfuzz, Boofuzz, peach3, Defensics (Synopsys), Mayhem (ForAllSecure), medical-protocol-specific fuzzers for DICOM, HL7 v2, FHIR, ASTM, and BLE GATT. See our fuzz harness generation guide.
Where it lives. eSTAR v7.0 Slot 7, inside the penetration test report or as a separate fuzz testing appendix.
Common deficiency pattern. "Provide evidence of fuzz testing against [DICOM/HL7/FHIR/BLE] interfaces." Generic HTTP fuzzing does not satisfy this when the device speaks medical protocols.
Standards anchor. IEC 81001-5-1 §9.7; AAMI SW96:2023 §6.4.
6. Penetration testing
What it is. Methodology-driven, manual security testing by a qualified independent assessor, scoped to the device's threat model, exercising every interface the device actually exposes: network, radio (BLE, Wi-Fi, cellular, NFC, MedRadio), USB, debug ports (JTAG/SWD/UART/SPI), firmware update mechanism, and business-logic abuse. Penetration testing uses DAST, SAST, SCA, vulnerability scanning, and fuzzing as inputs and extends well beyond them.
What it catches. Multi-step exploit chains, hardware tamper paths, firmware downgrade and signature-bypass paths, radio-protocol attacks, USB service-mode abuse, JTAG/UART firmware extraction, business-logic abuse, side-channel and fault injection where the threat model requires.
What it misses. Things by design out of scope. If your engagement statement of work excludes a class of testing, that exclusion needs an explicit residual-risk argument.
Tools the FDA's reviewers commonly accept. Tooling is not the bar; the named, independent assessor with documented qualifications is. Tools we see in accepted reports: Burp Suite Pro, Metasploit, Nessus, Bettercap, Ubertooth/HackRF/Proxmark/Flipper Zero, Saleae logic analyzers, ChipWhisperer, JTAGulator, and protocol-specific fuzzers.
Where it lives. eSTAR v7.0 Slot 7 as the signed penetration test report, with a traceability matrix mapping every Slot 3 threat to the test(s) that exercised it.
Common deficiency pattern. A DAST report presented as the pen test (see family 3). Web-only pen test on a Bluetooth device. Self-assessment with no third-party independence.
Standards anchor. Section 524B; AAMI SW96:2023 §6.5; IEC 81001-5-1 §9.7; OWASP MASVS for SaMD; NIST SP 800-115.
For depth: FDA penetration testing requirements · scoping a medical device penetration test · BLE/RF pen test case study.
7. Abuse and misuse case testing
What it is. Testing against negative requirements (what the device must not do), derived from the threat model and from intended-misuse scenarios (IEC 62366-1 human-factors abuse cases), including malformed inputs, unexpected user actions, off-spec environments, and adversarial workflow chaining.
What it catches. Behavior the requirements never explicitly forbade but that creates safety or security hazards: workflow chaining (combining two legitimate actions into an unsafe sequence), input-validation gaps that aren't strict-protocol-fuzz territory, intended-misuse paths a clinician or patient could take, off-spec environments (low battery, network drop, sensor failure mid-procedure).
What it misses. Implementation defects you'd find with SAST or pen testing. Abuse cases are about scenario coverage, not bug discovery.
Tools the FDA's reviewers commonly accept. No single tool; this is methodology-driven. Common approaches: threat-model-derived abuse-case worksheets, exploratory testing logs, IEC 62366-1 use-error tables extended with adversarial paths.
Where it lives. eSTAR v7.0 Slot 7, often cross-referenced from Slot 2 (Risk Management) and Slot 3 (Threat Model) because abuse-case results feed both human-factors and security risk files.
Common deficiency pattern. Reviewers see a long list of positive test cases and no evidence of negative-requirement testing. "Provide test evidence for abuse/misuse cases identified in the threat model."
Standards anchor. AAMI TIR57:2016 (R2023) / ANSI/AAMI SW96:2023 5.6; IEC 62366-1; IEC 62304 5.5. See abuse and misuse case testing.
8. Patch and update mechanism testing
What it is. Verification that the device can be updated "in a reasonably and reliably timely manner," the statutory phrasing from Section 524B(b)(1). Tests the signed-update path end-to-end: signature verification, root-of-trust integrity, rollback handling, anti-rollback (version monotonicity), update-channel authentication, failure-mode safety, and time-from-CVE-to-deployed-patch SLA evidence.
What it catches. Unsigned or weakly-signed updates, missing rollback handling, downgrade attacks that re-enable patched vulnerabilities, broken root-of-trust chains, update mechanisms that brick the device on a failed transfer.
What it misses. The vulnerabilities themselves; this family proves you can deliver fixes, not that the fixes exist.
Tools the FDA's reviewers commonly accept. Custom test harnesses against the update endpoint, signing-key compromise simulation, version-rollback test cases, network-interruption tests during update.
Where it lives. eSTAR v7.0 Slot 6 (Controls) describes the mechanism; Slot 7 (Testing) holds the evidence.
Common deficiency pattern. "Provide evidence of patchability demonstrating compliance with Section 524B(b)(1)." Submissions describe a mechanism but show no test results exercising it.
Standards anchor. Section 524B(b)(1); NIST SP 800-193 (Platform Firmware Resiliency); IEC 81001-5-1 §9.4.
9. Authentication, authorization, and access control testing
What it is. Verification of identity, role enforcement, and key-handling for every account class on the device: clinician, patient, service technician, manufacturer, machine-to-machine. Covers RBAC enforcement, session management, multi-factor where required, account lockout, password policy, service-account isolation, and key lifecycle.
What it catches. Authentication bypass, privilege escalation, horizontal authorization gaps (IDOR), broken session handling, hardcoded service credentials, weak default credentials, missing rate limits on credential endpoints.
What it misses. Implementation defects in the underlying crypto (family 10), and any attack that doesn't go through the auth surface.
Tools the FDA's reviewers commonly accept. Burp Suite Pro intruder/repeater, Postman/curl-based test suites, OWASP ASVS-aligned manual test plans, automation via custom scripts.
Where it lives. Slot 6 (Controls) describes the design; Slot 7 (Testing) holds the evidence.
Common deficiency pattern. "Provide test evidence for role-separation enforcement between [role A] and [role B]." Or: hardcoded service credential discovered in pen test → traced to missing auth test plan coverage.
Standards anchor. IEC 81001-5-1 §6.1, 9.7; OWASP ASVS 2 (authentication), 4 (access control); NIST SP 800-63B.
10. Cryptographic implementation testing
What it is. Verification that cryptography is correctly chosen, correctly implemented, and correctly operated across its lifecycle. Covers algorithm selection, key generation entropy, key storage (HSM/TPM/secure element/keystore), key rotation, certificate handling, TLS configuration, and FIPS 140-3 validation status where applicable.
What it catches. Weak or deprecated algorithms (MD5, SHA-1 in signatures, DES, RC4), insecure modes (ECB), weak key generation (low entropy, predictable seeds), missing certificate validation, downgrade-vulnerable TLS configuration, key material exposed in logs or memory, expired or self-signed certs in production paths.
What it misses. Application-layer bugs that bypass crypto entirely (e.g., an API that accepts both a JWT and a static API key).
Tools the FDA's reviewers commonly accept. testssl.sh, sslyze, nmap NSE crypto scripts, custom test harnesses for key-rotation flows, FIPS 140-3 module certificate references from NIST CMVP.
Where it lives. Slot 6 (Controls) describes the cryptographic posture; Slot 7 (Testing) holds the evidence.
Common deficiency pattern. "Provide FIPS 140-3 validation status for the cryptographic module used for [function]" or "Provide test evidence that key rotation does not interrupt clinical function."
Standards anchor. FIPS 140-3; NIST SP 800-131A (algorithm transitions); NIST SP 800-57 (key management).
Traceability is its own deliverable
Every test result in families 1-10 must trace back to the threat model in eSTAR v7.0 Slot 3 and forward into the residual-risk argument in Slot 4. Reviewers organize their assessment by threat, not by tool. A scanner report organized by URL is not a traceable artifact until you map each finding to the threats it exercises.
A clean traceability matrix has, at minimum: threat ID · test family · test ID(s) · finding(s) · remediation or residual-risk argument · evidence pointer (file/page). Most accepted submissions we have seen format this as a single spreadsheet appendix to the Testing attachment.
How the 10 families fit together
A premarket submission for a connected medical device that passes Slot 7 review on first read typically includes:
- SAST report (family 1): first-party code base, with suppression log.
- SBOM + VEX (family 2): CycloneDX or SPDX, with VEX statements for every applicable CVE.
- DAST report (family 3): every network-reachable interface, authenticated and unauthenticated.
- Vulnerability scan output (family 4): typically appended to the pen test report.
- Fuzz testing evidence (family 5): medical-protocol-aware where the device speaks medical protocols.
- Independent penetration test report (family 6): signed by a named, independent assessor, scoped to the threat model.
- Abuse/misuse case test evidence (family 7): negative-requirement testing.
- Patch/update mechanism test results (family 8): evidence supporting Section 524B(b)(1).
- Auth/access control test plan + results (family 9): every role, every account class.
- Cryptographic implementation test results (family 10): including FIPS 140-3 status where applicable.
- Traceability matrix: threat → test → result → residual-risk argument.
Anything thinner is an avoidable deficiency. Anything heavier is fine; reviewers do not penalize over-evidence.
How Blue Goat Cyber covers the 10 families
We scope every medical-device cybersecurity engagement against this 10-family taxonomy. Static and composition analysis run in the build pipeline; dynamic and vulnerability scanning run against the deployed environment; fuzzing runs against the actual protocols the device speaks (DICOM, HL7, FHIR, BLE GATT, USB, ASTM); penetration testing happens on a calibrated bench with the real hardware in front of a qualified, independent assessor (CISSP / OSCP / ex-military red team); abuse-case, patch-mechanism, auth, and crypto testing layer in based on the threat model. We deliver the full Slot 7 package (every report, the traceability matrix, and the residual-risk argument) formatted for direct eSTAR upload.
If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our penetration testing service and the companion eSTAR v7.0 mapping guide.
FAQ
Does the FDA require every one of these 10 testing families on every submission?
Not literally every family on every device; a pure cloud-hosted SaMD with no hardware doesn't need JTAG/UART pen testing inside family 6, and a device with no BLE doesn't need BLE fuzzing inside family 5. But every family that could apply given the device's threat surface must either be performed or have an explicit residual-risk argument for why it was excluded. Silent exclusion is a deficiency pattern.
What's the difference between vulnerability scanning and DAST?
Vulnerability scanning baselines the system: OS patch level, open ports, service banners, network-protocol posture. DAST tests the application: endpoint behavior, input handling, authentication logic, business logic. Both live in Slot 7 and both are usually expected on any device with network-reachable services.
Is fuzz testing required if we already ran pen testing?
A penetration test for a device that speaks medical protocols (DICOM, HL7, FHIR, BLE GATT, ASTM) should include protocol-aware fuzzing as part of its scope. If your pen test report does not document fuzzing against those interfaces, reviewers ask for it separately. It's not a separate test family in your project plan if the pen-test scope is right; it is a separate deliverable family in the FDA's mental model.
Can we use a single tool that "does it all"?
No tool covers all 10 families, and reviewers know this. Be skeptical of any vendor pitch claiming a single platform satisfies the entire Testing attachment. The portfolio matters more than the brand on any individual report.
What's the most common Slot 7 deficiency?
Across the deficiency letters we have seen since the February 2026 final guidance, the top three patterns are: (1) a DAST report presented as the penetration test (family 3 vs 6 confusion), (2) SBOM in Slot 5 with no VEX statements in Slot 7 (family 2 gap), and (3) missing fuzz evidence for the medical protocols the device speaks (family 5 gap on a device with BLE, DICOM, HL7, or FHIR).
Where does threat modeling fit into the testing taxonomy?
Threat modeling is not a testing family; it lives in Slot 3 as its own deliverable. But every entry in the 10 families must trace back to it. Without a Slot 3 threat model, the test results in Slot 7 have nothing to map to and reviewers cannot credit coverage. See our STRIDE threat modeling guide.
Related reading
- eSTAR v7.0 Cybersecurity Attachments mapping guide
- FDA cybersecurity guidance
- FDA Premarket Cybersecurity Submission Checklist
- DAST vs Penetration Testing
- FDA Penetration Testing Requirements
- FDA Security Requirements Testing: The 2026 Verification Guide
- Scoping a Medical Device Penetration Test
- Fuzz Harness Generation for Medical Device Protocols
- Abuse and Misuse Case Testing
- SBOM Vulnerability Management
- STRIDE Threat Modeling for Medical Devices
References
Primary sources cited or relied on in this guide:
- Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Feb 2026 final), U.S. FDA
- ANSI/AAMI SW96:2023, Standard for Medical Device Security, AAMI/ANSI
- IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security, IEC/ISO
- OWASP Application Security Verification Standard (ASVS), OWASP
- Section 524B of the FD&C Act (Consolidated Appropriations Act, 2023, §3305), U.S. Congress
Sources & references
Primary sources cited in this article. Links open in a new tab.
- February 2026 final guidance- U.S. FDA
- Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Feb 2026 final)- U.S. FDA
- ANSI/AAMI SW96:2023, Standard for Medical Device Security- AAMI
- IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security- ISO
- OWASP Application Security Verification Standard (ASVS)- OWASP
