Summary
- ENISA’s 2026 report says the Cyber Resilience Act is accelerating SBOM adoption.
- Organisations are investing in SBOM generation and automation inside the software development lifecycle.
- Regulatory pressure is shifting SBOMs from technical documentation towards supplier assurance, procurement, and product-risk governance.
ENISA says the EU Cyber Resilience Act is accelerating adoption of software bills of materials, pushing software component transparency closer to routine product assurance and supplier governance.
The agency’s 2026 state-of-play report draws on a survey launched at the end of 2025 to understand how organisations across industries and company sizes are approaching SBOM adoption. ENISA says the results confirm that the Cyber Resilience Act is acting as an accelerator, with organisations investing in SBOM generation and automation and seeking to integrate SBOMs into the software development lifecycle.
Although the Cyber Resilience Act entered into force in 2024, its main obligations do not apply until December 2027, with vulnerability reporting obligations beginning earlier, in September 2026. Even before full enforcement, the regulation is already influencing vendors that need to show how they manage dependencies, vulnerabilities, and product security throughout the lifecycle.
ENISA’s SBOM adoption report places that change in an operational context. An SBOM is not a control by itself. A component list has limited value unless it is accurate, machine-readable, updated, linked to vulnerability intelligence, and embedded into remediation and supplier-risk workflows. The agency’s finding that organisations are investing in automation is therefore more useful than a simple count of SBOM documents.
The market effect is likely to be felt first in procurement and assurance. Public bodies, regulated operators, and large enterprises increasingly need evidence that suppliers understand what is inside their products. That evidence becomes more valuable when new vulnerabilities emerge in common libraries, development frameworks, package ecosystems, or embedded components. Without reliable component inventories, buyers and operators are left asking vendors whether they are affected, often under incident pressure.
The CRA gives those questions legal and commercial force. Manufacturers of products with digital elements will need to meet security-by-design and security-by-default obligations, while market surveillance authorities will have enforcement responsibilities. Suppliers that cannot produce credible component transparency may face friction in enterprise procurement long before regulators intervene.
Quality remains the hard part. SBOM adoption can become superficial if vendors treat it as a compliance artefact rather than an operational capability. Component names can be inconsistent, transitive dependencies can be missed, versions can drift, and vulnerability data can be noisy or incomplete. Organisations consuming SBOMs also need the capacity to process them, prioritise exposure, and distinguish theoretical vulnerability matches from exploitable risk in their own environments.
The report lands in a market that is still defining what good looks like. Software teams, product security teams, procurement functions, legal teams, and risk owners need shared expectations about formats, frequency, access, and liability. A supplier that hands over an SBOM once a year is not solving the same problem as one that provides continuous, verified component intelligence tied to patching and vulnerability disclosure.
Europe’s regulatory direction is turning software transparency into an assurance requirement. SBOMs are moving from technical inventory work into supplier-risk governance, particularly for products used in critical services, public administration, regulated financial services, healthcare, transport, and industrial environments.
