Software supply chain visibility is becoming part of product security work as the EU Cyber Resilience Act (CRA) moves toward application in December 2027. ENISA’s SBOM Adoption State of Play 2026 shows organizations preparing for CRA obligations through SBOM tooling, automation, and changes to software development practices.

Level of SBOM adoption based on organisation size (Source: ENISA)

SBOMs move from best practice to requirement

The CRA requires manufacturers to create, maintain, and, where necessary, provide Software Bills of Materials for products with digital elements. The requirement places software supply chain transparency alongside other product security obligations and gives organizations a structured way to track software components and dependencies throughout a product’s lifecycle.

An SBOM serves as an inventory of the components, libraries, dependencies, and licensing information that make up a software product. That visibility supports vulnerability management, supplier risk assessments, license compliance, and technical documentation.

SBOM programs are becoming part of broader product security efforts. Adoption is underway throughout the software ecosystem, especially in organizations that expect to fall within the scope of the CRA.

Adoption gains momentum

Most respondents said their organizations have already started implementing SBOM-related processes and capabilities.

The regulation is influencing investment decisions, with many organizations increasing spending on SBOM tooling and automation. Respondents expect significant progress before the CRA becomes applicable, driven by efforts to integrate software supply chain transparency into development and security practices.

Common uses include vulnerability management, software inventories, third-party risk assessments, and compliance activities.

Limited supplier visibility

SBOM generation is becoming part of software development workflows. Thirty-nine percent of respondents generate SBOMs during software builds, making build-time generation the most common approach.

The survey shows growing investment in automation. Respondents reported using tooling to generate, update, and maintain SBOMs throughout the product lifecycle in support of vulnerability handling, software inventory management, and compliance efforts.

Many respondents reported challenges obtaining SBOMs from suppliers, particularly for commercial software products acquired from third parties. Limited access to supplier SBOMs reduces visibility into components and dependencies that originate outside an organization’s development environment.

Those gaps affect a range of activities, including vulnerability analysis, software inventory management, incident response, and software supply chain risk assessments. Visibility into internally developed software is improving. Supplier transparency remains inconsistent.

Building complete SBOMs remains difficult

Generating an SBOM is only part of the process. Organizations need to ensure that the information is complete, accurate, and useful for security and compliance activities.

Sixty-two percent of respondents rated achieving a high degree of SBOM completeness as quite difficult or extremely difficult. Tracking software components and dependencies throughout the development lifecycle requires substantial effort, particularly in complex software environments.

Data quality issues, vulnerability matching, and shortages of internal expertise slow adoption efforts. They can reduce the usefulness of SBOM data and make it harder to determine which software components are affected by newly disclosed vulnerabilities.

Organizations are looking for practical support to address those issues. Common requests include reference implementations, guidance on tool selection, conformance testing, and shared practices for integrating SBOMs into software development, risk management, and compliance processes.

Apply now: Simplify security management with CIS SecureSuite Platform