Where the SBOM requirement comes from
Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act requires the sponsor of a cyber device premarket submission to "provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components." The text is at 21 U.S.C. 360n-2. It applies to any 510(k), PMA, PDP, De Novo, or HDE for a device that meets the cyber device definition. The Section 524B guide covers that definition and the other two obligations.
The statute says what to provide. FDA's premarket cybersecurity guidance, issued February 3, 2026, says what FDA recommends the SBOM contain and what should accompany it. Section V.A.4 covers third-party components and the SBOM. Section VII.C.3 ties the recommendations to the statutory requirement. Appendix 4 lists the SBOM inside the cybersecurity risk management report and marks it as recommended even for IDE submissions.
For devices with software that are not cyber devices, the guidance still recommends SBOM documentation to support FDA's assessment of cybersecurity risk. In practice a reviewer expects an SBOM from any device that contains third-party software.
What an SBOM is, in FDA's words
The guidance describes a robust SBOM as one that includes both the components the manufacturer wrote and the third-party components, including purchased or licensed software and open-source software, and the upstream dependencies those components need. It also says why: the SBOM lets the manufacturer and users identify which devices and systems are affected when a vulnerability is published in a component, during development when components are chosen and after the device is on the market.
Two consequences follow. First, the SBOM is a hierarchy, not a flat list. A component that pulls in its own dependencies should show them. Second, the SBOM is a living record. The guidance says the SBOM, or an equivalent capability, should be maintained as part of configuration management and regularly updated to reflect changes to the software in marketed devices, supporting the design and development files and the medical device file under ISO 13485 subclauses 7.3.10 and 4.2.3.
The minimum elements
FDA's guidance asks for a machine-readable SBOM consistent with the minimum elements, which it also calls baseline attributes, and points to the NTIA multistakeholder document Framing Software Component Transparency (second edition, October 2021) for them. FDA's FAQ points to the same document. Those baseline attributes come from the NTIA report The Minimum Elements for a Software Bill of Materials, published July 12, 2021, which defines three groups of elements.
Data fields
The seven data fields apply to every component:
| Data field | What it records |
|---|---|
| Supplier name | The entity that creates, defines, and identifies the component |
| Component name | The designation the original supplier assigned to the unit of software |
| Version of the component | The supplier's identifier for a change from a previous version |
| Other unique identifiers | Look-up keys for databases, such as CPE, package URL (purl), or SWID |
| Dependency relationship | That upstream component X is included in software Y |
| Author of SBOM data | The entity that created the SBOM data, which may differ from the software supplier |
| Timestamp | The date and time the SBOM data was assembled |
The NTIA report notes that other unique identifiers may not exist for every piece of software but should be used where they do. For a medical device this matters most for firmware and embedded libraries that have no package manager entry: the identifier field is where you put what a vulnerability database can match.
Automation support
The NTIA report says the SBOM must be conveyed across organizational boundaries in one of the interoperable machine-readable formats it names: SPDX, CycloneDX, or SWID tags. FDA's guidance repeats the requirement for machine readability and says industry-accepted formats are encouraged. A table in a PDF is not machine-readable. Submit the file, and include a human-readable rendering if you want the reviewer to read it without tooling.
Practices and processes
The third group covers how the SBOM is produced and shared: frequency of generation, depth of the dependency tree, known unknowns, distribution and delivery, access control, and accommodation of mistakes. In a submission these show up as statements: the SBOM is regenerated on each release build, it covers all transitive dependencies to the stated depth, the components whose subcomponents could not be enumerated are flagged, and the SBOM is delivered to customers through a stated channel.
Depth: how far down the tree
The NTIA report describes software as a hierarchical tree of components and subcomponents and says each component should have its own SBOM listing its components. Its Depth practice asked, as a floor, for top-level dependencies with the transitive ones to follow as tooling matured. FDA's guidance goes further in its description of a robust SBOM: it includes the upstream dependencies that proprietary, purchased, and open-source components require. The CISA 2026 document replaces Depth with Coverage, which adds horizontal breadth, meaning every shipped component, to vertical depth.
For a device, the test is whether a published vulnerability in a transitive dependency can be matched to the device by machine. A firmware SBOM that lists the TLS library but not the compression library it links will miss the advisory. Generate from the build graph, not from a hand-written list, and state the depth reached in the coverage statement.
What changed in 2026: the CISA minimum elements
On July 29, 2026, CISA, the NSA, the FBI, and international partners published 2026 Minimum Elements for a Software Bill of Materials. CISA's page states that the document updates and replaces the NTIA 2021 minimum elements and incorporates feedback from the 2025 public comment period.
FDA's February 2026 guidance predates it and still cites the NTIA document. Until FDA updates the guidance or the FAQ, the NTIA elements are what the reviewer's checklist names. The safe position is to meet the 2026 elements, which contain the 2021 fields under new names plus additions, so the file satisfies both.
The 2026 document's Appendix B summarizes the changes from 2021. The ones that affect a device SBOM:
- Renamed fields. Supplier Name becomes Component Producer. Author of SBOM Data becomes SBOM Author. Other Unique Identifiers becomes Component Identifiers, with at least one common software identifier expected.
- New data fields. Component Hash Value and Component Hash Algorithm, Component License, SBOM Author Signature, SBOM Data Format Name and Version, SBOM Generation Context (the lifecycle phase the SBOM was generated in), SBOM Tool Name and Version, and SBOM Version.
- Practices. Depth becomes Coverage, and now includes horizontal breadth as well as the vertical depth of the dependency tree. Known Unknowns becomes Explicitly Identifying Unknown Information, which separates what the author does not know from what the author withheld. Accommodation of Mistakes becomes Accommodation of Updates to SBOM Data. Access Control is folded into Distribution and Delivery.
- Formats. SWID tags are removed from the format list; the Automation Support element becomes Machine-Processable Data under practices.
Component hash and generation context are the two additions that change engineering practice. A hash of the executable artifact lets a reviewer or a customer confirm the SBOM describes the binary they hold. Generation context records whether the SBOM came from source, from the build, or from binary analysis, which is the same distinction FDA's guidance draws when it asks for software composition analysis of binary executables in Section V.C.
The two fields FDA adds
Section V.A.4(b) of the guidance asks that, beyond the minimum elements, the submission include for each component:
- The software level of support provided through monitoring and maintenance from the component's manufacturer, with the examples actively maintained, no longer maintained, and abandoned.
- The component's end-of-support date.
The guidance says these may be part of the SBOM or provided separately, for example in an addendum. Both formats have fields or properties that can carry them, and an addendum spreadsheet keyed by component identifier is also accepted. What is not accepted is their absence. In CyberMed's reviews of submission files, a support-status column with blanks is the most common SBOM gap, because the data has to come from the supplier or the project's own maintenance record rather than from a scanner.
FDA's Off-The-Shelf Software Use in Medical Devices guidance, issued August 11, 2023, is the companion document. The cybersecurity guidance says the SBOM is in addition to the OTS information that guidance describes for components over which the manufacturer cannot claim full lifecycle control. The cybersecurity guidance also asks that the submission include plans for how third-party components could be updated or replaced if support ends, and that manufacturers keep custodial control of source code through escrow or backups where licensing allows.
Vulnerability disposition at submission
The SBOM identifies components. The guidance then asks the manufacturer to identify all known vulnerabilities associated with the device and its software components, including those in CISA's Known Exploited Vulnerabilities Catalog, and to describe how the vulnerabilities were discovered, so FDA can judge whether the assessment methods were robust.
For each component with known vulnerabilities, the submission should provide:
- A safety and security risk assessment of each known vulnerability, including device and system impacts.
- The safety and security risk controls that address it. Where the controls are compensating controls, they should be described in detail.
Two positions in the guidance shape the disposition. Section V.A.2 says known vulnerabilities should be assessed as reasonably foreseeable risks, and vulnerabilities in the KEV catalog should be designed out, because they are already being exploited. Section V.C says that where remediation is deferred to a future release, the submission should contain the plan: which vulnerabilities the release will address, the timeline, whether fielded devices will receive it, and how long it takes to reach them.
A practical structure is a vulnerability disposition table keyed by component and CVE, with columns for how the vulnerability was found, whether the vulnerable code path is reachable in the device, the exploitability assessment, the control, and the status. CISA's minimum requirements for VEX define a machine-readable way to state "not affected" with a justification, and both CycloneDX and SPDX can carry VEX data. FDA's guidance does not name VEX, but a disposition table with the same fields is what the reviewer is reading for.
CycloneDX or SPDX
Both formats appear in the NTIA minimum elements and both remain in the CISA 2026 machine-processable data practice. The choice is operational.
| Question | CycloneDX | SPDX |
|---|---|---|
| Maintained by | OWASP Foundation | The Linux Foundation |
| Origin | Security use cases: dependency inventory and vulnerability exchange | License compliance, extended to security |
| Vulnerability and VEX data | In the core specification | Supported through the security profile and external references |
| Support status and end-of-support | Component properties or external references | Annotations or external references |
| Typical native producers | Application build tools and package managers across common stacks | Compliance tooling and OS distributions, plus many build tools |
The decision rule CyberMed uses: pick the format your build pipeline emits without a conversion step, generate it at build time from the same inputs that produce the release image, and keep the format fixed across the product's life so successive SBOMs diff cleanly. Converting between the formats is possible, but every conversion is a place where a field goes missing. The post on SBOM generation by stack walks through the tooling for embedded C and C++, Rust, Node.js, Python, .NET, mobile, and container builds.
What to submit, and where it goes
The cybersecurity section of the eSTAR takes attachments. For the SBOM obligation, the file CyberMed prepares has four parts:
- The machine-readable SBOM for each software item that ships: the device firmware, the companion app, and any manufacturer-controlled cloud or update service that is part of the related systems. One SBOM per software item, each with its own dependency tree.
- A human-readable rendering of the same data with the support status and end-of-support columns, or a separate addendum keyed by component identifier.
- The vulnerability disposition described above, with the discovery method and the risk assessment for each entry, cross-referenced to the threat model and cybersecurity risk assessment by ID.
- A coverage statement that says how the SBOM was generated, from what inputs, to what depth, what was excluded and why, and which components have unknown subcomponents.
The book chapter on SBOM analysis for the eSTAR shows how this attaches to the rest of the file. CyberMed's FDA cybersecurity documentation service prepares all four parts as part of the cybersecurity risk management report.
Scope: what counts as a component
The statute names commercial, open-source, and off-the-shelf components. FDA's guidance adds the manufacturer's own components and upstream dependencies. The scope follows the software that runs in the device and its related systems. Firmware, real-time operating systems, cryptographic libraries, communication stacks, and vendor SDKs on the device side; the app, its SDKs, and its analytics or crash-reporting libraries on the mobile side; the runtime, frameworks, and base images on the cloud side. Development and test tooling that does not ship is out of scope for the submission SBOM, but the coverage statement should say so.
Modifications
For a device modification that needs a new submission, Section VII.D of the guidance says the SBOM requirement applies regardless of whether the change affects cybersecurity. A changes-unlikely-to-affect-cybersecurity submission still provides a current SBOM. Keeping the SBOM generated per release makes this a file attachment, not a project.
Maintaining the SBOM after clearance
The guidance treats the SBOM as a lifecycle record. Section V.A.4(a) says it should be maintained under configuration management and regularly updated to reflect changes to the software in marketed devices. Section VII.C.1 says the plan required by Section 524B(b)(1) should describe the sources, methods, and frequency for monitoring vulnerabilities, including third-party software manufacturers and the NIST National Vulnerability Database, and how KEV entries are identified and addressed. The SBOM is the inventory those sources are matched against.
Section V.A.6 asks the manufacturer to track and report three measures: the percentage of identified vulnerabilities that are patched, the time from identification to patch, and the time from patch availability to deployment in the field. None of the three can be computed without a current SBOM per fielded software version. The guidance's point about fielded devices applies here: if updates are not applied to every unit automatically, there are several software configurations in the field, and the SBOM set has to cover each one so vulnerabilities are assessed for every version in use.
The postmarket cybersecurity guidance defines controlled and uncontrolled risk and the reporting and remediation expectations that follow. The SBOM and the disposition table are what turn a published CVE into a controlled or uncontrolled decision within the timelines the 524B(b)(1) plan committed to.
Worked example: an SBOM package for a cloud-connected monitor
The example is illustrative. The device is a Class II bedside monitor with embedded Linux firmware, a Bluetooth Low Energy companion app for iOS and Android, and a manufacturer cloud service that receives telemetry and serves firmware updates.
Software items and SBOMs. Four SBOMs: firmware image, iOS app, Android app, cloud service image. Each is generated in the release pipeline from the build inputs, in CycloneDX, with the release tag, the build timestamp, and the tool name and version recorded. Each carries a hash of the artifact it describes.
Support status and end of support. The firmware SBOM lists the Linux kernel and distribution packages with the distribution's published support end dates; the BLE stack and TLS library with their maintainers' support statements; and two vendor SDKs whose support terms are in the supplier agreements, cited by document number. One legacy image codec is marked no longer maintained with an end-of-support date already past. It appears in the disposition table with a replacement planned for the next release and a compensating control (input validation on the only path that reaches it) for the current one.
Vulnerability disposition. A scan of the four SBOMs against the NVD and the KEV catalog at the submission build produces entries per component. Each entry states the discovery method (composition analysis of the SBOM plus binary analysis of the firmware image), reachability, exploitability, the control, and the status. Two KEV entries in an older TLS release were resolved by upgrading before submission, and the table records that. The remaining entries are not reachable in the device configuration, and the justification is stated in VEX terms.
Coverage statement. All shipped components to full dependency depth; build and test tooling excluded; one vendor SDK delivered as a binary with subcomponents not enumerable, flagged as unknown with the supplier's own SBOM attached.
Cross-references. Each component with a disposition entry appears in the threat model where its interface is modeled, and the cybersecurity risk assessment carries the same IDs, which is the traceability FDA's Appendix 2 asks for between the SBOM and the architecture views.
Common reviewer findings on SBOMs
These are the gaps CyberMed sees most often when reviewing an SBOM package before submission, stated against the guidance section each one misses. No frequencies are given, because CyberMed does not publish client data.
- PDF only. The guidance asks for a machine-readable SBOM. A table in the submission narrative is a rendering, not the deliverable.
- No support status or end-of-support dates. Section V.A.4(b) asks for both, for each component.
- Vulnerabilities listed without assessment. The guidance asks for a safety and security risk assessment and the controls for each known vulnerability, and for the discovery method.
- KEV entries carried as accepted risk. Section V.A.2 says KEV vulnerabilities should be designed out.
- Device-only scope. The related systems in Section 524B(b)(2) include the app, the cloud service, and the update server. Each needs an SBOM.
- No coverage statement. Without it the reviewer cannot tell whether a short SBOM is a small device or a shallow scan.
- Frozen at submission. The guidance expects the SBOM under configuration management and the 524B(b)(1) plan to describe how it is used for monitoring.
Where CyberMed fits
CyberMed prepares the SBOM package as part of the cybersecurity risk management report: the machine-readable files, the support and end-of-support addendum, the vulnerability disposition tied to the threat model, and the coverage statement. That is part of the FDA cybersecurity documentation service and of the 30-day Cybersprint, which also delivers the penetration test whose binary composition analysis confirms the SBOM matches the image.
If you already have an SBOM and want to know whether it is complete against the points above, the free FDA 524B readiness assessment takes three minutes and returns a gap report.