If a medical device uses outside software, the manufacturer still owns the risk. That is FDA’s position in plain terms.
I’d sum up the article like this:
- Third-party software counts if it affects safety, device function, or cybersecurity
- Manufacturers must track it with records, risk reviews, validation, and an SBOM
- FDA expects action before and after release, including known-vulnerability review, patching, supplier oversight, and disclosure
- Healthcare buyers should ask for proof, not promises - especially SBOMs, patch timelines, and support dates
The article ties this to patient harm and delay in care. It points to 8,665 known vulnerabilities found in third-party libraries across four pacemaker programmers. It also cites hospital cyber incident data where 53% of affected hospitals reported higher mortality and 37% reported worse patient conditions. Put simply: missing software visibility can turn into care risk.
What matters most to me is this: an SBOM is not just a file for compliance. It is the device software inventory that supports vulnerability checks, patch decisions, supplier follow-up, and release records. FDA’s 2026 guidance also pushes for a machine-readable SBOM for cyber devices under Section 524B.
For healthcare teams, the buying signal is clear. If a vendor cannot show:
- what software is in the device
- which versions are in use
- when support ends
- how flaws are reviewed and fixed
that is a procurement risk.
A few numbers make the point fast:
- 661 distinct vulnerabilities were found in devices already in use in one study
- More than half were critical or high severity
- The average time from purchase to vulnerability disclosure was about 3.2 years
- 35% of medical device purchasing decision-makers will not consider a device without an SBOM
So the main takeaway is simple: FDA expects third-party software to be documented, tested, watched, patched, and tied to supplier controls across the full device life. And buyers should treat that evidence as part of vendor review from day one.
Medical Device Third-Party Software Risk: Key FDA Stats & Procurement Facts
FDA Scope: Software Documentation, Cybersecurity, and Lifecycle Obligations
Once FDA defines third-party software, the next step is simple: manufacturers have to document it and keep it under control. FDA does not treat cybersecurity like a side task. It treats it as part of the quality system itself. That means cybersecurity records need to sit inside the same design-control process used for software validation and risk management.[15][2]
If software affects safety, effectiveness, performance, or cybersecurity, FDA expects it to fall under design controls in 21 CFR 820.30. That includes things like architecture records, risk analysis, and verification and validation.[16]
And there’s no carveout for outside code. Third-party software is still the manufacturer’s responsibility. FDA applies the same risk-based controls to software built in-house and to third-party components brought into the device.[2][3]
Premarket Expectations for Software Components and Known Vulnerabilities
Before a device reaches the market, FDA expects manufacturers to do more than list software components. They need to document those components, review how dependencies affect the system and its architecture, and disclose known vulnerabilities, support status, and end-of-support dates.[3][10]
The risk assessment has to show the thinking behind the decision. In plain English, FDA wants to see:
- how each vulnerability was reviewed for exploitability and clinical impact
- what mitigations are already in place
- whether the remaining risk is acceptable[3][7]
FDA also expects threat modeling based on how the device will actually be deployed, not just how it looks on paper.[2][14]
Why does this matter so much? A research study of medical devices purchased by national health services found 661 distinct vulnerabilities in devices already in use. More than half were rated critical or high severity. Even if patching happened right away, the average window between device purchase and vulnerability disclosure was about 3.2 years.[17] That’s a long time for risk to sit in the background. Premarket documentation is supposed to bring those issues into view before the device ships. It also sets the starting point for post-clearance monitoring.
Postmarket Duties for Monitoring, Patching, and Coordinated Disclosure
FDA expects that same level of discipline after launch. Cybersecurity work doesn’t stop once the device is on the market. Manufacturers are expected to keep active risk management in place, with continuous monitoring of vulnerability feeds, supplier advisories, and end-of-support notices linked to SBOM entries.[5][11][3]
When a vulnerability shows up, FDA expects manufacturers to:
- assess the impact
- rank the fix by urgency
- deploy patches or other controls
- verify that the response actually worked[5][11]
FDA also expects set remediation timelines. For some vulnerability classes, that often falls in the 30- to 60-day range.[11][12] If a patch might affect clinical performance, or if a legacy device can’t be fully fixed, the manufacturer needs records that explain the decision.
There’s another piece here too: disclosure. FDA expects manufacturers to keep a coordinated vulnerability disclosure policy with a clear reporting channel for researchers and customers. That policy should also include set timelines for assessment and communication back to healthcare organizations.[5][13] And when the issue involves third-party components, the coordination has to include the supplier as well.
sbb-itb-535baee
Inventory, SBOM, and Supplier Controls for Third-Party Software
Tracking vulnerabilities and patch windows only works if you know exactly what software is in the device. That’s why the software inventory and SBOM sit at the center of this work.
Building a Complete Software Inventory and SBOM
FDA's 2026 final cybersecurity guidance requires a machine-readable SBOM for cyber devices under Section 524B(b)(3) of the FD&C Act, and strongly recommends it for all other software-containing devices.[2][23][24] A strong SBOM should include manufacturer-built software and all third-party components, including purchased and licensed software, open-source software, and upstream dependencies. It also needs to be regenerated and version-controlled for each release.
In practice, the SBOM should act as the main release inventory for vulnerability monitoring. If a new issue shows up in a library, package, or embedded module, this is the record you check first. It also gives you the baseline for supplier oversight and release-by-release validation.
For each component, manufacturers should record:
- name
- version
- supplier
- unique identifier or hash
- dependency relationships
- level of support
- end-of-support date
- known vulnerabilities [6][22][23]
This applies across the stack: operating systems, libraries, firmware, middleware, and embedded components. The amount of documentation can scale with enterprise risk, but every component still needs version, supplier, support, and vulnerability data.
SBOM generation also needs validation. Tool output can miss relationships, versions, and suppliers, so it can’t be treated as correct by default.[18][25]
Supplier Oversight Across the Software Lifecycle
FDA expects manufacturers to manage third-party software suppliers inside their quality management system, with supplier evaluation, qualification, and continued oversight based on the risk tied to the component.[2][4][1]
For high-criticality components - such as operating systems, networking stacks, cryptographic libraries, and safety-related modules - manufacturers should carry out a formal review of the vendor’s secure development practices, vulnerability disclosure process, and incident response capabilities.[2][5][1] Contracts should also spell out expectations for timely vulnerability notification, end-of-support notice periods, and updated SBOM data.[7][4][3]
If source access isn’t available, there are still ways to cut exposure. Manufacturers can require detailed SBOMs, use binary analysis and penetration testing, and document contingency plans that explain how to isolate, compensate for, or replace a component if supplier support weakens.[2][5] For critical components, backup source access can serve as a fallback if a vendor becomes unable or unwilling to support the product.[19]
Third-Party Software Risk from Selection to End-of-Support
Third-party software risk starts long before deployment. It begins when a component is first being considered. That means risk management should run from selection through end-of-support: vet suppliers, map dependencies, validate in deployment, baseline approved versions, monitor over time, revalidate after every change, and retire unsupported components.[2][5][20]
The Philips Vue advisory shows why this matters. Fifteen vulnerabilities affected both product software and third-party components such as Redis, 7-Zip, Oracle Database, jQuery, Python, and Tomcat.[21] That lifecycle record then feeds validation and submission evidence.
Validation, Security Controls, and Evidence for FDA Submissions
An inventory is the starting point, not the finish line. FDA also wants proof that the components listed in the SBOM were validated and kept under control. The SBOM shows what sits inside the device. This section is about showing why those parts are fit for release.
The key point is simple: FDA is not focused on whether software came from a third party. It cares about whether the manufacturer can show that the software is safe, secure, and supportable. That means proving those components were validated, tested, and secured for the device’s intended use.
Validation and Risk Assessment for Third-Party Components
FDA expects objective evidence that each third-party component meets intended use, safety, and security requirements, not just code built in-house. That applies to an operating system, library, framework, or external service. Each one should connect to a hazard analysis that identifies possible failure modes and patient safety effects.
When a known vulnerability cannot be patched right away, the file should spell out the CVE, affected versions, severity, how likely the vulnerability is to be exploited in this device, patient impact, and any compensating controls. FDA expects a clear risk rationale, not a short note saying the issue was accepted.[4][26][27]
That risk analysis then drives which security controls need verification in testing.
Cybersecurity Control Areas FDA Expects Manufacturers to Address
FDA expects manufacturers to address eight control areas: authentication, authorization, cryptography, code/data integrity, confidentiality, logging, resiliency and recovery, and patchability.[12][8]
These controls matter for a plain reason. If third-party code fails, it can interrupt therapy, suppress alarms, or block recovery.
Vendor defaults alone do not meet these expectations. A third-party OS, for example, needs documented hardening configuration, fault-condition testing, and proof that logging captures security-relevant events. For cryptographic libraries, document the algorithms in use and the validation status of the module. For networked components, validate authentication flows, encryption in transit, and failover behavior during connectivity loss.
Premarket vs. Postmarket Evidence: What FDA Expects at Each Stage
FDA wants different proof before clearance and after release. The table below separates those evidence types.
| Evidence Area | Premarket | Postmarket |
|---|---|---|
| Testing records | Validation protocols and summarized results covering third-party integration, security, and fault conditions | Regression test results for each patch or update applied post-release |
| Monitoring and logging | Design documentation and test evidence showing security events are captured and protected | Operational log review procedures and incident records showing third-party telemetry in use |
| Update evidence | Secure update architecture, patch assessment criteria, and rollback mechanisms | Patch deployment records, release notes, and version control logs showing what each fielded device is running |
Premarket submissions that miss required cybersecurity and SBOM information risk refusal to accept.[27]
A clean way to package this is as a separate submission dossier that includes:
- SBOM
- Risk analysis
- Validation summary
- Control-to-test traceability
What This Means for Healthcare Organizations
FDA guidance turns third-party software evidence into a buying decision, not just a device maker’s compliance task. Put plainly: if a vendor can’t show what software sits inside a device, how that software is maintained, and how security flaws are handled, the healthcare organization ends up carrying risk it didn’t need to take on.
For healthcare teams, the practical test is straightforward: can this evidence help screen vendors, handle renewals, and track fixes over time?
What Healthcare Organizations Should Request from Device Vendors
Third-party software transparency should be part of the purchase requirement, not something you chase after the sale.
Healthcare organizations should ask vendors for:
- A current, machine-readable SBOM in SPDX or CycloneDX format that lists all components, versions, CVE mappings, and support and end-of-support dates
- The vendor’s patching policy, including severity-based timelines, secure update methods, supplier oversight records such as risk reviews, change-control records, periodic component reviews, and a coordinated vulnerability disclosure process with a clear contact path
If a vendor can’t provide these materials, that should be treated as a procurement risk and a renewal risk.
Industry data backs this up: 35% of medical device purchasing decision-makers will not consider a device that does not come with an SBOM.[9]
Once you ask for these documents, a new problem shows up fast: collecting them, comparing them, and tracking them in a consistent way.
How Censinet Supports Medical Device and Third-Party Risk Oversight
Tracking SBOMs, questionnaires, and remediation commitments across a large vendor base gets messy fast without a standard workflow. Censinet RiskOps™ brings vendor questionnaires, SBOMs, and supporting documents into one place, then scores responses across security, privacy, and operational risk.
That gives clinical engineering, IT security, compliance, and supply chain teams one view of each vendor’s risk profile. And that view goes beyond a basic checklist. It includes exposure tied to third-party software, PHI, clinical applications, and supply-chain dependencies.
It also helps teams compare vendors side by side, including:
- SBOM quality
- Patch SLAs
- Vulnerability disclosure practices
Remediation commitments can then be tracked over time, which creates an auditable record of due diligence. That record can support procurement decisions and help when teams need to show regulatory defensibility.
With a process like that in place, procurement teams can turn vendor evidence into repeatable risk decisions.
Key Takeaways for Compliance and Risk Management
FDA’s message is direct: visibility into third-party software is now a core procurement requirement. The healthcare organizations in the best position for compliance are the ones that treat SBOM availability, structured supplier controls, and coordinated vulnerability disclosure as part of the buying process from day one, not as an afterthought.
Better vendor evidence helps with compliance, speeds incident response, and lowers patient risk.
FAQs
What counts as third-party software?
Third-party software is outside code built into a medical device that the manufacturer usually doesn't fully control across the software life cycle.
That can include commercial software, open-source code, and off-the-shelf software. It also covers firmware, SDKs, middleware, drivers, network stacks, and transitive dependencies.
The FDA also treats SOUP as a subset of third-party software.
Why is an SBOM so important?
A Software Bill of Materials (SBOM) is a machine-readable inventory of the software parts inside a medical device. That includes third-party, commercial, and open-source code.
Put simply, it shows what’s under the hood.
That visibility helps manufacturers and healthcare delivery organizations spot vulnerabilities, review patient safety risks, and support regulatory compliance.
An SBOM also tracks dependencies and lifecycle metadata. That makes it useful for proactive vulnerability management and continuous monitoring across a device’s 10- to 15-year life.
What should hospitals ask vendors for?
Hospitals should treat cybersecurity documents as a must-have part of procurement.
Ask vendors for:
- a machine-readable SBOM in SPDX or CycloneDX format, with both direct and transitive dependencies
- their CVD policy, CVE history, and average patch response times
- postmarket support details, EOS dates, and escalation contacts
Contracts should also require vendors to report critical vulnerabilities, ideally within 24 hours.
For devices already in use, check whether any components are past EOS.
