Cyber Resilience Act: what the regulation imposes on software, and since when

In brief:

• From 11 September 2026: any publisher of a product with digital elements must notify ENISA of actively exploited vulnerabilities and serious incidents. The deadlines are an alert within 24 h, a notification within 72 h, then a final report within 14 days after a patch is made available.
• From 11 December 2027: placing on the European market will be subject to the requirements of the regulation. These include security by design and by default, the absence of known exploitable vulnerabilities, a software component inventory (SBOM, Software Bill of Materials), security patches for at least five years after initial commercialisation, and a coordinated vulnerability disclosure policy, which allows third parties to report a flaw.

As a tech and AI partner for over 800 companies, Galadrim designs and maintains numerous software and applications. On these projects, our engineers already apply the good practices that the Cyber Resilience Act (CRA) now makes mandatory: security by design, secure development, dependency management, vulnerability monitoring, rapid deployment of patches, and maintenance of security conditions. However, these practices remain uncommon, and many applications will need to be brought into compliance. This responsibility falls to the publisher, i.e., the company that markets the product under its name, which the regulation calls the manufacturer.

A simulator, further down the article, will tell you if your product is affected.

What the CRA requires of a digital product

The Cyber Resilience Act is a European regulation, directly applicable like GDPR. It was adopted by the European Parliament on 12 March 2024. It is the first European text to impose cybersecurity requirements on all "products with digital elements".

Only reporting has been in force since 11 September 2026; security requirements will apply on 11 December 2027.

From 11 September 2026: the reporting obligation

The publisher must report two types of events:

• an actively exploited vulnerability, i.e., one for which reliable evidence shows that a malicious actor has used it to compromise a system;
• a serious incident, i.e., an event that threatens the protection of data and product functions, or introduces malicious code into them.

Notification must be made on the ENISA’s single reporting platform. From the identification of the incident or vulnerability, you are required to comply with these deadlines:

• 24 h: early warning;
• 72 h: detailed notification, including the nature of the exploitation, corrective measures, and recommended measures for users;
• final report: 14 days after a patch is made available for a vulnerability, or one month after notification for an incident.

The publisher must also inform affected users of the vulnerability or incident, and of the measures to be applied to protect themselves, in a structured and machine-readable format.

Meeting the 24 h deadline requires knowing at all times which product versions are deployed and what components each includes, supervising the backend to detect an exploitation, and having a reporting procedure with a designated person in charge.

Do you want to prepare, or has your product been affected by a flaw? Our teams help you organise to report and correct within deadlines. Speak with our experts

From 11 December 2027: security requirements

The publisher will only be able to place on the market a product compliant with the regulation's requirements. They will need to:

• design a product secure by default: secure configuration from installation, reduced attack surface, access and data protected by authentication, encryption, and logging;
• deliver a product without known exploitable vulnerabilities, which must be verified across all embedded dependencies, not just on internally developed code;
• maintain an SBOM, the machine-readable inventory of product components;
• correct any vulnerability upon discovery, through free security updates distinct from functional evolutions;
• distribute these updates securely, for example, signed so that the device verifies they genuinely come from the publisher;
• ensure this monitoring for at least five years after initial commercialisation;
• publish a coordinated vulnerability disclosure policy: a point of contact and a procedure for third parties to report a flaw.

These best practices are those we apply to the software we develop and maintain.

Why compliance is primarily a technical project

Dependencies. An application embeds hundreds of open-source components, from language to libraries. Each can introduce a vulnerability, by error or intentionally during a supply chain attack (supply chain attack). Once known, the vulnerability can be automatically exploited on all un-updated versions: the PHP2Shell vulnerabilities, published on 21 October 2026, were exploited as soon as they were disclosed. On an old project, patching often requires upgrading a framework that is no longer maintained.

Continuous monitoring. Throughout the support period, published vulnerabilities (CVE, CERT-FR advisories) must be monitored for each component.

With the rise of AI in development, the volume of code produced increases, and AI-assisted analysis tools detect vulnerabilities faster and faster. The bottleneck becomes correction: triage, correct, test, and deploy across all circulating versions before exploitation.

We can implement these practices on your product or support your teams. Speak with our experts

Is your product affected?

The CRA applies to products with digital elements sold or distributed in the European Union as part of a commercial activity. A product is affected if the user installs software on their device. This is the case for a mobile application, a desktop application, a browser extension, software deployed on the client's servers, or embedded software of a connected object. Servers essential for the functioning of this software are also affected, for example, the backend of a mobile application or its payment module. Excluded are:

• web applications used only in the browser, with nothing to install, unless they are essential for the functioning of an affected software;
• software developed and used exclusively internally;
• products subject to sectoral regulation: medical devices, vehicles, certified aeronautics, marine equipment, and defence.

The company that markets the product is responsible for its compliance, but the service provider in charge of its development also has obligations: to provide the SBOM, correct vulnerabilities within deadlines, and ensure support for the planned duration.

For a product already on the market, reporting applies from today. The 2027 requirements will only apply in the event of a substantial modification after 11 December 2027, i.e., an evolution that changes the product's intended use or affects its compliance. Security patches are not included.

Failures can result in a fine of up to €15M or 2.5% of global turnover, and the withdrawal of the product from the market.

Simulator: Is your product affected?

Answer four questions to find out if the CRA applies to your product.

Beyond this diagnosis, we support companies throughout their compliance process, from audit to vulnerability correction. Speak with our experts

Glossary

• Flaw : a vulnerability in a computer system that allows an attacker to impair its normal functioning, or the confidentiality or integrity of the data it contains (ANSSI).
• Vulnerability : a weakness or defect in a product that can be exploited by a threat.
• Actively exploited vulnerability : a vulnerability for which reliable evidence shows that a malicious actor has used it without the system owner's authorisation.
• Serious incident : an event that compromises, or may compromise, the availability, integrity, or confidentiality of a product's data or functions, or that introduces malicious code into it.
• SBOM (Software Bill of Materials) : a formal inventory of software components, their versions, and their dependencies.
• CVE (Common Vulnerabilities and Exposures) : a standardised public identifier assigned to a known vulnerability.
• ENISA : The European Union Agency for Cybersecurity, which operates the CRA reporting platform.
• CSIRT : computer security incident response team. In France, CERT-FR, operated by ANSSI, is the national CSIRT (ANSSI).
• CI/CD (continuous integration and continuous deployment) : an automated chain that tests and then deploys every code modification to production.

About the author

Harold Stern is a Cybersecurity and Compliance Expert at Galadrim. He is developing this offering, alongside the application security team.