Cyber Resilience Act: what becomes mandatory on 11 September 2026, even for products you already sold

When people talk about the Cyber Resilience Act (CRA), one date comes up almost every time: 11 December 2027. That is when most of the requirements in the European regulation become applicable.

Yet for software vendors and connected product manufacturers, a first deadline arrives much sooner. From 11 September 2026, manufacturers must report certain actively exploited vulnerabilities and certain severe security incidents.

And this obligation does not only cover new products placed on the market after that date. It can also cover software and equipment that has been on the market for years.

event_available What changes on 11 September 2026

From that date, a manufacturer who becomes aware of:

• an actively exploited vulnerability in one of its products, or
• a severe incident affecting the security of that product,

must trigger a regulatory notification process.

The first deadline is very short: 24 hours from the moment the manufacturer becomes aware of the situation. A fuller notification must then follow within 72 hours.

These notifications go through the Single Reporting Platform (SRP), set up and operated by ENISA. The European Commission states that the platform will be operational when the obligations start applying, on 11 September 2026.

In other words, the CRA is no longer only a compliance project to prepare for 2027. Part of the regulation becomes operational as early as September 2026.

group Who is affected?

The CRA targets companies that manufacture and sell in the European Union products with digital elements (Article 3 of the regulation).

That notion covers both hardware and software products: applications, locally installed software, operating systems, connected devices, software or hardware components placed on the market separately, and remote data processing solutions that are essential to the product's functioning.

The scope (Article 2) rests on making available on the European market a product whose intended or reasonably foreseeable use involves a direct or indirect, physical or logical, connection to a device or a network.

Not every IT company is therefore automatically in scope. A pure SaaS service, for instance, does not necessarily become a CRA product simply because it is reachable over the internet: online accessibility is not enough, what matters is the combination of a product and remote data processing that is essential to how it works.

A vendor selling software that constitutes a product with digital elements, on the other hand, is clearly in scope.

The confusion between 2026 and 2027

This is probably the most important point to grasp, and the one most companies miss.

For most CRA obligations, products placed on the market before 11 December 2027 benefit from a transitional regime: they are only subject to the new requirements if they subsequently undergo a substantial modification (Article 69(2)).

But the regulation provides an explicit exception for the reporting obligations in Article 14. Article 69(3) states that those obligations also apply to products within the scope of the CRA that were placed on the market before 11 December 2027.

restore 24 hours, 72 hours, 14 days: what exactly are the deadlines?

The CRA distinguishes two situations.

Actively exploited vulnerability

Not every vulnerability has to be reported. The regulation defines an actively exploited vulnerability (Article 3, point 42) as a vulnerability for which there is reliable evidence that a malicious actor has actually exploited it in a system without the permission of its owner.

This distinction matters. A published CVE, or a technically exploitable vulnerability, is not in itself proof that real malicious exploitation has taken place. Without that nuance, a small company would drown in unnecessary reports.

Once the manufacturer becomes aware of active exploitation:

• Within 24 hours: an early warning must be submitted.
• Within 72 hours: a fuller notification, including the available information on the product concerned, the nature of the vulnerability and of its exploitation, and any corrective or mitigating measures already taken or recommended to users.
• Final report: no later than 14 days after a corrective or mitigating measure is available.

Severe incident

The CRA also defines (Article 14(5)) when an incident must be considered severe. That is the case in particular when it affects, or is capable of affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of important data or functions, or when it may lead to the introduction or execution of malicious code in the product or in a user's system.

The timeline is similar:

• 24 hours: early warning.
• 72 hours: notification with a first assessment of the incident and the measures taken.
• One month: detailed final report, counted from the 72-hour notification.

The clock starts when the manufacturer becomes aware of the actively exploited vulnerability or of the incident (Article 14(2) and 14(4)).

That is precisely what makes internal organisation decisive: information reaching support, a developer or a security team must be able to get quickly to whoever decides whether a CRA notification is required.

flag How to report from Belgium

The CRA sets up a common European mechanism: the CRA Single Reporting Platform (SRP).

