SBOM compliance requirements: A comprehensive guide

An SBOM is a formal, machine-readable inventory of the components associated with a software product or build. Depending on the applicable requirement, it can provide regulators, customers, procurement teams, and security teams with standardized information about software composition and dependencies.

This guide explains major SBOM compliance requirements, the standards and formats organizations should understand, and how SBOM data can become part of a broader software supply chain and application security program.

Key takeaways

• There is no universal definition of SBOM compliance. Requirements depend on the applicable law, regulation, procurement rule, industry standard, or contract.
• Some regimes explicitly require SBOMs. The EU Cyber Resilience Act (CRA), for example, requires manufacturers of covered products with digital elements to draw up a machine-readable SBOM covering at least top-level dependencies.
• In the US, Section 524B of the Federal Food, Drug, and Cosmetic Act requires manufacturers of qualifying cyber devices to provide an SBOM that includes commercial, open-source, and off-the-shelf software components.
• The 2026 Minimum Elements for a Software Bill of Materials, published by CISA and international partners, replace the 2021 NTIA baseline. The updated guidance defines 17 minimum data fields alongside practices and processes for generating, maintaining, and sharing machine-processable SBOMs.
• Other frameworks, including PCI DSS, DORA, and NIS2, impose relevant software inventory, vulnerability management, and supply chain requirements without creating the same general explicit SBOM mandate.
• An SBOM provides software component visibility, but organizations still need processes and tools to identify, assess, prioritize, and remediate security risks associated with those components.
• Invicti helps turn SBOM compliance into actionable security by combining SCA-driven SBOM and AI-BOM generation with DAST runtime intelligence and ASPM, enabling teams to prioritize vulnerabilities and manage remediation across the application lifecycle.

What is SBOM compliance?

SBOM compliance means satisfying the SBOM-related obligations that apply to an organization under a specific law, regulation, procurement requirement, standard, or contract.

Those obligations can cover the information included in an SBOM, its format and dependency depth, when it needs to be generated or updated, how it is distributed, and what supporting vulnerability management processes are required.

This makes context essential. Meeting a general minimum-elements baseline, for example, does not automatically establish compliance with every regulation that refers to an SBOM.

Organizations first need to identify the obligations that apply to their software, industry, customers, and markets. They can then determine what SBOM data and processes those obligations require.

Who needs to consider SBOM requirements?

SBOM requirements can affect organizations in several different ways.

Software manufacturers placing covered products with digital elements on the EU market need to consider the explicit SBOM provisions of the Cyber Resilience Act. Manufacturers of qualifying cyber devices in the US face explicit FDA requirements.

Software suppliers serving US federal agencies may encounter SBOM requirements through federal procurement actions, agency requirements, or contractual terms. Customers in other sectors can also make SBOM delivery a condition of procurement.

Organizations subject to frameworks such as PCI DSS, DORA, or NIS2 may use SBOMs to support software inventory, vulnerability management, and software supply chain controls even where the framework does not itself impose a general SBOM mandate.

The starting point should therefore be the requirement that applies to the organization, product, or contract rather than a generic definition of SBOM compliance.

SBOM requirements at a glance

The distinction between an explicit SBOM requirement and a broader security requirement that an SBOM can support is important.

The exact scope and implementation details should always be checked against the applicable primary source and, where relevant, national implementation or contractual terms.

SBOM formats and data standards

A useful SBOM needs structured data that can be generated, exchanged, and processed automatically. Two widely used formats are SPDX and CycloneDX.

SPDX and CycloneDX

Software Package Data Exchange (SPDX) is an international standard for communicating information about software components, licenses, copyrights, security references, and other software metadata.

CycloneDX is an OWASP standard designed around software supply chain and security use cases. In addition to SBOMs, the CycloneDX specification supports related security information and other bill of materials types.

Both formats can represent software component inventories and dependency information. The appropriate format depends on the regulatory, contractual, customer, and technical requirements of the organization exchanging the SBOM.

