What does the FDA require in an SBOM for a cyber device?

A software bill of materials that inventories the components in the device, in a machine-readable form. The current premarket guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," was revised on 3 February 2026 to align with the Quality Management System Regulation. It expects the SBOM to carry, for each component, the supplier name, component name, version, unique identifiers and dependency relationships, along with the SBOM author and a timestamp, plus the support status and end-of-support date. Machine-readable in practice means SPDX or CycloneDX.

Which FDA guidance is current?

The 3 February 2026 revision. The premarket cybersecurity guidance has been through three finalized versions: 27 September 2023, then 27 June 2025, then 3 February 2026, each superseding the last. The February 2026 revision aligns terminology with the Quality Management System Regulation, which took effect on 2 February 2026 and incorporates ISO 13485:2016 into 21 CFR Part 820. If a vendor page or an internal SOP still cites the June 2025 version as operative, it is one revision behind.

What is the difference between an SBOM and an AIBOM?

An SBOM inventories software components: libraries, operating system, firmware, third-party dependencies, and the relationships between them. An AIBOM, or ML-BOM in the CycloneDX vocabulary, extends that idea to the parts of an AI system a software inventory has no vocabulary for: the model itself, its version, the datasets it was trained and evaluated on, and its lineage. They answer different questions. The SBOM tells you what code is in the device. The AIBOM tells you what model is in the device.

Does an SBOM cover the AI model in our device?

Not meaningfully. An SBOM will list the inference runtime, the numerical libraries and the operating system underneath the model, because those are software components with suppliers and versions. It has no field that captures which weights were loaded, what data they were trained on, or which evaluation they passed. For a conventional device that gap does not matter much, because the risk lives in the code. For an AI-enabled device a large part of the behavior lives in the weights, and a complete software inventory can still leave that part uninventoried.

If we have both, are we covered?

For inventory questions, largely. For evidentiary questions, no, and the distinction matters. An SBOM and an AIBOM are both inventories: statements about what a system is made of at a point in time. Neither is a record of what the system did. Asked months later which model version produced a specific output, or whether the record of that output has been altered since, neither document can answer, because neither was created at the moment of the decision. Inventory and provenance are different artifacts serving different questions.

Where do most SBOMs fall short in a submission?

Two places, in our reading of the guidance. The first is treating the SBOM as a one-time deliverable rather than a living document maintained alongside vulnerability management, which is how the guidance frames it. The second is component identity: without stable unique identifiers, a component in your inventory cannot be reliably matched to a vulnerability record later, which is most of what an SBOM is for. Both failures look fine at submission and surface when something needs to be traced.

Does RankShieldMD produce our SBOM?

No. SBOM generation is a build-pipeline function and there are established tools for it. RankShieldMD is not a medical device, does not render clinical decisions, and never sees PHI. What we produce is the layer neither bill of materials covers: a tamper-evident, PHI-free record binding a model version to an output at the moment it happened, which a third party can verify without trusting us. That supports evidentiary questions. It is not an SBOM, not a submission, and not compliance.

Resources // FDA

SBOM, AIBOM, and the part of your device neither one inventories.

An SBOM tells you what code is in the device. An AIBOM tells you what model is in the device. Neither tells you what the model did, and for an AI-enabled device that is where most of the later questions land.

Read the guide → Ask a question

Guidance rev. 3 Feb 2026SPDX · CycloneDXPHI-free · non-device

Published September 1, 2026

A software bill of materials inventories the code in your device. An AI bill of materials extends that to the model, its datasets and its lineage. Both are statements about what the system is made of. Neither is a record of what the system did, and on an AI-enabled device that third layer is where the difficult questions land: which model version produced this output, and can you show the record has not been altered since.

These three artifacts get discussed as though they were one deliverable with different names. They are not. This guide covers what the current FDA guidance actually expects in an SBOM, what an AIBOM adds that an SBOM structurally cannot express, and the question neither of them was designed to answer.

Which guidance is current

Start here, because it is easy to be a revision behind. The premarket cybersecurity guidance has been finalized three times: 27 September 2023, then 27 June 2025, then 3 February 2026, each superseding the one before.^[1][2]

