SBOM for Third-Party Chip Firmware

Published June 11, 2026

Why this matters

The FDA's February 3, 2026 final premarket cybersecurity guidance restates the Section 524B(b)(3) requirement plainly: the SBOM submitted with a cyber device must include commercial, open-source, and off-the-shelf software components, including software embedded in third-party silicon. The agency does not distinguish between code your team wrote and firmware burned into a Quectel, u-blox, Nordic, Telit, or Qualcomm part. If it ships in the device, it belongs in the SBOM.

Deficiency letters we have seen raise this gap in language similar to this: "The submitted SBOM does not appear to include the firmware of the cellular communications module. Provide the firmware SBOM and the associated vulnerability assessment." We regularly see this deficiency on connected Class II devices using off-the-shelf 4G/5G or BLE modules, and it adds an Additional Information cycle to the review timeline.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Software Bill of Materials resources; FDA Cybersecurity resources for medical devices.

When the chip vendor's SBOM is enough

A vendor-supplied SBOM is acceptable as a drop-in component of your device SBOM when all of the following hold:

• Request a machine-readable SBOM in a supported standard format, such as CycloneDX or SPDX, and validate its schema. The versions listed here are examples, not exclusive FDA requirements.
• Check the full CISA 2026 minimum-elements guidance, including Component Hash, Component Hash Algorithm, Component License, SBOM Tool Name, and SBOM Generation Context, as well as updated existing elements, automation support, and practices and processes. These recommendations are distinct from the statutory SBOM requirement.
• Components have PURL and/or CPE identifiers so they can be matched against NVD, GHSA, and OSV.
• The SBOM version matches the exact firmware binary you flash and ship, same hash, same build ID.
• You receive updated SBOMs within your patch SLA whenever the vendor releases new firmware.

When all five conditions are met, you merge the vendor SBOM into your device SBOM, preserve the dependency relationship up to the chip module, and run the same vulnerability-management loop described in our SBOM Vulnerability Management guide.

When the vendor SBOM is not enough

In practice, most chip vendors fail at least two of those five conditions. The recurring gaps:

• No machine-readable file. A release note PDF listing "open-source components used" is not an SBOM. Reviewers reject it as such.
• Top-layer only. The vendor lists their RTOS and TCP/IP stack but not the TLS library, the PPP stack, the audio codec, or the proprietary blobs from the underlying silicon supplier (Qualcomm, MediaTek, etc.).
• Stale. The SBOM corresponds to a firmware release from 14 months ago; your latest flash is on a newer build.
• No identifiers. Components are named but carry no PURL, CPE, or hash, so CVE matching is manual and unreliable.
• Reference-image-only. The SBOM describes the vendor's reference firmware. The image you actually flash differs because of regional band configuration, feature toggles, or a vendor hotfix.

When any of these apply, the vendor SBOM is an input to your SBOM, not a substitute. You either get a conformant SBOM from the vendor (the right ask) or generate one yourself via binary composition analysis.

What changes when you modify a cellular modem or radio chip

The device manufacturer remains responsible for submission accuracy whether firmware is modified or not. Changes to firmware or configuration require assessment of the shipped inventory and vulnerability applicability; FDA does not define SBOM authorship by an automatic transfer at each change.

• Reflashing a modem with custom AT-command firmware or a different vendor SKU image.
• Enabling, disabling, or reconfiguring features, turning off unused radio bands, swapping the TCP/IP stack, changing TLS suites, disabling the audio path.
• Applying vendor hotfixes that have not been published as a new official firmware release.
• Layering custom code on programmable modems, Telit AppZone, Sequans Monarch GO, Nordic nRF SDK with custom application binaries, ESP32 with custom firmware.
• Statically linking vendor SDKs into your own firmware image with selective inclusion.

A practical example is a device using a Quectel BG95 variant for LTE-M or NB-IoT connectivity. Radio capabilities depend on the variant; BG95 does not support WCDMA. Document the exact model, firmware build, configuration, and any vendor hotfix. Reconcile the supplier SBOM with the shipped image and assess whether configuration changes affect vulnerability applicability; a configuration change does not automatically transfer SBOM authorship.

Binary composition analysis as the fallback

When source-derived information is unavailable, BCA can supplement supplier records by identifying some components in firmware binaries. It may miss stripped, encrypted, proprietary, or statically linked code and does not by itself establish SBOM completeness or FDA acceptability.

The tooling landscape for medical device firmware:

Document BCA methodology, tool and version, coverage limits, and uncertain identifications. Reconcile results with supplier and build information where available; transparent methodology alone does not guarantee FDA acceptance.

What the FDA evidence package looks like

See also: SBOM EOS, EOL, & LoS for FDA 524B, FDA PCCP Beyond AI: Cybersecurity & Firmware Uses, and FDA Section 524B Subsections Explained.

For each third-party chip whose firmware ships in the device, the submission should include:

