On this page
Published: · Updated:
Key Takeaways
- Section 524B places the SBOM obligation on the device manufacturer, not on component suppliers.
- Supplier SBOM delivery is enforced through purchasing controls and contract terms under 21 CFR 820.10 and ISO 13485:2016 clause 7.4, not by regulation on the supplier.
- Document supplier gaps and mitigation evidence; documentation does not guarantee acceptance or replace the statutory SBOM obligation.
- Contract language should require SBOM at delivery, on every update, plus vulnerability notification and end-of-support commitments.
- Binary analysis is a legitimate fallback when a supplier will not provide component data for a delivered binary.
Who is responsible for supplier SBOMs?
You are. Section 524B of the FD&C Act places the SBOM obligation on the manufacturer of the cyber device, and the FDA holds that manufacturer accountable for the completeness of the submitted SBOM including third-party and off-the-shelf components. Suppliers have no direct FDA obligation to produce an SBOM for you. The mechanism you have is your own purchasing controls and contract terms, and, where a supplier will not cooperate, efforts to obtain the data, documented limitations, and mitigation evidence; these do not exempt you from the SBOM requirement.
This is the question that stalls SBOM programs. A team assembles a clean inventory of its own code, then discovers that a delivered binary from a component vendor accounts for a third of the device's software and the vendor will not share what is inside it. The instinct is to treat that as the supplier's problem. The FDA does not.
Why this matters
Section 524B(b)(3) requires the manufacturer of a cyber device to provide a software bill of materials including commercial, open-source, and off-the-shelf software components. The statutory duty runs to the submitter. The February 3, 2026 final premarket cybersecurity guidance reinforces this by expecting the SBOM to cover the full software composition of the device rather than only the portions the manufacturer wrote.
The quality-system side matters just as much. Under 21 CFR 820.10 and ISO 13485:2016 clause 7.4 purchasing controls, you are already required to establish requirements for suppliers and to evaluate their ability to meet them. Software component transparency is a supplier requirement like any other. Assess whether supplier controls adequately address software transparency risks; the regulation does not expressly require an SBOM clause in every supplier agreement.
Who owes what
| Party | Obligation | Enforced by |
|---|---|---|
| Device manufacturer | Complete SBOM for the device submitted to the FDA | Section 524B, premarket review |
| Component supplier | Deliver component data per contract | Your purchasing controls and supplier agreement |
| Open-source project | None | Nothing; you enumerate from package metadata |
| Contract manufacturer | Deliver SBOM for software they build or integrate | Quality agreement and supplier controls |
| Cloud provider | Shared-responsibility boundary documentation | Service terms; assess device-system scope and document any inventory boundary |
A supplier's refusal to provide component data does not create an exemption. Document the limitation and address the unmet SBOM obligation; documentation alone is not a substitute.
What to put in supplier contracts
If you are writing or renegotiating supplier terms, the SBOM clause should cover more than a one-time delivery:
- SBOM at delivery. Machine-readable CycloneDX or SPDX, meeting the CISA minimum elements published July 29, 2026, for every delivered software version.
- SBOM on every update. Including patches, not just major releases.
- Transitive coverage. The supplier's own dependencies, not just their top-level components.
- Unique identifiers. PURL or CPE per component so you can correlate to vulnerability data.
- Vulnerability notification. A committed window for notifying you of newly discovered vulnerabilities affecting delivered components.
- End-of-support commitments. Declared support horizon per component and advance notice before end of support.
- Coordinated disclosure cooperation. A named contact and a commitment to participate when a researcher reports something affecting your device.
- Audit or evidence rights. The ability to verify the SBOM's accuracy, or to accept an attestation with defined scope.
When a supplier will not provide an SBOM
This happens most often with legacy commercial components, small vendors with no SBOM tooling, and hardware suppliers shipping firmware blobs. The path forward has three parts.
Enumerate what you can. Binary composition analysis on a delivered artifact will identify many embedded open-source libraries and versions. It will not be perfect, and you should say so, but it is far better than an empty entry. Represent the supplier's component as a single entry with the sub-components you were able to identify and note the analysis method.
Document the gap explicitly. In the SBOM discussion, name the component, name the supplier, state what you requested, state what you received, and state the method you used to fill the gap. Documenting the method helps explain limitations but does not establish that an incomplete SBOM satisfies Section 524B.
Show the mitigation. Compensating controls for a component you cannot fully inventory: network segmentation, input constraints, monitoring at the boundary, and a risk-assessment entry that treats the opacity itself as a risk factor. Pair it with a supplier-evaluation record in the QMS and a plan for either obtaining the data or replacing the component.
Submission gaps to address
- Third-party components represented as a single opaque entry with no attempt at decomposition and no explanation.
- An SBOM that covers only first-party code, with supplier components absent entirely.
- A statement that the supplier is responsible for their own SBOM, offered as a reason for the omission.
- Supplier components present but with no vulnerability analysis, because the manufacturer treated them as out of scope.
- No purchasing-control evidence that SBOM delivery was ever requested.
How Blue Goat approaches this
We separate the inventory problem from the contract problem, because they move on different timelines. On the inventory side, we run composition analysis against delivered binaries and firmware images so the SBOM reflects what actually ships rather than only what your team compiled, and we write the gap documentation with a clear structure: component, supplier, request made, data received, method used, residual risk, mitigation. On the contract side, we give your supplier-management team clause language that makes SBOM delivery, update cadence, vulnerability notification, and end-of-support declarations a purchasing-control requirement, so the next generation of supplier agreements closes the gap structurally instead of one submission at a time.
FAQ
CTA
If a supplier component is the reason your SBOM is not submission-ready, we can decompose the delivered artifact, document inventory gaps and their mitigations, and give your team the contract language that prevents a repeat. Talk to a MedTech cybersecurity expert.
Related
- FDA SBOM Requirements for Medical Devices (pillar guide)
- What SBOM Format Does the FDA Require
- SBOM in a 510(k) Submission: Where It Goes
- Postmarket SBOM Maintenance
Free tools for this
- SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.
