Security Testing
Medical-device cybersecurity testing is evidence that security requirements, risk controls and threat mitigations work in the real device system. FDA expects more than ordinary software verification and validation, and a single vulnerability scan is not enough to prove the cybersecurity case.
Testing purpose
Cybersecurity testing should show whether the selected controls work in the security context that matters for the device. That means the test scope should follow the threat model, security architecture, interfaces, data flows, trust boundaries, update paths, user roles and deployment assumptions.
Premarket evidence
The premarket file uses testing to support design verification, design validation, security-control effectiveness and risk-control adequacy.
Postmarket evidence
The postmarket process uses testing to assess new vulnerabilities, verify fixes, check regressions and maintain confidence in fielded versions.
Premarket testing scope
FDA's current premarket guidance identifies several kinds of cybersecurity testing and analysis that may belong in a submission. The useful file does not list every possible test. It explains why the selected tests match the device risk, architecture and controls.
This testing shows that design input requirements were implemented and that boundary assumptions are justified. It should connect requirements to architecture elements and security-control acceptance criteria.
This testing shows that risk controls work against threats identified in the threat model and architecture views. It should address security effectiveness, stability, reliability and traffic or workload conditions when those conditions matter.
FDA examples include abuse or misuse cases, malformed and unexpected inputs, robustness testing, fuzz testing, attack surface analysis, vulnerability chaining, known vulnerability scanning, software composition analysis of binary executable files, and static or dynamic code analysis.
Penetration testing should try to discover and exploit security vulnerabilities in the product. FDA expects reports to explain tester independence and expertise, test scope, duration, methods, results, findings and observations.
One scan is not enough
A scan can support the file, but it does not prove the security architecture, update path, authentication model, cryptographic design, logging behaviour, recovery path or user responsibility. A scanner also cannot decide by itself whether exploitation could affect patient harm or whether residual risk is acceptable.
- A vulnerability scan can find known issues, but it may miss design flaws and unsafe trust assumptions.
- Static analysis can find code-level weaknesses, but it does not prove deployed configuration or runtime control behaviour.
- Fuzz testing can expose malformed-input handling, but it does not replace architecture review or penetration testing.
- Penetration testing can show exploit paths, but it is still bounded by scope, time, tester access and methodology.
Findings feed risk management
Testing findings should be assessed for security impact and connected to the cybersecurity risk-management process. FDA explains that a security anomaly may need mitigation because its exploitability can create a different kind of harm than an ordinary software defect.
Assessment of findings
Reports should explain the finding, affected component or interface, exploitability, affected versions, control status and patient-harm implication.
Deferred remediation
If a fix is deferred, the file should explain the risk rationale, planned release, affected fielded devices and how the update will reach them.
Postmarket testing
FDA recommends security testing throughout the secure product development framework and after release at intervals that match the risk. Postmarket testing may be needed for new CVEs, supplier changes, changed deployment assumptions, revised update infrastructure, incident investigation, patch validation and regression assessment.
For EU files, MDCG 2019-16 links verification and validation, risk-management updates, PMS, incident handling and security updates. IEC 81001-5-1 can support this lifecycle discipline for health software, but it does not replace FDA or MDR evidence mapping.
Primary sources
Sources
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 2026
- FDA, Postmarket Management of Cybersecurity in Medical Devices, final guidance, December 2016
- European Commission, MDCG 2019-16 Guidance on Cybersecurity for medical devices
- IEC, IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security