US CISA, G7 Partners in Europe and Asia Release Minimum Elements for AI Software Bills of Materials

The US Cybersecurity and Infrastructure Security Agency (CISA), together with G7 partners from Canada, France, Germany, Italy, Japan, the United Kingdom, and the European Union, has released the joint guidance Software Bill of Materials for AI – Minimum Elements, intended to help public and private sector organizations improve transparency across artificial intelligence systems and supply chains. It could also help organizations comply with at least certain obligations under the EU AI Act and other applicable laws.

While the guidance is voluntary and nonmandatory (unlike, for example, parallel obligations under the EU AI Act that will be binding once in effect), it may become an important reference point for AI governance, cybersecurity diligence, vendor contracting, procurement, and incident response.

CISA describes the AI SBOM guidance as supplemental to general SBOM minimum elements because AI systems remain software systems but introduce additional components, including models, datasets, performance indicators, and AI-specific infrastructure.

BACKGROUND

A software bill of materials, or SBOM, functions as an “ingredients list” for software, helping organizations understand what components are present in a system and how those components may affect security, vulnerability management, and supply chain risk. CISA’s AI-focused guidance extends that concept to AI systems, where risk can arise not only from conventional software dependencies but also model provenance, training or validation datasets, model performance, infrastructure dependencies, and security properties.

The guidance reflects G7 expert consensus and is designed to evolve as AI technology develops. It expressly does not create new legal requirements, standards, or legislation, but does identify practical baseline information that AI developers and deployers should consider including in an AI SBOM.

Notably, there are certain areas of overlap between the G7 guidance and technical documentation and other information that “providers” of “high-risk” AI systems are required to develop and disclose under articles 11 and 13 and Annex IV of the EU AI Act. In turn, the guidance could help organizations meet certain of these obligations.

Structurally, the guidance organizes AI SBOM information into seven “clusters,” each containing discrete data “elements.” The Metadata cluster describes the SBOM document itself (e.g., the SBOM author, version, data format, digital signature, generation context, timestamp) while the remaining six clusters (System Level Properties, Models, Datasets Properties, Infrastructure, Security Properties, and Key Performance Indicators) describe the AI system and its constituent components.

Several elements track concepts already familiar from conventional SBOM practice, including component identifiers, cryptographic hash values and algorithms, license information, and dependency relationships, but the guidance layers on AI-specific elements such as model lineage and training properties, dataset provenance and sensitivity, and security controls addressing adversarial robustness and prompt-injection risk.

Because the guidance treats AI systems as software systems, it expressly positions these elements as supplemental to, and not a replacement for, the general SBOM minimum elements that organizations may already be producing.

Notably, the working group considered but declined to include a standalone element capturing an AI system’s level of autonomy or decision-making, observing that this attribute may be addressed differently across jurisdictions, including through safety requirements, a point worth monitoring as agentic AI deployments expand.

KEY TAKEAWAYS

• AI SBOMs are positioned as an extension of traditional SBOMs. Organizations should not treat AI inventory practices as separate from software supply chain governance. Instead, AI SBOMs should build on existing SBOM processes while adding AI-specific information.
• The guidance identifies seven core clusters of AI SBOM information. These include metadata, system-level properties, models, dataset properties, infrastructure, security properties, and key performance indicators. These clusters are intended to document the AI system as a whole, the models it uses, the datasets involved across the model lifecycle, the infrastructure required to operate the system, cybersecurity measures, and relevant performance metrics. As a result, preparing AI SBOMs based on the guidance could help organizations meet certain parallel technical documentation and disclosure obligations under the EU AI Act and other applicable laws.
• The guidance applies to both developers and deployers. AI vendors, enterprise AI adopters, critical infrastructure operators, and regulated companies may all face increased expectations to document AI system composition and provenance, even where no formal AI SBOM mandate applies.
• Dataset and model documentation are likely to become diligence focal points. The inclusion of model and dataset properties (similar to Annex IV of the EU AI Act) moves AI supply chain transparency beyond open-source software libraries and package dependencies. Procurement, security, privacy, and legal teams may increasingly ask vendors to identify model sources, dataset provenance, model limitations, and lifecycle-relevant performance information.
• The guidance may influence contractual and regulatory expectations. While voluntary, CISA and G7 guidance often informs procurement requirements, security questionnaires, vendor risk management programs, and future regulatory frameworks. The EU AI Act also requires “providers” of “high-risk” AI systems to provide SBOM-type disclosures to “deployers” of such AI systems. Companies that sell or deploy AI-enabled software should expect AI SBOM requests to become more common in enterprise and government-facing transactions.
• The AI SBOM guidance sits atop a layered and evolving US federal and international SBOM landscape. SBOM concepts already appear across federal cybersecurity policy, sector-specific regulation, and national security supply chain controls. The new AI-specific elements should be read against that backdrop, including the NTIA and CISA minimum-elements work, the US Food and Drug Administration’s statutory medical-device requirements, and the US Commerce Department’s use of SBOMs in its Information and Communications Technology and Services (ICTS) supply chain rules. EU regulators are also likely to issue regulatory guidance with respect to technical documentation and disclosure obligations under articles 11 and 13 and Annex IV of the EU AI Act, which could potentially track elements of the G7 guidance.   

