If your medical device uses third-party software, the FDA now expects you to track it, test it, disclose its risks, and fix issues after release. That includes open-source code, commercial software, embedded modules, and cloud services.
I’d boil the article down to this:
- Cybersecurity is now tied to device safety and FDA compliance
- Manufacturers are still responsible for third-party code they don’t control
- SBOMs must include direct and transitive dependencies
- Vulnerability monitoring must continue after launch
- Public disclosure, patch timelines, and supplier controls now matter more
- Hospitals should ask vendors for SBOMs, VEX, support dates, and escalation contacts
A few numbers make the point fast: third-party code can make up 80%+ of a device software stack, open-source software shows up in 96% of commercial codebases, and 84% of those codebases contain known vulnerabilities. In healthcare, 44% of organizations report devices with known unpatched flaws, and 28% report devices past support dates.
From my view, the message is simple: an SBOM alone is not enough. You need a process that connects inventory, CVE review, KEV checks, risk scoring, patching, compensating controls, and vendor follow-up.
For manufacturers, that means tying cybersecurity work to design controls, purchasing controls, CAPA, and postmarket plans under the FDA and QMSR. For healthcare teams, that means turning vendor disclosure into a buying and risk-review step instead of a file that sits untouched.
Below, I’ll keep the focus on what teams need to do, what the FDA is asking for, and where many organizations still fall short.
Webinar: FDA Expectations for SBOMs - A Deep Dive with Blue Goat Cyber
sbb-itb-535baee
FDA Cybersecurity Expectations for Third-Party Software in Medical Devices
FDA cybersecurity requirements for third-party software sit inside QMSR, SBOM, and postmarket controls. In practice, that means the work has to show up in design controls, SBOMs, third-party risk management, and postmarket disclosure.
Key FDA guidance documents and what they require
Under QMSR and ISO 13485, cybersecurity is part of design controls, purchasing controls, and verification. It does not belong in some stand-alone appendix. Threat modeling should connect to design inputs, architecture should map to design outputs, and testing should map to design verification under 7.3.3, 7.3.4, and 7.3.6. Purchasing controls under ISO 13485 Clause 7.4 also require manufacturers to include cybersecurity requirements when sourcing third-party components and to verify those components through scanning or testing [2].
For premarket submissions, the FDA expects a complete Software Bill of Materials (SBOM). Every third-party component should be named, versioned, and listed with its current vulnerability status. Use VEX or similar evidence to show whether a known vulnerability is exploitable in the device context [7]. Postmarket plans should spell out monitoring sources, set triage SLAs, and publish a CVD URL, including on the device label [7].
FDA deficiency letters are putting more attention on gaps in SBOMs, VEX, and coordinated disclosure processes.
That matters for a simple reason: a flaw in third-party software can turn into a safety risk.
Security as part of device safety and effectiveness
"Ensuring device safety and effectiveness includes adequate device cybersecurity, as well as its security as part of the larger system." - FDA Guidance, February 2026 [5]
The agency reviews devices against five core security objectives: authenticity, including integrity, authorization, availability, confidentiality, and secure, timely updatability [5]. If a third-party component has a vulnerability, that issue can become a foreseeable safety hazard when it affects device function, data integrity, or access to care.
Events like WannaCry and URGENT/11 make this pretty clear. Third-party operating system and network stack vulnerabilities can spread into clinical disruptions across hospital networks [2]. Under Section 524B of the FD&C Act, failure to meet cybersecurity requirements for a cyber device is a prohibited act [5]. That applies to devices that include software, connect through Bluetooth, USB, Wi‑Fi, or similar interfaces, and contain characteristics that could be vulnerable to cybersecurity threats.
SBOM Transparency and Third-Party Vulnerability Disclosure Requirements
SBOMs make this safety requirement auditable. For the FDA, SBOM transparency is a requirement, not just a best practice [6][8].
What FDA expects in an SBOM for third-party components
Under Section 524B of the FD&C Act, makers of cyber devices must provide an SBOM that covers all commercial, open-source, and off-the-shelf components [6][8]. The FDA uses the NTIA minimum elements as the starting point: supplier name, component name, version, unique identifiers, dependency relationships, SBOM author, and a timestamp [3].
| SBOM Category | Required Elements |
|---|---|
| Component Identification | Name, version, supplier, unique identifier (CPE, PURL, or SWID) |
| Relationships | Direct dependencies, transitive (upstream) dependencies, integration points |
| Lifecycle & Security | Support status, end-of-life date, known vulnerabilities (CVEs), available security updates |
| Metadata | SBOM author, timestamp of generation |
Current FDA guidance also expects SBOMs to spell out third-party SDKs and OS-level components instead of leaving them buried as hidden dependencies [4]. If one library relies on another library with a known flaw, that upstream dependency needs to show up. The FDA accepts machine-readable formats such as SPDX, CycloneDX, and SWID tags [3].
Known vulnerabilities and external vulnerability sources
A component list alone isn't enough. Makers are also expected to monitor trusted public sources like the CVE database, the National Vulnerability Database, and the CISA Known Exploited Vulnerabilities catalog [1][3].
Where available, VEX statements can help recipients figure out whether a known vulnerability is actually reachable in the device's specific implementation. A useful disclosure should say whether a CVE is reachable in the product as deployed.
How HDOs can put SBOM and disclosure data to work
For healthcare delivery organizations, SBOMs only matter if there's a repeatable process to collect them, review them, and act on what they show. Right now, 44% of healthcare organizations say they run devices with known, unpatched vulnerabilities, and 28% run devices past their end-of-support date [1]. That’s what it looks like when SBOM data sits still instead of feeding an active risk workflow.
HDOs should ask for machine-readable SBOMs such as SPDX or CycloneDX during procurement and check component lists against the CISA KEV catalog on a regular schedule [1][3]. From there, they can use CVSS v4.0 Safety Impact metrics to sort vulnerabilities that may affect patient safety [1].
When patches aren't available, SBOM data helps teams spot where compensating controls like network segmentation are needed [1]. In plain terms, the SBOM can't live in a folder no one opens. It needs to feed procurement checks, KEV review, vulnerability triage, patching, and compensating controls after release.
SBOM disclosure only helps if manufacturers keep monitoring and triaging vulnerabilities after release.
Monitoring, Coordinated Disclosure, and Risk Assessment for Third-Party Vulnerabilities
FDA-Aligned Practices vs. Common Industry Gaps in Medical Device Cybersecurity
Once the SBOM is in place, the work doesn't stop. Manufacturers need to track third-party components across the full device life cycle. The FDA makes it clear that this monitoring must be continuous, not something done only during the submission window [1][6]. In practice, that means the SBOM is a live monitoring tool, not just paperwork for a filing.
Postmarket monitoring and coordinated vulnerability disclosure
Under Section 524B, manufacturers need a documented postmarket plan to monitor, identify, and address vulnerabilities within a documented timeframe [1][6]. That plan should sit with a PSIRT that can triage reports, score severity, and map findings back to the SBOM [1].
The FDA expects a two-tier patching model:
- A regular patch cycle for lower-risk vulnerabilities
- Out-of-cycle updates for critical vulnerabilities that create uncontrolled medical device security risks [6]
If a vulnerability hits a shared third-party component used by multiple manufacturers, coordination should go through CISA using the Traffic Light Protocol (TLP) [1].
The standard timeline for coordinated disclosure is 90 days. The manufacturer should acknowledge the report within five days, reproduce the issue and plan remediation by day 15, develop and test the fix by day 45, and publish the advisory with a deployed fix by day 90 [1]. The FDA also expects a public security contact and a 48-hour acknowledgment SLA [1].
Things get harder when a supplier stops shipping patches. At that point, the manufacturer has to put compensating controls in place, plan a move to another component, or document a technical justification for the remaining risk [2][8]. Under the FDA's Total Product Lifecycle (TPLC) framework, that inherited risk still belongs to the manufacturer [1][6].
Threat modeling and supplier risk analysis for third-party code
FDA-aligned threat models need to cover third-party libraries, SDKs, cloud services, and communication interfaces - plus the dependency chains tied to them [2]. That scope matters because it defines which supplier advisories could affect device safety. Modern medical devices often include 80% or more third-party code [3], so if transitive dependencies are ignored, most of the attack surface stays unchecked.
The FDA also treats devices with USB, serial, Bluetooth, or similar interfaces as connectable unless the manufacturer can prove otherwise [6]. That pulls more components and more interactions into scope.
Under the QMSR, which takes effect on February 2, 2026, cybersecurity threat models and remediation work should trace back to ISO 13485 design controls under Clause 7.3 and CAPA processes under Clause 8.5 [1][2]. Risk assessments should treat vulnerable third-party components as hazard sources inside ISO 14971 analysis, right alongside clinical safety risks [2].
Some teams make this easier by tiering suppliers into Critical, High, Medium, and Low groups based on access to patient data or device control [2]. It's a simple way to decide where tighter oversight is needed first.
FDA-aligned practices vs. common gaps: a comparison
The problem usually isn't policy. It's execution.
| FDA-Aligned Practice | Common Industry Gap |
|---|---|
| Complete, machine-readable SBOM (SPDX/CycloneDX) updated at every change, including transitive dependencies [2][3] | Only direct dependencies tracked; nested libraries left unmonitored [2] |
| Continuous automated monitoring of supplier advisories and the CISA KEV catalog [1][2] | Reactive response only after a major public exploit occurs [2] |
| Formal PSIRT with public security contact and a 48-hour acknowledgment SLA [1] | No dedicated security contact; inconsistent or slow response to researchers [1] |
| Documented CVD process with a structured 90-day timeline and customer communication [1] | Inconsistent or non-existent disclosure communication to customers [1] |
| Active supplier oversight with contractual patch obligations and audit rights [2] | Passive reliance on suppliers to provide fixes without formal agreements [2] |
| Threat models include third-party libraries, dependency chains, and cloud services [2] | Threat models limited to proprietary code only [2] |
| Cyber risks managed through CAPA and ISO 13485 purchasing controls [2] | Security handled by IT/Engineering without linkage to the QMS [2] |
These gaps show where manufacturers still need stronger design controls, supplier oversight, and patch workflows. They also make it clear where manufacturers and HDOs need to tighten day-to-day operations next.
Practical Steps for Manufacturers and Healthcare Organizations
What manufacturers need to change in design, supplier, and patch management
These requirements need to show up in everyday design, supplier, and patch work. Manufacturers should treat cybersecurity as a quality-system control, not as a side task for engineering. That means building third-party risk controls into design inputs, supplier qualification, verification, and CAPA.
They also need to submit curated SBOMs that map direct and transitive dependencies, versions, and known vulnerabilities. Use VEX to show which listed vulnerabilities are actually exploitable in the device’s deployed configuration. If a component can’t be patched, spell out the compensating controls and the technical reason the remaining risk is still acceptable.
But paperwork alone doesn’t do much. Buyers need a way to check these controls during procurement.
What healthcare organizations should ask vendors now
For healthcare organizations, these same disclosure requirements should become procurement checkpoints. Before or during procurement, ask vendors for evidence in a few core areas:
| Evidence Category | What to Ask For |
|---|---|
| SBOM | Machine-readable file (CycloneDX or SPDX), direct and transitive dependencies included, quarterly update schedule [3][9] |
| Disclosure policy | Public CVD policy, safe harbor language for researchers, 90-day standard timeline [1] |
| Postmarket support | Vulnerability management plan, patch deployment records, device lifetime support commitment [9] |
| Escalation paths | Named critical-vulnerability contacts, 48-hour acknowledgment SLA, escalation path for clinical impact [1] |
For devices already in use, ask a direct question: are any components past their end-of-support date? Supplier support commitments aren’t just a box to check during procurement. They tie straight to patient safety.
It also helps to treat SBOMs, VEX statements, and support timelines as inputs for risk assessment. They should feed triage and escalation workflows, not sit in a folder untouched.
Once these controls are written into contracts and daily workflows, the job becomes steady follow-through.
Conclusion: Core takeaways for FDA-aligned third-party software protocols
Disclosure protocols work only when manufacturers curate the data and HDOs put that data to use. For manufacturers, that means curated SBOMs with transitive dependencies, formal PSIRTs with public intake channels, and threat models that reach third-party libraries. For HDOs, that means asking for VEX with SBOMs, checking support lifetimes, and putting escalation paths into contracts before a critical vulnerability appears.
Censinet RiskOps™ can support structured vendor risk workflows that connect SBOM data, disclosure timelines, and third-party risk assessments. The FDA’s expectations are clear. The gap is execution.
FAQs
What counts as third-party software?
Third-party software refers to external code or software components built into a medical device that the manufacturer usually doesn't fully control across the software life cycle.
It often includes:
- commercial software
- open-source components
- off-the-shelf software
The FDA also treats Software of Unknown Provenance (SOUP) as a subset of third-party software.
How is a VEX different from an SBOM?
An SBOM is a detailed inventory of the software parts inside a medical device. That includes third-party code, commercial software, and open-source packages.
A VEX is a companion document that explains whether a given vulnerability listed against something in the SBOM can actually be exploited in the device’s setup. Put simply, the SBOM shows the components and possible risks, while the VEX adds the risk context.
What should hospitals ask vendors for now?
Hospitals should ask vendors for a machine-readable SBOM for every device in SPDX or CycloneDX format.
They should also ask for the vendor’s vulnerability disclosure policy, including CVE history and average patch time. On top of that, contracts should require timely notice of any critical vulnerabilities in software components, ideally within 24 hours.