• The chip module identified in the device SBOM as a top-level component with supplier, model, and firmware version.
• A nested SBOM for the chip firmware, either vendor-supplied (when conformant) or BCA-generated.
• The methodology note for how that nested SBOM was obtained, including tool, version, and date.
• The vulnerability assessment for the chip firmware components against NVD, KEV, GHSA, and OSV at submission date.
• VEX statements for CVEs that do not apply because of disabled features or unreachable code paths (e.g. GSM-only CVEs on a modem with GSM disabled).
• The patch path for the chip firmware, vendor cadence, your update mechanism, the SLA tying them together, traceable to your Patch and Update Mechanism evidence.

This evidence sits in eSTAR v7.1 Slot 5 (SBOM) with cross-references to Slot 6 (Controls) and Slot 1 (Cybersecurity Management Plan). See our eSTAR mapping guide for placement detail.

How Blue Goat Cyber handles third-party chip firmware

We treat every third-party chip as a separate SBOM workstream. We start by asking the vendor for a conformant CycloneDX or SPDX file, and if one is not available, we run binary composition analysis on the exact firmware image flashing to the device, validate the result against the vendor's published component list, and generate VEX statements for the unused features so reviewers are not buried in irrelevant CVEs. For modified firmware (band reconfiguration, feature toggles, custom AppZone code), we rebuild the SBOM from the modified binary, not the reference image. The deliverable plugs into the Slot 5 attachment with the traceability matrix FDA guidance recommends.

If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. See our medical device SBOM services for FDA premarket submissions and the SBOM pillar guide.

To keep your SBOM and vulnerability records current after clearance, GoatWatch matches components to new CVEs and tracks VEX decisions.

Related reading: SBOM for SaMD and Cloud Components: What the FDA Expects in 2026.

FAQ

Does the FDA accept the chip vendor's PDF release note as an SBOM?

No. Section 524B(b)(3) requires an SBOM; the February 2026 guidance recommends the SBOM to be machine-readable in a widely-supported format. CycloneDX and SPDX are examples of industry formats; the FDA specifies neither a format nor a version. A PDF or HTML release note may be useful as an input but is not an SBOM and may not provide the component inventory and machine-readable information recommended by the guidance.

What if the chip vendor refuses to provide an SBOM?

That does not relieve the device manufacturer of the obligation. The fallback is binary composition analysis on the firmware image, documented with the tool, version, and methodology. Document the supplier ask and refusal in the supply-chain risk file, repeated refusal is itself a supplier-risk signal.

Do I need an SBOM for a Bluetooth radio that has no internet path?

If the device meets the Section 524B definition of "cyber device", software validated by the sponsor and able to connect to the internet through any path, even indirect, then every software component including the BLE radio firmware belongs in the SBOM. The BLE stack is a frequent CVE surface (e.g. BleedingTooth, SweynTooth, BrakTooth) and reviewers ask for it explicitly.

How is this different from the main device SBOM?

It is part of the main device SBOM, not a separate document. Best practice is a single top-level CycloneDX or SPDX file with nested dependency relationships that name the chip module as a component and link to or embed its firmware SBOM. One file, multiple layers, not two parallel SBOMs.

What about programmable modems like Telit AppZone or Nordic nRF Connect SDK?

These are the clearest cases of SBOM authorship transfer. The manufacturer is building and signing the firmware image; the chip vendor merely supplied the SDK. Generate the SBOM from your build pipeline using cyclonedx-cli, syft, or language-native generators, and merge any vendor-supplied component SBOMs underneath.

Where do VEX statements fit for chip firmware?

VEX is essential here. A 4G modem firmware will surface dozens of CVEs that do not apply because the device disables GSM, never enables voice, or runs in a constrained data-only mode. Publishing VEX statements for those CVEs is what keeps the postmarket vulnerability bulletin readable for hospital biomed teams. See our VEX document guide.

Ready to close the chip-firmware SBOM gap?

If your submission relies on a third-party cellular, Wi-Fi, BLE, or SoC module and you do not yet have a machine-readable SBOM for the firmware image that actually ships, we will run the BCA, validate vendor inputs, and deliver the Slot 5 evidence package before your next submission window closes. Request a scoping call.

---

Christian Espinosa, Founder, Blue Goat Cyber., ex-military red team. Has built SBOMs for more than 275 FDA-submitted devices, including connected diagnostics with off-the-shelf 4G modems, programmable BLE implants, and Wi-Fi infusion pumps. More on the author.

Related reading

• SBOM for Medical Devices: 2026 FDA Pillar Guide
• SBOM Vulnerability Management for Medical Devices
• CycloneDX vs SPDX for Medical Devices
• VEX Documents for Medical Device FDA Submissions
• Medical Device SBOM: FDA Requirements & Submission Guide (2026)
• Patch and Update Mechanism Testing for Section 524B(b)(2)
• eSTAR v7.1 Cybersecurity Attachments mapping

---

More on this topic

• Docker Containers in Medical Devices: FDA
• Secure Update Infrastructure for Medical
• VxWorks Vulnerabilities in Medical Devices