Medical-device cybersecurity testing
Sytance · Updated
Medical-device cybersecurity testing checks whether security requirements and risk controls work in the device’s intended configuration. The results need to show the test conditions and observed behaviour so reviewers can judge what the testing establishes about the product.
Testing purpose
The test scope follows the device’s threats and security requirements. If only an authorised service account may change configuration, test the direct interface with both permitted and prohibited accounts and observe whether the stored settings change.
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 submission should explain why the selected tests are appropriate for the device risks, 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 vulnerability scan reports findings within its coverage. It may identify a known weakness in a network service, while a separate test is needed to check whether the device rejects an unauthorised command or recovers after a failed update. Assess patient impact using the device architecture and risk analysis.
- 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 during development and after release at intervals appropriate to the risk. A change to the update mechanism, for example, may require new integrity and recovery tests. A newly disclosed component vulnerability may require investigation and regression testing of the fix.
For EU documentation, the verification results support the risk assessment and can identify changes needed to the device or its instructions. MDCG 2019-16 explains how this work continues after release. IEC 81001-5-1 provides a lifecycle process for maintaining those activities.
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