FDA recommends four kinds of cybersecurity testing evidence in a premarket submission: security requirements testing, threat mitigation testing, vulnerability testing and penetration testing. Reports should state who tested, how independent they were, the scope, the duration, the methods and the findings, along with the manufacturer's response to each finding.
Why ordinary software testing is not enough
The guidance says cybersecurity controls need testing beyond standard software verification and validation, to show the controls work in a proper security context. Verification and validation under ISO 13485 still apply, and security testing is added to them.
The four categories
Security requirements. Evidence that each design input requirement was implemented, plus the boundary analysis and the reasoning behind boundary assumptions.
Threat mitigation. Evidence that risk controls work as the threat models in the architecture views say they should. The guidance includes adequacy checks such as how well a control enforces the stated security policy, and its performance, stability and reliability.
Vulnerability testing. The guidance lists, citing ANSI/ISA 62443-4-1:
- Abuse and misuse cases, malformed and unexpected inputs.
- Fuzz testing and robustness testing.
- Attack surface analysis.
- Vulnerability chaining.
- Closed box testing for known vulnerabilities.
- Software composition analysis of binary executables.
- Static and dynamic code analysis, including a search for hardcoded, default, easily guessed or easily compromised credentials.
Penetration testing. Testing that tries to discover and exploit weaknesses in the product.
What a penetration test report should include
The guidance asks for independence and technical expertise of the testers, scope, duration, methods and results with findings and observations. It asks manufacturers to say who did the testing, and how independent that team was from the developers. For third party reports, the original report should be provided.
For tools, the details may include the tool name, version and configuration.
Findings need a recorded decision
Every finding needs the manufacturer's assessment. If a finding is deferred, the submission should explain why. For issues to be fixed in a later release, the guidance asks for the plan: which vulnerabilities, expected timelines, whether devices released in the meantime will get the update and how long delivery takes.
Security differs from ordinary defect triage here. A defect with little clinical effect might be left alone in normal testing. In security testing, exploitability can make the same defect worth fixing, since an attacker can trigger it on purpose and repeatedly.
When to test
FDA recommends testing throughout the development framework, not only at the end, and after release at regular intervals commensurate with risk, such as annually.
Quick check
Does software composition analysis count as security testing?
Yes. FDA lists software composition analysis of binary executable files under vulnerability testing, next to fuzzing, attack surface analysis and static and dynamic code analysis.
Can the same team that wrote the code run the penetration test?
The guidance asks you to disclose the testers' independence from the developers and says third parties may be needed to keep an appropriate separation.
Sources
Last reviewed: 19 October 2026.