Organizations should establish which formats their consumers require rather than assuming that generating one particular SBOM format establishes compliance.

CISA 2026 minimum elements and the NTIA baseline

The National Telecommunications and Information Administration (NTIA) published the original Minimum Elements for a Software Bill of Materials in 2021 in response to Executive Order 14028. On July 29, 2026, CISA, NSA, FBI, and international partners published the updated 2026 Minimum Elements for a Software Bill of Materials, which explicitly updates and replaces the NTIA document.

The 2026 guidance expands the minimum data baseline from seven fields to 17. It separates them into nine fields describing the SBOM itself and eight fields describing software components.

Metadata fields for CISA’s minimum SBOM:

• SBOM Author
• SBOM Author Signature
• SBOM Data Format Name
• SBOM Data Format Version
• SBOM Generation Context
• SBOM Timestamp
• SBOM Tool Name
• SBOM Tool Version
• SBOM Version

Component data fields for CISA’s minimum SBOM:

• Component Dependency Relationship
• Component Hash Algorithm
• Component Hash Value
• Component Identifiers
• Component License
• Component Name
• Component Producer
• Component Version

Several familiar NTIA fields remain but have been renamed or clarified. “Supplier Name” becomes “Component Producer,” “Author of SBOM Data” becomes “SBOM Author,” and “Version of the Component” becomes “Component Version.” The expanded field set also reflects greater emphasis on SBOM provenance, component identification, and machine-processable information.

The updated guidance also revises the surrounding practices and processes. It uses concepts including machine-processable data, coverage, frequency, accommodation of updates, distribution and delivery, and explicit identification of unknown information. SPDX and CycloneDX remain central machine-processable SBOM formats, while SWID is no longer listed as one of the primary SBOM data formats in the updated guidance.

These minimum elements are still a baseline rather than a universal compliance specification. A regulator, customer, or procurement process can require different or additional information, so organizations should map the applicable requirement to the SBOMs they generate.

SBOMs and VEX

An SBOM identifies software components. A Vulnerability Exploitability eXchange (VEX) document communicates information about whether a product is affected by a known vulnerability in one of those components.

This distinction matters because the presence of a vulnerable component version does not by itself establish the actual security impact on a particular application. The affected code might not be used, reachable, or exploitable in the application’s context.

SBOM and VEX data can therefore complement each other, but they serve different purposes. An SBOM primarily answers “What is in this software?” VEX provides additional information about the status of specific vulnerabilities in a product.

US SBOM requirements and federal software procurement

US federal policy played a major role in accelerating SBOM adoption, particularly through Executive Order 14028, Improving the Nation’s Cybersecurity, and the subsequent work of NIST and NTIA.

The resulting guidance should not be interpreted as one universal SBOM rule for every organization selling software to the US government. The specific obligation depends on the relevant procurement action, agency requirements, contractual terms, and other applicable federal rules.

Executive Order 14028 and SBOMs

Executive Order 14028 directed federal work on improving software supply chain security and established SBOMs as one of the mechanisms for increasing software transparency.

NTIA defined the original minimum elements for an SBOM in 2021, while NIST developed related guidance for federal software acquisition and software supply chain risk management. In July 2026, CISA and its US and international partners replaced the NTIA baseline with the expanded 2026 Minimum Elements for a Software Bill of Materials.

Existing NIST federal procurement guidance states that, when an SBOM is applicable to a procurement action, agencies should require suppliers to provide access to machine-readable SBOMs. Because that NIST guidance predates the July 2026 CISA update and still references the earlier NTIA elements, organizations should use the current 2026 minimum elements alongside any specific agency, procurement, or contractual requirements.

For software suppliers, the practical requirement is therefore to establish what the specific federal customer, agency, procurement action, or contract requires rather than treating “EO 14028 compliance” as a standalone SBOM certification.

NIST secure software guidance

SBOMs sit within a broader federal software supply chain security model.