THE BROADER US GOVERNMENT USE OF SBOM

The AI SBOM guidance does not arrive on a blank slate. Over the past several years, the US government has incorporated SBOMs into cybersecurity policy, sector-specific regulation, and national security supply chain controls, with the legal force of those references varying considerably, ranging from binding statutory mandates to voluntary baselines and discretionary recordkeeping.

Understanding where the AI SBOM guidance fits within this landscape is useful for assessing how quickly it may harden into a practical expectation.

Federal Cybersecurity Policy (EO 14028, NTIA, OMB, CISA)

The federal SBOM framework traces to Executive Order 14028, Improving the Nation’s Cybersecurity (May 2021), which directed the US National Telecommunications and Information Administration (NTIA) to publish the foundational Minimum Elements for a Software Bill of Materials (July 2021). The US Office of Management and Budget (OMB) subsequently issued memoranda M-22-18 and M-23-16 directing agencies to obtain supplier attestations and, where appropriate, SBOM artifacts.

The posture has continued to shift: in January 2026 OMB issued M-26-05, which rescinded the prior mandatory self-attestation memoranda in favor of an agency-led risk-based approach, even as Executive Order 14028 itself remained in effect. In parallel, CISA published draft updated 2025 Minimum Elements for a Software Bill of Materials for public comment in August 2025, refreshing the 2021 NTIA baseline to reflect more mature tooling and adding fields such as hash, license, and generation context.

The AI SBOM minimum elements are best understood as the next layer in this body of work, extending, rather than displacing, the general SBOM baseline.

Sector-Specific Mandates (FDA Medical Devices)

In contrast to the voluntary federal cybersecurity baseline, SBOMs are a binding statutory requirement in at least one regulated sector. Section 524B of the US Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act, 2023 and effective as of March 2023, requires sponsors of premarket submissions for “cyber devices” to provide an SBOM covering commercial, open-source, and off-the-shelf software components.

The FDA has indicated that inadequate cybersecurity documentation, including a deficient SBOM, may result in a “refuse to accept” decision. For companies whose AI products may qualify as or be incorporated into regulated medical devices, the AI SBOM elements and Section 524B SBOM obligation should be analyzed together.

National Security Supply Chain Controls (BIS ICTS Connected Vehicles Rule)

SBOMs have also surfaced in the national security supply chain context, where the Commerce Department’s Bureau of Industry and Security (BIS) administers rules under the ICTS authorities established by Executive Order 13873. The most developed example is the BIS final rule on connected vehicles (effective March 17, 2025), which prohibits certain transactions involving Vehicle Connectivity System (VCS) hardware and covered software with a nexus to China or Russia.

The connected vehicle rule is instructive precisely because of how its SBOM treatment evolved. The proposed rule would have required VCS hardware importers and connected vehicle manufacturers to submit an SBOM or a hardware bill of materials (HBOM), along with a list of external connection endpoints, as part of their annual Declarations of Conformity.

