Software Engineering 6 min read

The Cyber Resilience Act and SBOMs: What Applies When

The Cyber Resilience Act turns SBOMs into a manufacturer duty: reporting obligations from Sept 2026, CE requirements from late 2027, and how to prepare.

The Cyber Resilience Act and SBOMs: What Applies When

The Cyber Resilience Act and SBOMs: What Applies When

The EU Cyber Resilience Act turns the SBOM question into a calendar question. Regulation 2024/2847 has been in force since December 2024, and its first sharp deadline hits on September 11, 2026: from that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents. The main obligations, including CE marking, follow on December 11, 2027. Anyone selling software into the EU market, whether device, standalone product or app, should use the time in between. This article sorts out what is actually required and the role the SBOM plays.

Who the CRA applies to

The CRA covers “products with digital elements” placed on the EU market. That scope is deliberately broad: connected devices, operating systems, desktop and mobile applications, and also pure software products offered commercially. Exempt are, among others, SaaS without product character (NIS-2 covers that instead), pure contract development, and open source software provided free of charge outside a commercial activity.

The open source boundary deserves a second look. Anyone monetizing an open source product, say through support subscriptions or an enterprise edition, does fall under the regulation. And whoever builds third-party open source components into their product remains responsible for their vulnerabilities as the manufacturer. Which is exactly where the SBOM enters.

The deadlines at a glance

Three dates structure the rollout. The regulation entered into force on December 10, 2024, which initially just started the countdown. From September 11, 2026, the Article 14 reporting obligations apply: an actively exploited vulnerability must be reported within 24 hours as an early warning to the responsible national CSIRT and to ENISA, followed by an update within 72 hours and a final report. From December 11, 2027, all requirements apply: products need a conformity assessment, CE marking extends to cybersecurity for the first time, and the technical documentation must be complete.

The 24-hour window is organizationally harder than it sounds. It presumes a company can detect that a vulnerability in its product is being exploited, escalate internally and run a rehearsed reporting path. That is a process topic, not a form-filling topic, and processes are not built in the week before the deadline. For readers less familiar with EU regulation: like the GDPR, the CRA is a regulation, so it applies directly in every member state without national transposition.

What the CRA actually says about SBOMs

Annex I Part II obliges manufacturers to handle the vulnerabilities of their products and names as the first measure identifying and documenting the product’s components, including by drawing up a software bill of materials in a commonly used, machine-readable format, covering at the very least the top-level dependencies. The SBOM does not have to be published, but must be available to market surveillance authorities on request, and it is part of the technical documentation.

In practice that means three things. SBOM generation belongs in the build pipeline, because a manually maintained document is outdated at every release. The format should be SPDX or CycloneDX, both “commonly used and machine-readable” in the regulation’s sense. And the SBOM has to be substantively correct, because a parts list that omits components or misstates versions helps neither your vulnerability management nor your position towards market surveillance.

Generating is not enough: reading and using SBOMs

The underestimated half of the duty is usage. The CRA does not just demand a parts list; it demands effective vulnerability handling built on it: knowing what ships in the product, identifying affected components when new CVEs appear, providing updates. An SBOM that sits unread in artifact storage after the build satisfies the letter and misses the point.

That requires being able to actually look at your own documents. Multi-tier products quickly produce cascading SBOM structures across release, components and container images, and at that point you need tooling that resolves the structure. We built SBOM Lens, an open viewer for exactly this, including a quality report along the NTIA minimum elements that surfaces gaps in versions, suppliers and checksums before a market surveillance authority does.

Conclusion

The CRA is not a paper tiger: from September 11, 2026, reporting duties with a 24-hour deadline apply; from late 2027 the CE mark depends on cybersecurity; and the SBOM is locked in as part of the technical documentation. Getting SBOM generation into the pipeline now, checking document quality and rehearsing the reporting process turns a compliance duty into a head start. The regulation text is on EUR-Lex; for implementation in pipeline and process we support you from assessment to working workflow: software engineering at EverBright.

Frequently Asked Questions

When does the SBOM requirement of the Cyber Resilience Act apply?

The SBOM requirement is part of the technical documentation and applies with the main obligations from December 11, 2027. The reporting obligations for actively exploited vulnerabilities apply earlier, from September 11, 2026. Since effective vulnerability handling presumes a current SBOM, generation should be in place well before that.

Does the CRA require publishing the SBOM?

No. The CRA requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies, as part of the technical documentation. It must be provided to market surveillance authorities on request; there is no obligation to publish it to customers or the general public.

Does open source software fall under the Cyber Resilience Act?

Open source software provided free of charge outside a commercial activity is exempt. As soon as a product is commercially exploited, for example through support contracts or an enterprise edition, the obligations apply. Manufacturers embedding open source components also remain responsible for those components’ vulnerabilities in their product.

What are the penalties for CRA violations?

The regulation provides for fines of up to 15 million euros or 2.5 percent of global annual turnover, whichever is higher. Market surveillance authorities can also withdraw products from the market. The more immediate business impact often comes earlier: without CE conformity there is no placing on the EU market from late 2027.

#Cyber Resilience Act #CRA #SBOM #Compliance #Product Security
Share:
Sergej Bardin

Sergej Bardin

CEO · AI Strategy & IT Consulting

Helping mid-sized companies adopt AI and shape their cloud strategy. Focus on practical decisions over hype.

AI StrategyMCPRAGMulti-CloudIT ConsultingMid-Market