On this page
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.50, not by regulation on the supplier.
- Reviewers accept documented gaps with mitigation evidence; they do not accept silent omissions.
- 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.
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, a documented gap with mitigation evidence.
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.50 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. If your supplier agreements are silent on SBOM delivery, that is a purchasing-controls gap, not just a cybersecurity one.
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; substrate is out of scope for enumeration |
A supplier's refusal to provide component data does not create an exemption. It creates a documentation obligation.
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 NTIA minimum elements, 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. Reviewers evaluate honesty and process. A named gap with a method attached reads as control. A missing component that a reviewer discovers by inspection reads as an incomplete inventory.
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.
What reviewers actually push back on
- 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 in the form reviewers expect: 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, write the gap documentation reviewers accept, and give your team the contract language that prevents a repeat. Talk to a MedTech cybersecurity expert.