NIST guidance addresses secure software development, software verification, component provenance, vulnerability management, supplier risk, and other controls alongside SBOMs. The Secure Software Development Framework (SSDF), NIST SP 800-218, provides a common set of secure software development practices that can support federal software assurance requirements.

For SBOM programs, the key point is that component transparency is part of a wider secure software development and supply chain process. An SBOM does not replace secure development, vulnerability identification, or remediation.

DoD and other federal requirements

Organizations supplying software to the Department of Defense or other federal agencies can encounter SBOM requirements through procurement terms, contract clauses, program requirements, or customer-specific software assurance processes.

Related federal frameworks such as CMMC and FedRAMP should not automatically be treated as standalone SBOM mandates. Organizations need to verify the specific controls, procurement terms, and contractual requirements that apply.

Where SBOMs are requested, suppliers may need to provide component inventories alongside other evidence of secure development, vulnerability management, software provenance, or supply chain risk controls.

EU Cyber Resilience Act (CRA) SBOM requirements

The EU Cyber Resilience Act establishes one of the clearest statutory SBOM requirements for manufacturers of covered products with digital elements.

The CRA requires manufacturers to identify and document vulnerabilities and components contained in their products, including by drawing up an SBOM in a commonly used, machine-readable format. That SBOM must cover at least the product’s top-level dependencies.

This obligation sits within broader vulnerability handling requirements. Manufacturers must also address and remediate vulnerabilities, apply effective and regular security testing and reviews, and meet other product cybersecurity obligations defined by the regulation.

The distinction between maintaining an SBOM and publishing one is also important. The CRA’s requirement to create component documentation does not mean manufacturers must make their complete SBOM freely public.

For software vendors selling covered products into the EU, SBOM management should therefore be integrated with the wider product security and vulnerability handling processes required by the CRA.

FDA SBOM requirements for medical devices

Medical device manufacturers face another explicit SBOM requirement in the United States.

Section 524B of the Federal Food, Drug, and Cosmetic Act requires manufacturers of cyber devices to provide specified cybersecurity information to FDA. For qualifying cyber devices, this includes an SBOM containing commercial, open-source, and off-the-shelf software components.

FDA’s current final guidance, “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions,” was issued in February 2026 and superseded the June 2025 version.

FDA’s February 2026 guidance recommends machine-readable SBOMs consistent with the then-current NTIA minimum elements and also recommends additional component information, including support status and end-of-support dates. Since that FDA guidance was issued, the July 2026 CISA minimum elements have replaced the 2021 NTIA baseline, so manufacturers should consider both the FDA-specific requirements and the current SBOM guidance when designing their SBOM processes.

The SBOM is only one part of the cybersecurity information relevant to a medical device submission. FDA guidance also addresses known vulnerabilities, security risk assessments, security controls, vulnerability management plans, updates, and other lifecycle cybersecurity considerations.

Medical device manufacturers should therefore connect SBOM generation with their broader product security and vulnerability management processes rather than treating the SBOM as an isolated submission artifact.

Where SBOMs support broader compliance requirements

Not every framework associated with software component visibility explicitly requires an SBOM.

That distinction is particularly important for PCI DSS, DORA, and NIS2. SBOMs can provide useful evidence and automation for meeting relevant requirements, but the applicable controls remain broader than simply producing an SBOM.

SBOMs and PCI DSS

PCI DSS 4.0.1 does not establish a general requirement to produce an SBOM.

Requirement 6.3.2 instead requires organizations to maintain an inventory of bespoke and custom software and third-party software components incorporated into bespoke and custom software to facilitate vulnerability and patch management.

An SBOM can support this requirement by providing structured component and version information, particularly when generated and maintained through software composition analysis (SCA).

SBOMs and DORA

The EU Digital Operational Resilience Act (DORA) applies to financial entities within its scope and establishes requirements for managing information and communications technology (ICT) risk.

DORA does not impose a generic SBOM requirement. It does require financial entities to identify and maintain inventories of ICT assets and understand relevant dependencies and third-party relationships.

