Cybersecurity in Medical Devices
As medical devices increasingly incorporate software, wireless connectivity, and integration with broader health IT systems, cybersecurity has become a critical component of device safety and effectiveness. This expanded connectivity has introduced new attack surfaces, making devices more vulnerable to cybersecurity threats that can directly or indirectly impact patient care.
Cyber incidents such as ransomware attacks or exploitation of software vulnerabilities have already disrupted hospital operations and compromised medical device functionality.
In some cases, this has led to delays in diagnosis or treatment, placing patients at risk. To mitigate these risks, the U.S. FDA emphasizes that medical device manufacturers must consider cybersecurity throughout the Total Product Lifecycle (TPLC), from design and development through postmarket surveillance.
1. Cybersecurity - Integration with Quality System Regulation:
As part of the software validation and risk analysis required by 21 CFR 820.30(g), software device manufacturers may need to establish cybersecurity risk management and validation processes.
To reduce vulnerabilities and support compliance with Quality System Regulation (QSR), FDA encourages the use of an Security Product Development Framework (SPDF), which integrates security throughout the product lifecycle—from design to decommission.
SPDF helps minimize the likelihood and impact of cybersecurity risks, and may prevent the need for postmarket design changes when connectivity-based features are added or new vulnerabilities are discovered.
Medical Device Cybersecurity Strategies
A radial diagram illustrating nine interconnected cybersecurity strategies for medical devices:
- Cybersecurity Testing
- Threat Modeling
- Risk Assessment
- Interoperability
- Third-Party Software
- Software Bill of Materials
- Anomaly Assessment
- TPLC Security Management
- Security Controls
a. Threat Modeling
Threat modeling is a proactive technique used to identify and mitigate cybersecurity threats during the device design phase. It enables developers to visualize potential attack vectors, assess system-level vulnerabilities, and define appropriate countermeasures.
b. Cybersecurity Risk Assessment
Security risk assessments must be fully integrated into the overall quality system, addressing risks beyond direct patient harm, such as data breaches and system availability issues.
FDA recommends utilizing established frameworks, including AAMI TIR57, ANSI/AAMI SW96, and AAMI TIR97, to manage risks across the device lifecycle from development through post-market.
c. Interoperability Considerations
Interoperability between medical devices and other IT systems introduces unique cybersecurity concerns.
Manufacturers must evaluate all interoperable functions, such as connections to Electronic Health Records (EHRs), smartphones, or cloud platforms. Risk assessments should determine how these connections may expose the device to threats.
Security controls should be implemented to ensure safe data exchange without impeding interoperability or usability.
d. Third-Party Software Components
Manufacturers are responsible for identifying, validating, and managing risks associated with the third-party components. The third-party software must be treated as part of the device's design controls, with traceable supplier oversight and contingency plans for patching or replacing software nearing end-of-support.
e. Software Bill of Materials (SBOM)
An SBOM provides transparency into the software components and dependencies used within a device. It plays a critical role in identifying affected products during vulnerability disclosures.
The manufacturer must include a machine-readable SBOM in premarket submissions. This should include component names, versions, suppliers, and any known vulnerabilities, supporting timely risk response and remediation.
f. Security Assessment of Unresolved Anomalies
Not all software anomalies identified during testing can be resolved prior to release. Manufacturers must assess the security implications of these anomalies to determine their impact on device safety and effectiveness.
g. TPLC Security Risk Management
Manufacturers must continuously monitor emerging threats, reassess vulnerabilities, and update security controls. This includes revisiting threat models, SBOMs, and risk assessments as part of ongoing vigilance.
h. Implementation of Security Controls
Security controls form the foundation of a resilient medical device. These controls may include:
- Authentication and authorization
- Cryptographic data protection
- Integrity verification
- Event logging and monitoring
- Secure software updates
i. Cybersecurity Testing
Cybersecurity testing validates the device's resilience against real-world threats. This includes:
- Security requirements and threat mitigation: Evidence of implemented design inputs, boundary assumptions, and effective risk controls.
- Vulnerability testing: Includes robustness checks, fuzz testing, abuse/misuse scenarios, attack surface analysis, and static/dynamic code analysis.
- Penetration testing
- Incident response validation
- Verification and validation of implemented security controls
Testing reports should be included in premarket submissions to support the risk mitigation claims made by the manufacturer.
2. Designing for Security
The FDA evaluates device cybersecurity in premarket submissions based on how well a product meets core security objectives, including:
- Authentication
- Authorization
- Cryptography
- Code, Data, and Execution Integrity
- Confidentiality
- Event Detection and Logging
- Resiliency and Recovery
- Updatability and Patchability
Design considerations must reflect the device's intended use, connectivity, and environment of operation. This includes identifying all system interfaces and connections, evaluating risks (e.g., from hospital networks or cloud infrastructure), and implementing security controls as part of the design process, not as add-ons.
FDA recommends including Security Architecture Views in premarket submissions, such as:
- Global System View – showing the entire device ecosystem and all connections.
- Multi-Patient Harm View – evaluating risks where one breach could affect multiple patients.
- Updateability/Patchability View – explaining how software updates are securely delivered end-to-end.
- Security Use Case Views – demonstrating how security is maintained in specific device operations.
These views should combine diagrams and explanations that trace security controls to system requirements and threat models, enabling FDA to assess the safety and effectiveness of the device from a cybersecurity perspective.
3. Cybersecurity Transparency:
Manufacturers must share sufficient information to enable informed risk management by users, system integrators, and healthcare providers.
This includes:
- Disclosure of known and zero-day vulnerabilities
- Description of communication interfaces and ports
- Use of third-party software (e.g., through a Software Bill of Materials (SBOM))
- Update mechanisms and secure configuration instructions
Clear labeling supports secure deployment and maintenance, ensuring the device remains resilient to cybersecurity threats throughout its lifecycle. Insufficient disclosure may lead to a device being considered misbranded.
4. Submission Documentation
The extent of cybersecurity documentation in premarket submissions should reflect the cybersecurity risk level of the device. Devices with network connectivity or integration into larger systems typically carry higher risk and require more robust cybersecurity controls and supporting evidence.
Documentation should include:
- Threat modeling and risk assessments
- Description of security architecture
- Evidence of validation and verification of cybersecurity features
- Alignment with design controls per Secure Product Development Framework