On this page
Published:
Key Takeaways
- An AIBOM is an SBOM extended to cover model artifacts, weights, training and evaluation data, frameworks, and hosted model endpoints. It is not a separate document format; it is additional component types inside the bill of materials you already ship.
- The FDA does not require an AIBOM by that name. It requires an SBOM that covers all software components, and for an AI-enabled device the model and its runtime are software components.
- CycloneDX supports AI components natively through its machine-learning model card extension. SPDX 3.0 added an AI profile and a dataset profile. Either satisfies a machine-readable inventory.
- The AIBOM is what makes a Predetermined Change Control Plan auditable: without a versioned inventory of model artifacts, you cannot show which model the cleared device shipped with.
- Pair the AIBOM with VEX. A CVE in a serialization library is only meaningful once you can state whether the vulnerable path is reachable from your inference pipeline.
What is an AIBOM for medical devices?
An AIBOM is a machine readable inventory of the model artifacts, weights, training and evaluation datasets, frameworks, and hosted models behind an AI enabled device. The FDA does not name it as a required deliverable, but Section 524B already requires an SBOM covering all software components, and reviewers increasingly expect the model and its provenance to appear in that inventory using CycloneDX or SPDX.
Most SBOM tooling was built to enumerate compiled dependencies. Point it at an AI-enabled medical device and it will faithfully list the Python packages and miss the thing that actually determines clinical behavior: the model. The AI bill of materials closes that gap.
What is an AIBOM?
An AIBOM, or AI bill of materials, is a machine-readable inventory of the components that determine how an AI system behaves. For a medical device, that means:
- Model artifacts. Each shipped model, with a version, a hash, and the format it is serialized in.
- Weights and checkpoints. Which weights the cleared configuration uses, and where they came from.
- Training, validation, and test datasets. Source, size, licensing, patient population, and any de-identification applied.
- Frameworks and runtimes. PyTorch, TensorFlow, ONNX Runtime, TensorRT, and the versions actually deployed on the device.
- Preprocessing and feature code. The transformations applied before inference, which are as safety-relevant as the model itself.
- External and hosted models. Any third-party model or API the device calls, including the vendor, the model identifier, and the version pinning strategy.
The AIBOM is not a new file format. It is a set of component types recorded inside the same bill of materials you already produce for your submission.
AIBOM vs SBOM: what actually differs
| Dimension | SBOM | AIBOM |
|---|---|---|
| Primary unit | Software package or library | Model artifact, dataset, framework |
| Version identity | Package version and hash | Model version, weight checksum, training run identifier |
| Provenance question | Who published this library? | Who trained this model, on what data, under what license? |
| Vulnerability source | CVE feeds (NVD, KEV, OSV) | CVEs in the runtime plus model-specific risks: poisoning, inversion, evasion, drift |
| Change trigger | Dependency upgrade | Retraining, fine-tuning, weight update, dataset refresh |
| Regulatory hook | Section 524B SBOM requirement | Same SBOM requirement plus the PCCP and AI-specific risk documentation |
The practical consequence: an SBOM that is technically complete can still leave a reviewer unable to tell which model version the device under review actually runs. That is the deficiency worth avoiding.
What the FDA expects today
The February 3, 2026 premarket cybersecurity guidance does not use the word AIBOM. It does require a machine-readable SBOM covering the software in the device, and it expects the security risk analysis to address the device as built, including AI components. Read together with the agency's AI-enabled device documentation expectations, that produces four practical asks:
- The model is inventoried like any other component. Name, version, hash, supplier, and where it executes: on-device, on an edge gateway, or in a cloud service.
- Third-party and hosted models are disclosed. A model you call over an API is a supplier relationship with a trust boundary, and it belongs in both the inventory and the threat model.
- Unresolved vulnerabilities in the AI stack are assessed, not omitted. Serialization libraries, model servers, and GPU runtimes carry CVEs like any other dependency.
- Change control is traceable. If your PCCP allows retraining after clearance, the inventory has to make "which model shipped" answerable at any point in the lifecycle.
None of this requires a new document. It requires that your existing SBOM stop treating the model as an opaque blob.
Formats: CycloneDX ML-BOM or SPDX 3.0 AI profile
Both major SBOM standards now carry AI components, so the CycloneDX vs SPDX decision does not change because you added a model.
| Capability | CycloneDX | SPDX 3.0 |
|---|---|---|
| AI component type | machine-learning-model component with a model card | AI profile with model metadata |
| Dataset representation | data component with governance fields | Dataset profile |
| Native VEX | Yes | Via separate VEX or CSAF document |
| Maturity for device pipelines | Stronger CI/CD tooling today | Stronger licensing and provenance modeling |
Pick the format you already use for your SBOM and extend it. Producing an SBOM in one standard and an AIBOM in the other creates a reconciliation problem for you and a credibility problem for the reviewer.
Minimum AIBOM fields for a submission
Treat this as the AI analogue of the NTIA minimum elements:
| Field | Why a reviewer cares |
|---|---|
| Model name and version | Establishes exactly what was evaluated in your clinical and bench testing |
| Weight file hash | Proves the deployed artifact matches the tested artifact |
| Model type and architecture | Informs which failure and attack modes are credible |
| Training data source and licensing | Supports provenance, bias, and IP questions |
| Dataset date range and population | Supports generalizability and drift arguments |
| Framework and runtime versions | Maps the model to CVE feeds and patchability |
| Execution location | Defines the trust boundary the model sits behind |
| Third-party model supplier and terms | Establishes who can change the model and how you would know |
| Retraining trigger and cadence | Ties the inventory to the PCCP |
| Responsible owner | Gives postmarket monitoring an accountable party |
How the AIBOM connects to VEX
An inventory generates noise. A GPU runtime or a model-serialization library will accumulate CVEs, and most of them will not be exploitable in your device. That is what VEX is for: a machine-readable statement of whether a given CVE affects your product, with a justification.
For AI components specifically, three VEX justifications carry most of the weight:
- Vulnerable code not present. You ship inference only and the vulnerable training path is not in the build.
- Vulnerable code not reachable. The deserialization path exists but the device only loads signed weights from internal storage.
- Inline mitigation already exists. The model server is not network-reachable because it sits behind an authenticated gateway inside a trust boundary you documented.
Write these once, keep them versioned with the AIBOM, and reissue them when the model or runtime changes.
Model-specific risks the inventory should support
A component list is only useful if it feeds the risk analysis. Map each AI component to the attack classes that apply to it:
| Risk | What the AIBOM contributes |
|---|---|
| Data poisoning | Dataset provenance and integrity controls for training data |
| Model inversion or extraction | Where weights live, who can read them, and how they are protected at rest |
| Adversarial evasion | Model architecture and preprocessing chain, which determine the attack surface |
| Supply chain substitution | Weight hashes and signature verification at load time |
| Performance drift | Training data date range and retraining cadence |
| Dependency CVEs | Framework and runtime versions with VEX status |
Score these on the same exploitability and patient-impact scale as the rest of your threat model so the security risk file speaks one risk language.
Generating and maintaining the AIBOM
- Emit it from the build, not from a spreadsheet. The AIBOM should be produced by the same pipeline that produces the firmware image, so it can never drift from what shipped.
- Hash every weight file at package time and verify the hash at load time on the device.
- Version datasets like code. A training set that changes silently makes every downstream claim unverifiable.
- Record hosted model versions at call time, not at design time. A vendor that silently upgrades a model behind an API has changed your device's behavior.
- Regenerate on every retrain, and record whether the change falls inside the PCCP or requires a new submission.
- Keep it postmarket. The inventory is what makes vulnerability monitoring possible after clearance. See postmarket SBOM maintenance.
Common mistakes
- Listing the Python packages and omitting the model entirely.
- Referencing "the model" with no version or hash, so no one can prove what was tested.
- Documenting the training dataset in a clinical document that the cybersecurity reviewer never sees, and nowhere in the inventory.
- Treating a hosted third-party model as infrastructure rather than a component with a supplier.
- Producing the AIBOM once for the submission and never regenerating it after a retrain.
- Submitting a PDF. The requirement is machine readability, for the AIBOM exactly as for the SBOM.
Frequently asked questions
Does the FDA require an AIBOM?
Not under that name. Section 524B requires an SBOM covering the software components of a cyber device, and for an AI-enabled device the model artifacts, frameworks, and inference runtime are software components. Reviewers increasingly ask where the model and its provenance appear. Producing an AIBOM is how you answer without a round of Additional Information questions.
Is the AIBOM a separate document from the SBOM?
It should not be. Both CycloneDX and SPDX 3.0 can carry AI components inside the same bill of materials, and keeping one artifact avoids reconciliation errors. Some teams publish an AI-focused view of the same data for internal use, which is fine as long as one source of truth generates both.
Do we have to disclose our training data?
You have to disclose enough for a reviewer to assess provenance, licensing, and generalizability: source, date range, population characteristics, size, and any de-identification. That is not the same as publishing the dataset. Proprietary detail can be described at the level of characteristics rather than raw content.
What about a third-party or foundation model we call over an API?
Inventory it as a component with a supplier, a model identifier, and a version pinning strategy, and document the trust boundary in the threat model. The key question a reviewer will ask is how you would detect that the vendor changed the model, and what your device does if the endpoint is unavailable or returns degraded output.
How does the AIBOM relate to our PCCP?
The PCCP describes which model changes you may make after clearance without a new submission. The AIBOM is the evidence that you stayed inside those bounds: it records which model version, weights, and data each release used. A PCCP without a versioned inventory is an intention rather than a control.
Which format should we use?
Use the one your SBOM already uses. CycloneDX has better CI/CD tooling and native VEX; SPDX 3.0 has stronger licensing and provenance modeling. Neither is preferred by the FDA, and neither will draw a deficiency for format alone.
Where to go next
- AAMI CR515:2025 and ML device cybersecurity - the ML threats that attach to the assets this inventory names.
- FDA SBOM requirements for medical devices
- VEX documents for medical devices
- Predetermined Change Control Plans
- FDA medical device threat model template
- Talk to a MedTech cybersecurity expert
- SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.
- AAMI CR515 Crosswalk - map CR515 clauses to GMLP, PCCP, AIBOM and Section 524B evidence.
Sources & references
Primary sources cited in this article. Links open in a new tab.