In the final rule, BIS retreated from affirmative submission: responding to comments on the sensitivity of the information, BIS removed the requirement to file an SBOM or HBOM with the Declaration of Conformity, narrowed the SBOM definition, and instead required declarants to certify that they had conducted supply chain due diligence and maintain supporting documentation, which may take the form of an SBOM or HBOM, to be furnished to BIS upon request.

Taken together, these regimes show SBOMs operating along a spectrum, from a binding premarket condition (FDA), to a voluntary but influential procurement baseline (EO 14028/NTIA/CISA), to discretionary diligence recordkeeping in a prohibition-based supply chain regime (BIS ICTS).

STRATEGIC INSIGHT

While The CISA/G7 guidance is not binding law, it may still meaningfully affect the standard of care for AI governance and software supply chain risk management alongside parallel binding technical documentation and disclosure obligations set out in the EU AI Act and other applicable laws. In practice, voluntary cybersecurity guidance can become operationally important when incorporated into contracts, customer security requirements, insurance questionnaires, procurement rules, or regulatory expectations.

For AI developers, the guidance suggests a need to align engineering, security, legal, and product documentation functions. An AI SBOM may require information that is not traditionally captured in a conventional SBOM process, including model lineage, dataset provenance, benchmark or performance metrics, infrastructure dependencies, and security controls. Companies should consider whether existing development pipelines can generate and maintain this information in a reliable, auditable, and customer-shareable format.

For AI deployers, the guidance may provide a framework for vendor diligence. Organizations adopting third-party AI tools should consider whether procurement and security review processes ask for AI-specific SBOM information, including the identity and source of models, use of third-party or open-source components, dataset-related representations, performance limitations, and infrastructure dependencies. For higher-risk use cases, companies may also want to evaluate whether vendor contracts require timely updates to AI SBOMs when models, datasets, or system components change.

The guidance also has implications for incident response. A useful AI SBOM can help organizations identify affected systems when a vulnerability, compromised model, tainted dataset, or insecure dependency is discovered. Without such documentation, companies may struggle to determine which AI products, internal tools, or customer-facing systems are affected by a supply chain event.

From a governance perspective, companies should consider treating AI SBOMs as part of a broader AI risk management program rather than a standalone technical artifact. Coordination with privacy, cybersecurity, IP, product, procurement, and compliance teams will be important, particularly where AI systems incorporate third-party models, open-source components, licensed datasets, or infrastructure controlled by external providers.

The guidance also carries particular significance for companies operating at the intersection of AI and national security supply chain regulation. The same component-level transparency that an AI SBOM provides maps closely onto the information that regimes such as the BIS ICTS rules, CFIUS reviews, and forthcoming foreign-adversary supply chain measures increasingly seek to capture.

For organizations whose AI systems incorporate models, datasets, or infrastructure with a foreign-adversary nexus, a well-maintained AI SBOM can serve a dual purpose: supporting cybersecurity vulnerability management while also furnishing the documentary record needed to assess and demonstrate compliance with supply chain prohibitions and due diligence certifications.

LOOKING AHEAD

Companies developing, procuring, or deploying AI-enabled software should monitor whether CISA, G7 partners, federal agencies, customers, or industry groups begin incorporating AI SBOM expectations into procurement standards, security assessments, or sector-specific guidance.

Early alignment with the CISA/G7 framework, alongside parallel binding requirements set out in the EU AI Act and other applicable laws, may help organizations respond more efficiently to customer diligence requests and demonstrate maturing AI governance practices. Organizations subject to the EU AI Act and other applicable laws may also need to bridge any “gaps” between their AI SBOMs and technical documentation and disclosure obligations under the EU AI Act (particularly with respect to “high-risk” AI systems).

HOW WE CAN HELP

Organizations should consult counsel regarding how AI SBOM practices may apply to their specific products, contracts, regulatory obligations, and risk profile.

We will continue monitoring AI supply chain, SBOM, and cybersecurity governance developments and their implications for technology companies, AI deployers, and regulated enterprises and stand ready to assist organizations with navigating any of these developments.