A manufacturer does not have to notify each Member State where its product is sold. The notification is submitted once, into the platform. It is addressed to the CSIRT designated as coordinator of the Member State corresponding to the manufacturer's main establishment, and made simultaneously available to ENISA, save in the exceptional circumstances set out in the regulation.

For a company whose main establishment is in Belgium, the Centre for Cybersecurity Belgium (CCB) acts as national CSIRT through CERT.be, and will be connected to the ENISA platform to receive CRA reports. The platform must be available from 11 September 2026.

ENISA also indicates that manufacturers' representatives will use an EU Login account to authenticate. It is therefore possible to make sure right now that the people likely to handle a notification have one. ENISA does, however, recommend not starting the registration and validation of a manufacturer in the SRP before you actually have a notification to submit.

checklist What an affected company should prepare before 11 September

There is no need to have completed your entire CRA programme before September 2026. But an affected company should at minimum be able to detect a reportable situation and meet the 24-hour deadline.

Five things can be prepared right now.

1. Identify which products fall within the CRA. List the software, equipment and components your company places on the European market. For each of them, determine whether it constitutes a product with digital elements within the meaning of Articles 2 and 3.
2. Decide who decides that an event must be reported. A developer discovers active exploitation on a Saturday evening: who do they alert? Support receives proof that a customer was compromised through your software: how does that information travel upward? With a first deadline of 24 hours, this responsibility cannot be settled after the incident. Appoint an owner and a backup in advance.
3. Create an internal escalation procedure. At minimum your process should capture the time at which the company became aware of the event, the product and affected versions, the countries where the product is available, the nature of the exploitation or incident, the first mitigating measures, and the information intended for users. These map directly onto the information requested in the 24-hour and 72-hour notifications and in the final report.
4. Prepare access to the platform. Identify the people who will be able to submit a report and make sure they hold a working EU Login account. The day an incident happens is not the best moment to discover how the process works.
5. Plan communication towards customers. Reporting to the authorities is not the only obligation in Article 14. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must also inform affected users and, where necessary, tell them about corrective or risk-reducing measures they can apply (Article 14(8)). This obligation is often forgotten.

policy What is at stake

The regulation provides for administrative fines whose ceiling depends on the nature of the breach.

Failure to comply with the reporting obligations of Article 14 falls under the highest ceiling. Article 64(2) provides for administrative fines of up to 15 million euros or 2.5 % of total worldwide annual turnover for the preceding financial year, whichever is higher. Other breaches fall under lower ceilings: 10 million euros or 2 % for a list of obligations set out in Article 64(3), and 5 million euros or 1 % for supplying incorrect, incomplete or misleading information to the authorities.

For a small company, though, the real stake is less the fine than the demonstration of good faith. A company able to show that it had a process, that it detected the event and that it reported on time is in a very different position from one discovering the obligation after the fact.

compare_arrows And 11 December 2027?

11 September 2026 is only the first major operational deadline of the Cyber Resilience Act.

From 11 December 2027, most of the regulation becomes applicable. Affected manufacturers will notably have to integrate the essential cybersecurity requirements set out in Annex I, carry out a cybersecurity risk assessment, handle vulnerabilities throughout the product's support period, document their conformity and, depending on the product category, follow the conformity assessment procedures laid down in the regulation (Articles 6 and 13, and Annex I).

The calendar can be summed up simply:

• 11 September 2026: be able to detect and report.
• 11 December 2027: your products and processes must meet all applicable CRA requirements.

For products already placed on the market before December 2027, the transitional rules still matter: outside the reporting obligations, the new requirements will generally only apply to those products if they subsequently undergo a substantial modification.

lightbulb Do not wait for 2027 to start

A company preparing its CRA compliance today does not need to have finalised its CE marking, its full technical documentation or its entire vulnerability handling programme by September.

But it does need an answer to a far more urgent question: if we find out tomorrow that a vulnerability in our product is being actively exploited, are we able to decide quickly whether it must be reported, and to send the first notification within 24 hours?

From 11 September 2026, that question stops being theoretical.

If your company also falls under NIS2, the preparation logic is largely shared and a lot of the work overlaps. We published a NIS2 checklist for Belgian companies covering that part.