Third-party firmware in medical devices poses serious risks for cybersecurity and patient safety. With most medical devices now integrating external code like Bluetooth modules or real-time operating systems, vulnerabilities in these components can lead to data breaches or even harm patients. The FDA has responded with stricter requirements, including mandatory Software Bills of Materials (SBOMs) and lifecycle security plans for all connected devices starting February 2026.
Key Points:
- What’s at Risk? Outdated or insecure third-party firmware can expose devices to cyberattacks or operational failures, directly impacting patient care.
- FDA’s Response: New rules under Section 524B of the FD&C Act require manufacturers to document all third-party software, demonstrate security controls, and maintain vulnerability management plans.
- Compliance Challenges: Manufacturers must address supply chain blind spots, ensure firmware patchability, and align device lifecycles with firmware updates.
- Solutions: Effective third-party risk management, secure design practices, and continuous monitoring are critical to meeting FDA standards and ensuring safety.
The FDA’s regulations aren’t just about compliance - they’re about protecting patients and ensuring trust in medical technology. Addressing these risks now is essential for manufacturers to avoid delays, rejections, or worse: compromised patient safety.
The Problem: How Third-Party Firmware Creates Risk
Technical Vulnerabilities in Device Security and Performance
Third-party firmware introduces external code that can compromise device security and performance. Common risks include memory corruption, hardcoded credentials, and flaws in wireless communication protocols like Bluetooth and Wi-Fi. These vulnerabilities can impact devices in various ways, as illustrated below:
| Vulnerability Type | Potential Device Impact | FDA Security Objective Affected |
|---|---|---|
| Memory Corruption | Device crashes or unintended behavior | Availability |
| Hardcoded Credentials | Unauthorized access to device functions | Authorization |
| Integrity Failures | Unauthorized firmware modification | Authenticity |
| Legacy Dependencies | Unpatchable vulnerabilities over time | Updatability/Patchability |
| Protocol Flaws (Wi-Fi/Bluetooth) | Remote exploitation | Confidentiality / Availability |
Real-world incidents like URGENT/11 and SweynTooth highlight the dangers of these vulnerabilities. Both involve widely used communication stacks and have raised safety concerns across various clinical specialties [4]. When a device fails or its remote monitoring system is compromised, the consequences extend beyond IT issues - they directly affect patient safety.
These technical flaws are further complicated by supply chain challenges.
Supply Chain and Lifecycle Management Challenges
The risks tied to third-party firmware extend beyond technical vulnerabilities to include significant supply chain issues. Many manufacturers have limited insight into the components within third-party software development kits (SDKs). This lack of transparency makes it nearly impossible to respond swiftly when new vulnerabilities are uncovered [5].
Adding to the complexity is the mismatch between the lifecycle of medical devices, which often last 10–15 years, and the shorter lifespan of third-party firmware. When firmware becomes obsolete, devices may be left with unpatchable vulnerabilities, creating long-term risks [2].
Consistency in firmware versions across a fleet of devices is another major hurdle. If third-party updates don’t align with a manufacturer’s internal quality assurance cycles, configuration control can fail. This breakdown makes it difficult to verify what firmware is running on devices in the field, increasing the risk of security gaps.
Gaps That Lead to Regulatory Noncompliance
The combination of technical vulnerabilities and supply chain blind spots often results in regulatory issues. A common problem is an incomplete SBOM (Software Bill of Materials), particularly the failure to account for transitive dependencies. For example, a third-party library might rely on another component, such as a logging framework that uses a vulnerable version of zlib. Missing these hidden layers can delay FDA submissions.
Another issue is disconnected threat modeling. If an SBOM is submitted without tying it to the device’s threat model, it signals to the FDA that the manufacturer hasn’t fully considered the security risks of each external component [5]. Similarly, generic vulnerability management plans - those that lack specific details like triage criteria, patch timelines, or clinical impact - often lead to requests for more information or submission delays.
"An eSTAR submission will be put on a Technical Screening hold if it does not contain accurate responses and relevant attachments in the Cybersecurity section." - FDA [1]
Since 2026, the FDA has adopted stricter enforcement policies. Submissions without adequate cybersecurity documentation are now rejected outright, making supply chain security a critical requirement for device approval [6].
sbb-itb-535baee
Webinar: Master Medical Device Cybersecurity: Avoid FDA Delays
FDA Guidance on Third-Party Firmware: What Manufacturers Need to Know
Navigating FDA requirements for third-party firmware isn't just about ticking boxes. It's about understanding the risks these components pose throughout a device's lifecycle and addressing them proactively. The FDA's regulatory framework aims to ensure that manufacturers prioritize cybersecurity from the ground up.
Premarket Cybersecurity Requirements for Firmware
Under Section 524B of the Federal Food, Drug, and Cosmetic (FD&C) Act, manufacturers must include comprehensive cybersecurity documentation in every premarket submission, such as 510(k), PMA, De Novo, or HDE applications. This extends to third-party firmware, requiring that every component used in a device be fully documented.
Premarket submissions must include threat modeling that explicitly examines third-party components, cloud services, and communication interfaces [2]. Testing protocols - like penetration, vulnerability, and fuzz testing - must address the entire system, including open-source and third-party libraries within the firmware [2]. Additionally, manufacturers are required to submit a postmarket monitoring plan, detailing how vulnerabilities will be identified and addressed after the device is on the market. This plan must also include procedures for coordinated vulnerability disclosure [1][7].
Starting in February 2026, the Quality Management System Regulation (QMSR) will require manufacturers to integrate third-party vendor risk management into purchasing decisions, as outlined in ISO 13485 Clause 7.4. This means that security requirements must be included in agreements with firmware suppliers before submission [2]. Furthermore, the FDA insists that off-the-shelf firmware components meet the same stringent security standards as proprietary software.
Off-the-Shelf Software Standards Applied to Firmware
Third-party firmware is subject to the same risk-based documentation and validation requirements as proprietary code [1][3]. This means any off-the-shelf (OTS) software embedded in a device must undergo rigorous validation.
To meet these expectations, the FDA encourages manufacturers to adopt a Secure Product Development Framework (SPDF), aligned with standards like IEC 81001-5-1 or the Joint Security Plan (JSP2) [3]. These frameworks embed security into every stage of a product's lifecycle - from design and production to decommissioning. One recommended method, Software Composition Analysis (SCA), helps manufacturers analyze firmware binaries to uncover hidden third-party components and their associated vulnerabilities [3].
"FDA expects cybersecurity to be embedded within manufacturers' quality systems and reflected in premarket submissions when applicable." - Exponent [3]
Manufacturers must also provide clear cybersecurity instructions and warnings with their devices. Failing to do so could result in a misbranding violation under Section 502(f) of the FD&C Act, which can lead to recalls [3].
Software Bills of Materials (SBOMs) and Their Role
An SBOM is essentially a detailed list of all software components within a device. As mandated by Section 524B(b), manufacturers must submit an SBOM covering all commercial, open-source, and off-the-shelf software components, including third-party firmware [1]. This requirement has been in effect since March 29, 2023, and as of October 1, 2023, the FDA began enforcing a "Refuse to Accept" policy for submissions that lack an SBOM [1].
Beyond compliance, SBOMs play a critical role in cybersecurity. They enable Software Composition Analysis, allowing manufacturers to quickly identify which firmware components are impacted by newly disclosed vulnerabilities and respond effectively [3]. Additionally, maintaining an SBOM aligns with the FDA's Total Product Life Cycle (TPLC) approach, which emphasizes ongoing monitoring and patching of third-party components throughout a device's market life [1][2].
To streamline vulnerability tracking, SBOMs should be provided in machine-readable formats like SPDX or CycloneDX [2]. Using these standardized formats allows manufacturers to automate threat detection and response, reducing the need for manual cross-referencing.
"Section 524B(b)[1] of the FD&C Act requires that manufacturers of cyber devices provide a software bill of materials (SBOM) for the commercial, open-source, and off-the-shelf software components contained within the device." - FDA [1]
Solutions: Reducing Third-Party Firmware Risk
FDA Third-Party Firmware Risk: Vendor Tier Assessment Framework for Medical Devices
Turning regulatory requirements into effective daily practices is key to reducing risks associated with third-party firmware. Here's how manufacturers can move from simply understanding compliance to taking actionable steps.
Governance and Supplier Management
Effective supplier governance, as outlined by FDA guidance, transforms compliance into a proactive approach to security. Not all firmware suppliers pose the same level of risk. For instance, a vendor providing safety-critical control software demands more scrutiny than one supplying a peripheral display module. The most practical method to handle this is through vendor risk tiering. By categorizing suppliers into tiers - Critical, High, Medium, or Low - based on their access to patient data or device control functionalities, manufacturers can tailor assessment frequencies. For example:
- Critical suppliers: Assessed quarterly
- High-risk suppliers: Assessed semi-annually
- Medium-risk suppliers: Assessed annually
| Vendor Tier | Criteria | Assessment Frequency |
|---|---|---|
| Critical | Direct access to patient data or safety-critical software | Quarterly |
| High | Indirect access to device systems or known vulnerability history | Semi-annually |
| Medium | Peripheral components with limited device interaction | Annually |
| Low | No network connectivity or data access | At onboarding or triggered |
Supplier contracts should include requirements like 24-hour vulnerability notifications for Critical suppliers, 72-hour notifications for High-risk suppliers, fixed timelines for patching, SBOM (Software Bill of Materials) delivery in SPDX or CycloneDX format, and audit rights [2]. These aren't just legal safeguards - they ensure suppliers remain accountable throughout the product's lifecycle.
Additionally, it's important to address risks beyond direct vendors by extending governance to sub-tier suppliers [2].
Platforms such as Censinet RiskOps™ can simplify these processes. They enable streamlined risk assessments, collaborative vendor management, and continuous monitoring, helping manufacturers meet FDA and QMSR requirements efficiently.
Security Controls During Device Design
Addressing security during the design phase is far more cost-effective than fixing issues after deployment. Manufacturers should incorporate secure boot to ensure only cryptographically verified firmware runs on devices, and code signing to prevent tampering during transit from supplier to device.
Threat modeling should include third-party components alongside proprietary code, with explicit security requirements passed down to suppliers of cybersecurity-critical components during the design phase [2]. This alignment between threat models and supplier contracts ensures consistency from the beginning.
Using Software Composition Analysis (SCA) tools during development is another effective measure. These tools scan firmware binaries to identify hidden third-party components and flag known vulnerabilities before devices are submitted for approval. When combined with fuzz testing, static analysis, and dynamic code analysis, this layered approach helps catch issues early, when they are still manageable [3].
By implementing these design controls, manufacturers can set a strong foundation for secure device deployment.
Vulnerability Monitoring and Patch Management
Continuous monitoring and timely patching are essential for protecting devices throughout their lifecycle, aligning with the FDA's Total Product Life Cycle approach.
The SBOM should be treated as a living document, updated with every release and validated quarterly [6][2]. Monitoring must also cover transitive dependencies - for example, a vulnerable compression library embedded within a logging framework can introduce risks that might be overlooked if only top-level components are tracked [6].
Patching medical devices requires a different approach than enterprise software. Clinical context matters - a firmware update can't be applied to a device actively in use during a procedure. Prioritization should consider exploitability and clinical impact alongside CVSS scores.
"A plan that lists CVSS thresholds without considering exploitability and clinical impact will receive review questions." - Shadab Khan, Security Engineer, Safeguard [6]
For third-party components no longer supported by their original vendors, mitigation measures like network segmentation and access restrictions can help minimize exposure while a migration or replacement plan is developed [2]. This is especially critical for legacy devices where some firmware components may have reached the end of their support lifecycle.
Conclusion: Meeting FDA Requirements and Strengthening Cybersecurity
Third-party firmware has become a major concern for both regulatory compliance and patient safety. With medical devices now relying on external components for 75% or more of their makeup [8], vulnerabilities hidden in third-party code pose serious risks. Adding to the urgency, healthcare data breaches in 2024 have an average cost of $9.8 million [2].
Meeting the requirements of FDA Section 524B and QMSR, which take effect in February 2026, is not optional. Manufacturers that approach these regulations as mere checklists - rather than embedding SBOM transparency and strict supplier oversight - could face "Refuse to Accept" holds or even misbranding issues.
Key Takeaways
To address these challenges, manufacturers need to prioritize cybersecurity at every stage of a product’s lifecycle. A strong defense strategy includes SBOM transparency, layered supplier governance, secure design protocols, and ongoing post-market monitoring.
Tools like Censinet RiskOps™ simplify this process by automating vendor risk assessments, streamlining monitoring activities, and enabling collaboration across the supply chain. This approach not only helps manufacturers comply with FDA requirements but also avoids unnecessary operational strain. With 35% of hospitals now refusing to purchase medical devices lacking an SBOM [8], supply chain transparency is no longer just a regulatory requirement - it’s a market demand.
The solution is clear: build security into the supply chain from the outset, maintain dynamic SBOMs, enforce supplier accountability through contracts, and ensure continuous monitoring. By following these practices, manufacturers can protect patient safety while preserving trust in the marketplace.
FAQs
How can I tell if my device’s SBOM is complete (including transitive dependencies)?
To create a comprehensive Software Bill of Materials (SBOM), especially one that includes transitive dependencies, rely on automated tools during the build process. Manual methods often overlook deeply nested components, which can lead to gaps in your SBOM. Incorporating tools like OWASP cdxgen into your CI/CD pipeline ensures the SBOM is generated before the final packaging stage. Stick to widely recognized formats such as CycloneDX or SPDX for consistency and reliability. Additionally, configure your pipeline to halt the process if SBOM generation isn't completed, ensuring no critical steps are missed.
What evidence does the FDA expect to prove third-party firmware is patchable for 10–15 years?
Manufacturers are required to clearly document the Software Component Support Level for every component listed in their Software Bill of Materials (SBOM). This involves identifying the support status - whether it's active, security-fixes-only, or legacy - and specifying the End-of-Support (EOS) dates.
For open-source components that lack clearly defined EOS dates, manufacturers must evaluate the support status based on factors such as commit history or registry updates. Additionally, they need to submit a written justification of their findings to the FDA.
How should manufacturers prioritize firmware vulnerabilities beyond CVSS (clinical impact and exploitability)?
Manufacturers need to look deeper than just CVSS scores when evaluating vulnerabilities. A device-specific exploitability analysis is crucial. This means examining whether the vulnerable component is actually present in the device, if the code path is accessible, and whether existing controls reduce the risk. Beyond that, it's essential to evaluate how the vulnerability might affect patient safety, clinical effectiveness, or data integrity. This thorough review helps identify whether a vulnerability could create a safety hazard or demands urgent action to fix it.
