Cyber Resilience Act and the software supply chain: security moves into the pipeline

On 11 September 2026 the first operational part of the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847 on the security of products with digital elements, started to apply. From that day on, manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products. The rest of the regulation, with the essential security requirements and CE marking, will apply from 11 December 2027.

Being a regulation, the CRA needs no transposing laws: it applies directly in all Member States.

What changes from September 2026

When a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, it must meet three deadlines:

• 24 hours for an early warning;
• 72 hours for the full notification, with the corrective or mitigating measures taken;
• 14 days for the final report, after the fix is available (one month for incidents).

Reports go through the single platform run by ENISA and reach the competent national CSIRT. A detail many companies underestimate: the obligation also applies to products already on the market, not just new ones.

Who it applies to

The CRA applies to products with digital elements placed on the European market: installable software, applications, firmware, connected devices and software components sold as a product. Pure SaaS services are generally excluded and fall instead under the NIS2 directive. However, remote data processing solutions that a product needs in order to work, such as the backend of an app or a device, do fall under the CRA.

Understanding precisely whether, and which, products are affected is the first step. When in doubt, the assessment should be made with a legal advisor, because the consequences of a wrong classification are real.

The real weak point: dependencies

To meet a 24-hour deadline you need to answer a simple question within minutes: is this vulnerability present in our product?

In most modern software, code written from scratch is a small part of the total. The rest is made of open source libraries, which in turn depend on other libraries. That is where many of the risks concentrate, including supply chain attacks, meaning compromised packages published on purpose to infiltrate other people's projects.

Without an up-to-date inventory, answering takes days. With an automated inventory, a query is enough.

What it means in practice for the pipeline

SBOM generated at every build

The Software Bill of Materials is the list of a product's components, with versions and integrity hashes. The CRA requires manufacturers to draw it up as part of the technical documentation. Generating it automatically at every build, in standard formats such as CycloneDX or SPDX, means it is always aligned with what is actually in production.

Dependency checks before merge

The CI pipeline blocks pull requests that introduce packages with known vulnerabilities (CVEs), abandoned libraries or licences incompatible with commercial use. The problem is stopped before it reaches production, not discovered afterwards.

Continuous monitoring

A library that is safe today may have a CVE published tomorrow. Periodically comparing the SBOMs of released products against vulnerability databases means you find out straight away.

A coordinated vulnerability disclosure (CVD) policy

The CRA requires a clear channel through which researchers and users can report vulnerabilities, and a defined internal process: who assesses the report, who decides whether it must be notified, who prepares and distributes the fix. When you have 24 hours, this process has to be written down and tested before you need it.

Not just compliance

All this has a cost, but it brings benefits that go beyond compliance. Those who know exactly what is inside their software react faster to every incident, update dependencies with less fear and can show customers, with documentation, how they manage security. In tenders and B2B contracts it is increasingly an explicit requirement.

How we work

In the projects we develop, we integrate SBOM generation and dependency checks directly into the CI/CD pipeline, so security becomes an automatic check rather than an extraordinary task before release. For existing products we start with an audit: component inventory, known vulnerabilities, licences and an action plan in order of priority.

Want to know whether your software is ready for the Cyber Resilience Act? Request an audit.

---

This article is for information purposes only and does not constitute legal advice.