The February 2026 revision aligns the document's terminology with the Quality Management System Regulation, which took effect on 2 February 2026 and incorporates ISO 13485:2016 into 21 CFR Part 820.^[2] The title moved from "Quality System Considerations" to "Quality Management System Considerations" for the same reason. If an internal SOP or a vendor page still describes the June 2025 version as operative, it is describing a superseded document.

What the SBOM has to carry

Section 524B requires a cyber device submission to include a software bill of materials. The guidance expects it to be machine-readable, in practice SPDX or CycloneDX, and to carry per component the supplier name, component name, version, unique identifiers and dependency relationships, together with the SBOM author and a timestamp, plus support status and end-of-support date.^[1]

The guidance also frames the SBOM as a living document tied to vulnerability management rather than a one-time submission artifact.^[1] That framing is the part most often missed, and it explains the two failures that show up later.

The first is treating the SBOM as something produced once for a submission and never regenerated. The second is weak component identity: without stable unique identifiers, a component in your inventory cannot be reliably matched against a vulnerability record months later, which is most of what the inventory exists to enable. Both look fine at submission time. Both surface the first time someone needs to trace an advisory to a shipped device.

What an AIBOM adds, and why it had to exist

An SBOM's vocabulary is built around software components: something with a supplier, a version, and dependencies. That model works well for a library, an operating system, a firmware image.

It has no field for a set of weights. There is no supplier-and-version way to express which training data produced a model, which evaluation it passed, or what its lineage was. You can list the inference runtime and the numerical libraries underneath a model, and doing so tells you almost nothing about the model.

An AI bill of materials, or ML-BOM in the CycloneDX vocabulary, exists to carry exactly that: the model, its version, the datasets it was trained and evaluated on, and its lineage. We covered the standards stack in AIBOM for healthcare. The point worth isolating here is the division of labor. The SBOM answers what code is in the device. The AIBOM answers what model is in the device. On a conventional device the first question is nearly the whole risk picture. On an AI-enabled device a large share of the behavior lives in the weights, so a complete SBOM can still leave the consequential part uninventoried.

Three layers, three questions

Artifact	Answers	Created when	Cannot tell you
SBOM	What code is in the device	At build, maintained over life	Which model, or what it did
AIBOM / ML-BOM	What model is in the device, and its lineage	At build or release	What any individual decision was
Decision provenance	Which model version produced this output, on intact data	At the moment of the decision	What else is installed on the device

The third row is the one that cannot be reconstructed later. An SBOM can be regenerated from a build. An AIBOM can be reissued from a release record. A decision record cannot be created after the decision, because the thing it attests to has already happened.

Why "we have both bills of materials" is not an answer to the later question

Picture the sequence that actually causes trouble. A device ships with an SBOM and an AIBOM, both complete. Eighteen months later a clinician disputes an AI-assisted output, or a regulator asks about a specific case during post-market review.

The SBOM establishes what software was in that release. The AIBOM establishes which model version that release carried. Neither establishes that this particular output came from that model, on data that had not been altered, at the time in question. Both documents describe a configuration. The question is about an event.

This gets sharper where a device is authorized to change. Under a Predetermined Change Control Plan a model can be updated without a new marketing submission, which means the model version in force is a function of the date. We covered that in one record, two regulators. A bill of materials issued at release cannot tell you which authorized state was running on a Tuesday in March.

What to do with this

Treat the three as three, and check which of them your current process actually produces. Most teams building AI-enabled devices have an SBOM because the submission forces it. Fewer have an AIBOM, and it is usually assembled by hand rather than emitted by the pipeline. Very few emit a per-decision record, because nothing in the submission asks for one.

That last gap is defensible right up until someone asks about a specific case. The cost of closing it is low while the system is being built and high afterward, because unlike the other two artifacts it cannot be produced retrospectively. The mechanics of a record that holds up are covered in what tamper-evident actually requires, and the underlying idea in what clinical-AI decision provenance is.

What we are careful never to claim

RankShieldMD does not generate your SBOM. That is a build-pipeline function with established tooling, and we are not in it. We do not write your submission, do not determine your device classification, and are not legal or regulatory advice. We are not a medical device, we do not render or score clinical decisions, and we never see PHI.