Detailed DORA requirements for vulnerability and patch management also require financial entities to track the use of third-party libraries, including open-source libraries, used by ICT services supporting critical or important functions. They also require automated vulnerability scanning and processes for prioritizing and monitoring remediation.

SBOM and SCA data can support these activities by improving visibility into software dependencies, versions, vulnerabilities, and third-party components.

SBOMs and NIS2

The NIS2 Directive requires covered essential and important entities to implement appropriate and proportionate cybersecurity risk-management measures.

Article 21 includes requirements relating to supply chain security and the security of network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure.

NIS2 does not impose a universal SBOM requirement. SBOMs can nevertheless support these security activities by helping organizations understand third-party software dependencies, maintain component visibility, investigate vulnerabilities, and manage software supply chain risk.

Because NIS2 is a directive implemented through national law, organizations also need to consider the requirements and supervisory expectations in the relevant EU member state.

What else can an SBOM contain?

The CISA 2026 minimum elements already cover core component identity, dependency, license, hash, generation, format, tool, and SBOM provenance information. Beyond that baseline, organizations may add metadata that supports specific regulatory, operational, or security use cases.

Depending on the applicable requirement and tooling, useful additional information can include:

• Component support status
• End-of-support or end-of-life dates
• Build and release provenance beyond the required SBOM metadata
• Vulnerability information associated with components
• Vulnerability status and exploitability information, such as VEX
• Business or application context
• Internal ownership and remediation information

More metadata can improve operational usefulness, but adding fields does not automatically make an SBOM compliant with a particular regulation or contract.

SBOM quality also matters. An SBOM should accurately identify component versions and relationships, contain useful identifiers, represent the required dependency depth, and remain traceable to the software release it describes.

How are SBOMs generated?

SBOM generation can happen at several stages of the software lifecycle, and the method affects what the resulting inventory represents.

SCA tools can analyze package manifests, lockfiles, source repositories, and other dependency information to identify open-source and third-party components. This approach can provide detailed dependency relationships and integrate with developer and CI/CD workflows.

Generating an SBOM during a build can provide a record associated with a particular software build or release. Organizations may also analyze built artifacts, packages, containers, or software received from external suppliers when source code or original build information is unavailable.

The appropriate approach depends on the regulatory requirement, software delivery model, available tooling, and intended SBOM consumer. Organizations may use more than one method where they need broader component visibility.

For a deeper look at operational SBOM and component security practices, see Invicti’s software supply chain security checklist.

How to build an SBOM compliance program

An effective SBOM program needs repeatable processes for identifying requirements, generating inventories, maintaining them, and connecting component data with security operations.

1. Identify applicable requirements

Establish why the organization needs SBOMs and which products, applications, or contracts are in scope.

Consider regulatory requirements, federal or other procurement rules, customer contracts, geographic markets, and internal software supply chain policies.

Do not assume that all requirements use the same fields, formats, dependency depth, update processes, or distribution model.

2. Define SBOM scope, data, and formats

Determine which applications, products, repositories, releases, and artifacts need SBOM coverage.

Map each applicable requirement to the expected data fields, accepted formats, dependency depth, and other technical requirements. For programs using US government minimum-element guidance as a baseline, use the 2026 CISA minimum elements rather than the superseded 2021 NTIA field set. Where multiple requirements apply, standardized internal processes can reduce duplicated effort.

3. Automate generation, validation, and versioning

Integrating SBOM generation with SCA, source control, build, or CI/CD processes can help keep inventories associated with current software versions.

Generated SBOMs should be validated for required data and format, traceable to the software they describe, and retained or versioned according to applicable requirements.

4. Define access, distribution, and retention

SBOM sharing requirements vary. Some SBOMs may need to be provided to regulators or customers, while others may be maintained internally or supplied only under defined conditions.

Organizations should establish who can receive SBOMs, how they are delivered, how updated versions are communicated, and what records need to be retained.

5. Connect SBOMs with vulnerability and risk management

Component inventories become much more useful when organizations can continuously identify newly disclosed vulnerabilities affecting those components.

