SBOM for Third-Party Chip Firmware in Medical Devices

Published June 11, 2026

Key Takeaways

• Most silicon-vendor "SBOMs" are release notes, not conformant SBOMs. Few meet the NTIA minimum elements out of the box.
• Section 524B(b)(3) holds the device manufacturer accountable for the SBOM — supplier silence is not a defense.
• A vendor SBOM only applies to the unmodified reference firmware. Any reflash, feature toggle, patch, or wrapper transfers SBOM authorship to the MedTech team.
• Binary composition analysis (BCA) is the FDA-accepted fallback when source-derived SBOMs are unavailable for third-party firmware blobs.
• VEX is the noise filter for chip firmware — most CVEs in a modem stack apply only to unused radio bands or disabled features.

Table of Contents

• Key Takeaways
• Why this matters
• When the chip vendor's SBOM is enough
• When the vendor SBOM is not enough
• What changes when you modify a cellular modem or radio chip
• Binary composition analysis as the fallback
• What the FDA evidence package looks like
• How Blue Goat Cyber handles third-party chip firmware
• FAQ

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.

Reviewers have started writing deficiencies that name this gap directly: "The submitted SBOM does not appear to include the firmware of the cellular communications module. Provide the firmware SBOM and the associated vulnerability assessment." That deficiency is increasingly common 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.

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:

• The file is machine-readable in CycloneDX 1.5+ JSON or SPDX 2.3+ — not a PDF release note or vendor portal table.
• It carries the NTIA minimum elements: supplier, component name, version, unique identifier, dependency relationship, author, timestamp.
• 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

This is where the responsibility line moves. The FDA's definition of "manufacturer" for SBOM purposes follows the build artifact. If your team performs any of the following, you become the SBOM author for that firmware:

• 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: a MedTech innovator using a Quectel BG95 module to provide 4G connectivity for a remote patient-monitoring device. Out of the box, the Quectel firmware ships with GSM, WCDMA, GNSS, and LTE-M support. The team disables GSM and WCDMA to reduce attack surface and applies a Quectel-supplied hotfix for a TLS issue. The shipping firmware is now neither the published Quectel reference nor an unmodified hotfix release. The Quectel SBOM (if one exists) describes neither of those configurations. The MedTech team is now the author of that derived firmware image for Section 524B purposes, and they owe the FDA an SBOM that reflects what actually ships.

Binary composition analysis as the fallback

When source-based SBOM generation is impossible — because the firmware is a vendor binary blob you do not have source for — the FDA-accepted fallback is binary composition analysis (BCA). BCA tools unpack the firmware image, identify embedded components by signature, version, and dependency, and emit a CycloneDX or SPDX SBOM.

The tooling landscape for medical device firmware:

See also: SBOM End-of-Support, EOL, and Level of Support, Docker Containers in Medical Devices: What the FDA Expects You to Test, and Secure Update Infrastructure for Medical Devices: A Safety-Critical Subsystem.

Tool	Type	Strongest for
binwalk + cve-bin-tool	Open source	Initial decomposition + CVE matching of common OSS libs
Syft on extracted root filesystems	Open source	Embedded Linux modems (Yocto, Buildroot-based)
Finite State, NetRise, CyberSwarm	Commercial	Full firmware BCA, VEX automation, MedTech-tuned matchers
ONEKEY, JFrog Xray firmware mode	Commercial	Compliance reporting, supply-chain attestation

A BCA-generated SBOM is not as authoritative as a build-time SBOM, and the FDA knows that. Document the methodology, the tool and version used, the unidentified-byte percentage, and any components flagged with low confidence. Reviewers accept BCA output when the methodology is transparent.

What the FDA evidence package looks like

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.0 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 the FDA expects.

If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our FDA-compliant SBOM services and the SBOM pillar guide.

FAQ

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

No. Section 524B(b)(3) and the February 2026 guidance require the SBOM to be machine-readable in a widely-supported format. CycloneDX 1.5+ JSON and SPDX 2.3+ are the accepted formats. A PDF or HTML release note may be useful as an input but is not an SBOM and will be cited as a deficiency if submitted as one.

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. CISSP, ex-military red team. Has built SBOMs for more than 250 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
• Patch and Update Mechanism Testing for Section 524B(b)(1)
• eSTAR v7.0 Cybersecurity Attachments mapping