The EU Cyber Resilience Act countdown: what software makers must prepare
The Cyber Resilience Act attaches security obligations to nearly every product with digital elements sold in the EU: SBOMs, vulnerability handling across the support period, no known exploitable vulnerabilities at release, and documentation to prove it all. Reporting duties arrive before the main deadline, and the capabilities take longest to build, so the preparation window is now.
The EU Cyber Resilience Act is the most consequential piece of software regulation most engineering teams have never read. It is already in force, its vulnerability-reporting obligations arrive first, and its main obligations follow on a fixed deadline. If you sell software or connected products into the EU market, from anywhere in the world, it almost certainly covers you.
Who is in scope
The CRA covers “products with digital elements” placed on the EU market: hardware with software in it, and standalone software itself, commercial open-source distribution included in many cases. The exclusions are narrow, mostly products already covered by sector regimes such as medical devices and vehicles. The realistic default assumption for a software vendor is: in scope.
What it actually requires
Cutting through the legal text, the obligations cluster into four capabilities:
Know your components. Manufacturers must draw up a software bill of materials covering at least the top-level dependencies of the product. In practice, market expectations and conformity documentation quality push toward complete, machine-readable SBOMs generated from real builds.
Handle vulnerabilities for the support period. Identify, remediate, and document vulnerabilities; provide security updates; run coordinated disclosure. This is a standing operational capability, not a policy document.
Ship clean. Products must be placed on the market without known exploitable vulnerabilities and with secure default configurations. Operationally this means a release gate that can actually answer whether the build contains known-exploited issues.
Prove all of it. Technical documentation demonstrating the above, maintained through the product’s life, ready for market surveillance authorities.
There are also reporting duties with sharp timelines: actively exploited vulnerabilities and severe incidents must be reported to authorities within tight windows, and those duties phase in ahead of the main deadline.
Why the deadline is closer than it looks
The deadline pressure is not paperwork, it is capability-building lead time:
- An SBOM pipeline that produces accurate inventories per release takes an engineering quarter to do properly, longer if builds are heterogeneous.
- A vulnerability-handling process that survives an auditor needs tooling, ownership, SLAs, and an audit trail with months of real history behind it.
- The “no known exploitable vulnerabilities” gate requires vulnerability data with exploitation context wired into release automation.
Teams that begin at the deadline will be buying consultancy at panic prices. Teams that begin now get to build these as ordinary engineering work.
A preparation sequence that works
- Classify your products against the CRA categories with counsel, so scope is settled early.
- Stand up SBOM generation in CI so every release ships with a machine-readable inventory. SecuDep produces complete CycloneDX graphs offline.
- Wire exploitation-aware gating: releases blocked on known-exploited findings, with documented exceptions. This maps directly to the shipping-clean obligation.
- Operate vulnerability handling in one place: a tracked queue with SLAs and an immutable audit trail, so the documentation duty becomes an export rather than a project. This is what the SecuNexa dashboard does all day.
- Monitor shipped versions: the support-period duty means knowing when a new disclosure affects a product you released two years ago, without rescanning it. BOMNexa’s drift monitoring exists for exactly this.
The strategic read
The CRA is doing to software what safety regulation did to physical products: making the manufacturer durably responsible for what they ship. Vendors who internalize that early will find the deadline uneventful and will start winning the procurement questions that reference it. Our full CRA compliance guide maps each obligation to the technical evidence, and a demo can show the whole loop running on a real product.