That means connecting SBOM and component data with vulnerability intelligence, SCA, prioritization, ownership, remediation, and security testing processes.

Why an SBOM alone is not vulnerability management

An SBOM answers an important question: What components are present in this software?

SCA adds security analysis by identifying third-party components and associating them with known vulnerabilities, license issues, dependency relationships, and other component risks. An SBOM records component information in a standardized, portable form.

Application security testing provides other types of evidence. Static application security testing (SAST) analyzes first-party application code, while dynamic application security testing (DAST) exercises running applications and APIs to identify vulnerabilities observable at runtime.

Runtime evidence can add valuable context, but DAST should not be treated as a universal mechanism for proving whether every vulnerable dependency is exploitable. For supported vulnerability classes, technologies such as proof-based scanning can safely provide evidence that detected vulnerabilities are exploitable.

For a detailed comparison of these roles, see SBOM vs. SCA: What each does, how they relate, and what DAST adds.

The broader security objective is to connect component inventory, component risk, application testing, runtime evidence, prioritization, and remediation rather than treating the SBOM as an isolated compliance artifact.

How Invicti makes SBOM data actionable

Invicti brings software supply chain visibility into an AppSec platform that spans code, software components, running applications and APIs, and vulnerability management.

Invicti SCA identifies direct and transitive dependencies and connects component data with vulnerability and license intelligence. SBOMs can be automatically generated in industry-standard formats such as CycloneDX and SPDX, while third-party SBOMs can also be ingested and enriched with security information.

SCA reachability provides an additional prioritization signal by identifying whether a vulnerable dependency is invoked by application code. This signal applies specifically to SCA findings and can be considered alongside vulnerability severity, threat intelligence, application context, and other risk factors.

Software supply chains increasingly contain AI-specific dependencies as well. Invicti AI-BOM extends the existing SBOM pipeline to identify AI frameworks, model providers, agentic libraries, vector databases, Model Context Protocol (MCP) SDKs, and embedded model files. This gives teams a structured inventory of AI components alongside their wider software component inventory without requiring a separate scan.

Runtime intelligence adds another source of security context from running applications and APIs. Invicti’s DAST foundation identifies application vulnerabilities at runtime, while proof-based scanning can confirm exploitability for supported vulnerability classes.

At the management layer, Invicti ASPM brings findings from DAST, SAST, SCA, API security, containers, and other sources into common AppSec workflows. Normalization, deduplication, prioritization, policy, routing, remediation tracking, and reporting help teams manage application risk across tools and testing methods.

For SBOM programs, this creates a path from component inventory to ongoing risk management: understand what software contains, monitor component risk, add application and runtime context, prioritize findings, and track remediation through the vulnerability lifecycle.

SBOM compliance checklist

Use this checklist as a starting point when establishing or reviewing an SBOM program. Individual regulatory and contractual requirements may add or remove specific obligations.

• Have you identified the laws, regulations, procurement rules, standards, and contractual requirements that apply?
• Have you established which products, applications, and releases are in scope?
• Have you defined the required data, format, and dependency depth?
• Are SBOMs generated automatically and validated where practical?
• Can each SBOM be traced to the software version or release it describes?
• Are versioning, retention, and update processes defined?
• Are distribution and access requirements documented?
• Can you consume third-party SBOMs where necessary?
• Is component data connected with current vulnerability intelligence and remediation processes?
• Can you provide the necessary evidence to customers, auditors, procurement teams, or regulators?

Turn SBOM visibility into actionable application security

SBOM compliance starts with understanding the requirements that apply to your software and producing accurate component information in the required format. The security value comes from putting that inventory to work across vulnerability management, application testing, runtime intelligence, prioritization, and remediation.

Invicti connects software composition and SBOM management with broader application security capabilities, helping teams understand component risk in the context of their applications and manage remediation through a unified AppSec platform.

Learn more about Invicti’s software composition analysis and SBOM capabilities, and request a demo to see how Invicti can help turn software component visibility into actionable application security.