FDA SBOM requirements for medical devices: a Section 524B guide

FDA SBOM requirements became law with Section 524B of the FD&C Act (added by the 2023 omnibus): manufacturers of "cyber devices" must provide a software bill of materials covering commercial, open source, and off-the-shelf components in premarket submissions. Since October 2023, the FDA can refuse to accept submissions that lack it. For device makers, SBOMs moved from best practice to gating requirement.

This guide covers:

The legal basis and why FDA moved from guidance to requirement
What qualifies as a "cyber device" (it is broader than teams expect)
What the SBOM must contain and the guidance that shapes reviewer expectations
Maintaining SBOMs through the postmarket lifecycle
Mistakes that draw deficiency letters

Precision work under review

GIF via GIPHY

Related guides:

Key takeaways

Section 524B makes SBOMs mandatory in premarket submissions (510(k), PMA, De Novo) for cyber devices—refuse-to-accept applies.
A cyber device is any device with software that can connect to the internet—including via intermediary systems.
The SBOM must cover commercial, open source, and off-the-shelf components, with support and end-of-support levels addressed.
SBOM obligations continue postmarket: monitoring components for new vulnerabilities is part of the required cybersecurity plan.
SecureSlate helps device makers run the underlying security program the FDA expects the SBOM to reflect.

Why the FDA requires SBOMs

Medical devices run long lifecycles on software stacks that age badly—unsupported operating systems and abandoned libraries in devices that stay in clinical use for a decade. Recalls and advisories tied to third-party components (URGENT/11, Ripple20) made component opacity a patient-safety problem, not just an IT problem.

Section 524B(b)(3) responded directly: manufacturers must "provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components." FDA's 2023 premarket cybersecurity guidance (updated since) tells reviewers what a credible SBOM package looks like.

What counts as a cyber device

A device qualifies under 524B if it:

Includes software (validated, installed, or authorized by the sponsor), and
Can connect to the internet, and
Could be vulnerable to cybersecurity threats as a result

"Can connect" is interpreted broadly—Bluetooth to a phone app, USB update workflows via a networked workstation, or hospital network connectivity all typically qualify. If your device has software and any realistic connectivity path, plan on being in scope.

What the SBOM must contain

FDA guidance points to the NTIA minimum elements as the baseline, with device-specific additions:

Element	Expectation
Component name, version, supplier	Every commercial, open source, and OTS component
Unique identifiers and relationships	Machine-readable (SPDX or CycloneDX commonly used)
Level of support	Whether each component is actively supported by its supplier
End-of-support / end-of-life dates	Known or anticipated, per component
Vulnerability status	Known vulnerabilities in listed components, with risk assessment and controls

The support and EOL fields are the distinctly FDA twist—reviewers want evidence you can manage a component going unsupported mid-device-lifecycle.

SBOMs across the device lifecycle

Premarket: SBOM submitted with the marketing application; deficiencies here delay clearance
Postmarket: 524B requires processes to monitor, identify, and address vulnerabilities—your SBOM is the index those processes run against
Updates and patches: each software change regenerates the SBOM; FDA expects update mechanisms and timelines described in your cybersecurity plan
Customer requests: hospitals increasingly request device SBOMs during procurement; a consistent artifact serves both audiences

Building a compliant SBOM process

Automate generation from the build, including firmware and RTOS components binary scanners may miss—manual spreadsheets do not survive device revision cycles.
Enrich with support/EOL data for each component; this typically requires a maintained component registry, not just scanner output.
Run vulnerability monitoring continuously against the SBOM and feed findings into your postmarket surveillance process.
Version SBOMs per device software version and keep them retrievable for every version in clinical use.
Integrate with your QMS so SBOM updates trigger documented review, consistent with design control expectations.

Common submission mistakes

Top-level-only SBOMs that omit the dependency tree inside embedded Linux or RTOS stacks
Missing support/EOL analysis—the most common FDA-specific gap
SBOM inconsistent with the vulnerability assessment elsewhere in the submission
No postmarket maintenance story—an SBOM without a monitoring process behind it
Treating contract manufacturers' components as out of scope—the obligation is the sponsor's regardless of who wrote the code

Device cybersecurity programs with SecureSlate

SecureSlate helps device and health-tech companies run the security program behind the submission—policies, vulnerability management SLAs, vendor risk, and evidence—mapped across FDA expectations, ISO 27001, and SOC 2.

Get started for free · Free readiness score

FAQ: FDA SBOM requirements

Which submissions need an SBOM?

Premarket submissions for cyber devices—510(k), PMA, De Novo, and others. FDA has applied refuse-to-accept for missing cybersecurity documentation since October 2023.

Does the FDA require a specific SBOM format?

The guidance references machine-readable formats and NTIA elements rather than mandating one format. SPDX and CycloneDX are the common choices in practice.

Do legacy devices already on the market need SBOMs?

524B applies to new submissions, but postmarket vulnerability management expectations touch marketed devices, and hospital customers increasingly demand SBOMs for installed fleets regardless.

How do we handle components with no support information?

Document the analysis honestly—unknown support status with your compensating controls is more credible than silence, and aligns with the "known unknowns" principle.

Do software-only products (SaMD) count as cyber devices?

Software as a Medical Device typically meets the definition when it has any connectivity, so SBOM requirements generally apply.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.