What we produce is the third layer: a tamper-evident, externally anchored, PHI-free record binding a model version to an output at the moment it happened, verifiable by a third party without access to your systems and without trusting us. It supports evidentiary questions that an inventory cannot reach. It is not compliance and it is not a clearance.

References

[1] Finite State. What Does the FDA's Final Guidance Say About SBOMs? Summarizes the required per-component fields, the machine-readable expectation (SPDX or CycloneDX), and the living-document framing tied to vulnerability management. finitestate.io
[2] U.S. Food and Drug Administration. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance; current version 3 February 2026, superseding 27 June 2025 and 27 September 2023. fda.gov
[3] DLA Piper. FDA issues revised cybersecurity premarket submission guidance to align with quality management system regulation. February 2026. dlapiper.com
[4] OWASP CycloneDX. Machine Learning Bill of Materials (ML-BOM). The model, dataset and lineage vocabulary an SBOM does not carry. cyclonedx.org

Answer engine

Ask the founder.

Straight answers about verifiable healthcare AI. Tap a question, or type your own.

Jamie Kloncz, founderverified human ✓

Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it.

What does the FDA require in an SBOM for a cyber device?: A software bill of materials that inventories the components in the device, in a machine-readable form. The current premarket guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," was revised on 3 February 2026 to align with the Quality Management System Regulation. It expects the SBOM to carry, for each component, the supplier name, component name, version, unique identifiers and dependency relationships, along with the SBOM author and a timestamp, plus the support status and end-of-support date. Machine-readable in practice means SPDX or CycloneDX.
Which FDA guidance is current?: The 3 February 2026 revision. The premarket cybersecurity guidance has been through three finalized versions: 27 September 2023, then 27 June 2025, then 3 February 2026, each superseding the last. The February 2026 revision aligns terminology with the Quality Management System Regulation, which took effect on 2 February 2026 and incorporates ISO 13485:2016 into 21 CFR Part 820. If a vendor page or an internal SOP still cites the June 2025 version as operative, it is one revision behind.
What is the difference between an SBOM and an AIBOM?: An SBOM inventories software components: libraries, operating system, firmware, third-party dependencies, and the relationships between them. An AIBOM, or ML-BOM in the CycloneDX vocabulary, extends that idea to the parts of an AI system a software inventory has no vocabulary for: the model itself, its version, the datasets it was trained and evaluated on, and its lineage. They answer different questions. The SBOM tells you what code is in the device. The AIBOM tells you what model is in the device.
Does an SBOM cover the AI model in our device?: Not meaningfully. An SBOM will list the inference runtime, the numerical libraries and the operating system underneath the model, because those are software components with suppliers and versions. It has no field that captures which weights were loaded, what data they were trained on, or which evaluation they passed. For a conventional device that gap does not matter much, because the risk lives in the code. For an AI-enabled device a large part of the behavior lives in the weights, and a complete software inventory can still leave that part uninventoried.
If we have both, are we covered?: For inventory questions, largely. For evidentiary questions, no, and the distinction matters. An SBOM and an AIBOM are both inventories: statements about what a system is made of at a point in time. Neither is a record of what the system did. Asked months later which model version produced a specific output, or whether the record of that output has been altered since, neither document can answer, because neither was created at the moment of the decision. Inventory and provenance are different artifacts serving different questions.
Where do most SBOMs fall short in a submission?: Two places, in our reading of the guidance. The first is treating the SBOM as a one-time deliverable rather than a living document maintained alongside vulnerability management, which is how the guidance frames it. The second is component identity: without stable unique identifiers, a component in your inventory cannot be reliably matched to a vulnerability record later, which is most of what an SBOM is for. Both failures look fine at submission and surface when something needs to be traced.
Does RankShieldMD produce our SBOM?: No. SBOM generation is a build-pipeline function and there are established tools for it. RankShieldMD is not a medical device, does not render clinical decisions, and never sees PHI. What we produce is the layer neither bill of materials covers: a tamper-evident, PHI-free record binding a model version to an output at the moment it happened, which a third party can verify without trusting us. That supports evidentiary questions. It is not an SBOM, not a submission, and not compliance.