On this page
Published: · Updated:
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.
- An AIBOM supports Predetermined Change Control Plan traceability, but is not a prerequisite; other controlled configuration records can identify the shipped model.
- 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 an AIBOM can supplement it with model and provenance information as recommended practice, not FDA-required fields.
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. Controlled configuration records can address this traceability gap, with or without an AIBOM.
What the FDA expects today
The February 3, 2026 premarket cybersecurity guidance does not use the word AIBOM. Section 524B requires an SBOM to the FDA for cyber devices. The guidance recommends machine-readable SBOMs, encourages industry-accepted formats, and names no format or version floor (§V.A.4(b), p. 17). It recommends component support level and end-of-support date, which may be supplied in an addendum. The following AI inventory additions are our recommended practices, not FDA-required AIBOM fields:
The seven fields are the historical NTIA 2021 baseline referenced by the FDA guidance. CISA’s July 29, 2026 SBOM minimum elements supersede that baseline and add elements including author signature, SBOM version, component hash, and license information; these are not additional FDA-specific fields. CISA’s 2026 minimum elements also apply to AI software components; they do not create FDA-required AIBOM model or dataset fields.
- 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.
These practices can extend an existing inventory or use linked controlled records; the FDA guidance does not prescribe an AIBOM.
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 | Native in the Security profile; SPDX 2.3 uses external VEX |
| 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 can complicate traceability.
Minimum AIBOM fields for a submission
The table is a recommended internal AIBOM checklist, not an FDA minimum-field list or an extension mandated by the NTIA baseline.
| 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, and validate it against what shipped to reduce drift.
- 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.
- Relying only on a human-readable inventory when machine-readable data would support monitoring. AIBOM format is recommended practice, not an FDA requirement.
Frequently asked questions
Does the FDA require an AIBOM?
No. Section 524B requires an SBOM for cyber device submissions to the FDA. An AIBOM is recommended practice for model and dataset traceability, not a separate FDA requirement, and does not guarantee avoidance of additional-information requests.
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?
The SBOM recommendation does not itself require disclosure of training datasets or specific dataset fields. Determine applicable AI submission documentation separately. We recommend controlled provenance references and dataset characteristics rather than including raw patient data in an AIBOM.
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. An AIBOM can support evidence of model version, weights, and data used in each release, alongside change-control and validation records. It is not a prerequisite to a PCCP and cannot alone establish that a change stays within authorized bounds.
Which format should we use?
Use the one your SBOM already uses. CycloneDX and SPDX 3.0 both support native VEX, with SPDX 3.0 using its Security profile; SPDX 2.3 pairs with external VEX. Assess tool support and provenance needs. The FDA guidance names neither format, and no format guarantees a review outcome.
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.
