TLDR overview
- In the context of CRA, SBOM is the software bill of materials the EU Cyber Resilience Act requires manufacturers to produce as part of a product's technical documentation, listing at least its top-level components so vulnerabilities can be traced and remediated.
- Manufacturers must report actively exploited vulnerabilities and severe incidents from September 11, 2026, starting with a 24-hour early warning; the broader CRA requirements, including the SBOM obligation, apply from December 11, 2027.
- SonarQube Advanced Security generates machine-readable SBOMs in CycloneDX and SPDX formats and continuously scans dependencies against known-vulnerability databases.
The EU Cyber Resilience Act has moved from a future policy concern to a concrete obligation with dates on the calendar. Manufacturers of products with digital elements sold in the EU now face specific requirements for documenting and controlling the software components inside their products, and the software bill of materials sits at the center of those requirements.
This page covers what the CRA requires for SBOMs and component control, who it applies to, and a focused starter plan for closing the most common readiness gaps.
What is a CRA SBOM?
A CRA SBOM is a software bill of materials that manufacturers must produce to satisfy the component-documentation obligations of the EU Cyber Resilience Act, Regulation (EU) 2024/2847. It's a machine-readable inventory of the software components in a product with digital elements, maintained so that vulnerabilities in those components can be identified, assessed, and remediated across the product lifecycle.
The SBOM isn't a standalone deliverable — it's part of a broader duty to identify and document product components as part of the technical documentation manufacturers must maintain and make available to market surveillance authorities on request. Annex I, Part II, point 1 requires manufacturers to identify and document product components and vulnerabilities, including through an SBOM covering at least the product's top-level dependencies; deeper, transitive coverage is common practice for teams that want fuller visibility, but it isn't the regulatory floor.
Modern software is assembled from hundreds of open-source and third-party components, many pulled in indirectly as dependencies of dependencies. The SBOM makes that composition visible to the manufacturer, which is the precondition for knowing whether a newly disclosed vulnerability affects a product at all.
How does the CRA treat components and SBOM?
The CRA treats software components as a first-class security concern, not an implementation detail. Because most vulnerabilities that reach production arrive through third-party and open-source dependencies rather than first-party code, the regulation puts explicit obligations on how manufacturers track, document, and manage those components over time.
Component identification and documentation
The regulation requires manufacturers to know what their products are built from. That means identifying direct dependencies at minimum, and — as good practice — the transitive dependencies pulled in beneath them, then documenting them in a form that can be shared and audited. The SBOM is the mechanism the CRA names for this, with a stated minimum of top-level dependency coverage.
Vulnerability handling across the lifecycle
Component documentation is only useful if it drives action. The CRA obligates manufacturers to address vulnerabilities in their products without delay, which depends on being able to map a disclosed vulnerability to the specific components and releases it affects. An SBOM that is generated once and never updated cannot support this. The inventory has to stay accurate as dependencies change.
Shipping without known exploitable vulnerabilities
Annex I, Part I requires products to be placed on the market without known exploitable vulnerabilities. Component control is how manufacturers meet that bar in practice: continuous checking of dependencies against known-vulnerability data, so a component with a documented exploit does not silently ship inside a release.
Provenance and traceability
Documenting components is inseparable from being able to trace a release back to its exact source, build inputs, and dependencies. Release traceability lets a manufacturer establish precisely which components are present in a given version, which is what makes impact assessment and targeted remediation possible when a vulnerability surfaces.
Who does the CRA reporting obligation affect, and what triggers it?
The CRA applies to manufacturers of products with digital elements made available on the EU market, including manufacturers based outside the European Union. Its scope is broad, covering B2B software products, consumer electronics, connected devices, and components — though the regulation carries specific exclusions, including for non-commercial open-source software and certain already-regulated products such as medical devices and vehicles. If your software reaches the EU market and falls within CRA's product scope, the obligations reach you regardless of where your organization is based.
From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products. The broader CRA obligations, including the essential requirements in Annex I, become generally applicable from December 11, 2027.
An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A severe incident is one that negatively affects a product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive data or functions, or that has led to the introduction or execution of malicious code. Both trigger a staged reporting obligation to the designated CSIRT coordinator and ENISA through the Single Reporting Platform: an early warning within 24 hours of the manufacturer becoming aware, a more detailed notification within 72 hours, and a final report within 14 days (or one month for severe incidents).
For a structured way to gauge how ready your codebase is against these obligations, Sonar's seven questions for assessing Cyber Resilience Act codebase readiness walks through the specific controls, including release traceability and component documentation, that support the September 2026 deadline. A broader view of which industries and products fall under the CRA clarifies who is affected and who is exempt.
Why does SBOM matter for a security-aware setup?
Component visibility is the foundation every other supply chain control depends on. You cannot patch, assess, or report on a vulnerability in a component you did not know your product contained. The SBOM turns an invisible dependency graph into an inventory you can act on.
The stakes are concrete under the CRA. Non-compliance can result in fines up to €15 million or 2.5% of global annual turnover, whichever is higher, for the most serious infringements — such as failing to meet the essential cybersecurity requirements or the Article 14 reporting obligations; other violations carry lower penalty tiers.
Beyond the penalty exposure, the practical risk is time. When a vulnerability like a widely used logging library flaw is disclosed, the manufacturers that can answer "are we affected, and where?" in minutes are the ones working from a current SBOM. Those without one spend days manually auditing codebases while the exploit window stays open.
AI-assisted development sharpens the need. As coding tools and agents increase the volume of code and the dependencies pulled in with it, the component inventory changes faster than manual tracking can keep up. The CRA makes no distinction between human-written and AI-generated code; the manufacturer is accountable for all of it. That accountability extends to every dependency an AI coding tool introduces, which makes continuous, automated component documentation a requirement rather than a convenience. The tools you need for a CRA-ready codebase span code security, software composition analysis, SBOM generation, and dependency governance.
A 30-day component-control starter plan
Component control is achievable on a short timeline if you sequence the work by risk. The goal of this 30-day starter plan is to move from an unknown dependency picture to a documented, monitored, and enforceable one.
Step 1: Establish the inventory
Start by generating an SBOM for your in-scope products so you have a baseline of what each release actually contains. The CRA's floor is top-level dependencies; capturing transitive dependencies too gives fuller visibility and is worth doing where you can, using a standard machine-readable format such as CycloneDX or SPDX so the inventory is portable and auditable. You cannot govern components you have not yet catalogued.
Week 2: Assess component risk
With the inventory in place, check every dependency against known-vulnerability data. Prioritize by exploitability, not just severity, so the components with active exploits or high exploitation likelihood move to the top of the queue. This is where the SBOM starts driving remediation.
Week 3: Enforce at the point of change
Move checks upstream so new risk is caught before it merges. Adding quality gates that block a change when serious dependency findings remain turns component control from a periodic audit into a continuous, preventive control. Apply the same standard to code and dependencies whether they originate from a developer or an AI coding tool.
Week 4: Make it repeatable and evidenced
Wire SBOM generation and dependency checks into your CI/CD pipeline so the inventory regenerates automatically whenever your components change — the CRA requires the SBOM to reflect current composition, and generating it with every build is simply the most reliable way to guarantee that. Retain the analysis history, quality gate results, and remediation records that demonstrate the controls are operating, which is what makes readiness demonstrable at audit rather than asserted.
How can SonarQube help you get your SBOMs in order?
SonarQube brings component documentation, dependency risk analysis, and enforcement into the development workflow, so your SBOM stays accurate as code changes. SonarQube Advanced Security generates machine-readable software bills of materials in CycloneDX and SPDX formats, giving you the traceable dependency inventory the CRA calls for without a separate manual process.
For component risk, software composition analysis continuously scans open-source and third-party dependencies against the NVD, EPSS, KEV, and OSV databases, identifying direct and transitive dependencies along with known risks. Dependency risk governance extends beyond detection to review, status tracking, fix guidance, license-policy enforcement, and malicious-package alerts.
Enforcement runs at the point of change. Quality gates act as a pass-or-fail signal in the CI/CD pipeline, blocking a change when serious security or dependency findings remain, so non-compliant code and components do not reach production. Because the same standards apply to all code, SonarQube holds AI-generated and human-written contributions to a single bar. Analysis history, quality gate results, and remediation records produce the evidence that supports CRA risk-assessment documentation.
Get your SBOMs in order now. Generate a CycloneDX or SPDX SBOM for one of your in-scope products and set up a quality gate that blocks unresolved dependency risk — see SonarQube Advanced Security in action.
Next steps
- Cyber Resilience Act by industry: who is affected and who is exempt? — clarifies CRA scope, exemptions, and key deadlines by industry and product type.
- Tools you need for a CRA-ready codebase — covers the code security, SBOM, and dependency governance capabilities that support CRA readiness.
- Cyber Resilience Act compliance for AI-generated code — explains how SCA, SBOMs, and evidence workflows apply when code is AI-generated.
- Seven questions for assessing Cyber Resilience Act codebase readiness — a control-by-control self-assessment against the September 2026 obligations.
- Software composition analysis — product documentation on identifying dependency risk and generating SBOMs.
- Quality gates — configure the pass-or-fail conditions that block non-compliant changes before merge.