In twenty days, on 11 September 2026, the Cyber Resilience Act enters its most operational phase. Any organisation that manufactures or publishes a product with digital elements (software, firmware, connected device) will have to report an actively exploited vulnerability to ENISA within 24 hours of detecting it. The single reporting platform will be accessible that day. The deadline is not negotiable: it follows directly from Regulation (EU) 2024/2847, published in the Official Journal of the European Union in October 2024.
What still surprises many teams: the obligation does not only cover products launched after 11 September. It applies to every product already on the European market. A SaaS software sold since 2021, an industrial router deployed in 2019, an open source library embedded in a medical device: if the publisher or manufacturer has its main establishment in the European Union, or sells in Europe from outside it, the obligation applies from the date of entry into force.
What the regulation concretely requires
The reporting mechanism works in three stages. Within 24 hours of detecting an actively exploited vulnerability: an initial report to ENISA through the single reporting platform, stating the nature of the vulnerability and the products concerned. Within 72 hours: a full notification with the impact assessment and the measures taken or planned. Within 14 days of a fix becoming available: a final report documenting the remediation.
The notification goes through a single entry point: the national CSIRT of the country where the company has its main establishment. In France, this is CERT-FR, attached to France's national cybersecurity agency (ANSSI). The information is passed on simultaneously to ENISA, which coordinates at European level. This architecture avoids multiplying contacts: one report, one channel, two automatic recipients.
Penalties for non-compliance reach 15 million euros or 2.5% of annual worldwide turnover. The European Commission estimates that 60% of the manufacturers concerned are SMEs, which means most of the compliance work remains to be done in organisations with no dedicated GRC team.
The prerequisite most teams do not yet have
To report a vulnerability within 24 hours, you must first be able to detect it within that time. This is not trivial. An actively exploited vulnerability may affect an embedded third-party component, such as an open source library, an SDK or a rendering engine, that the publisher does not monitor directly. In its practical guide published on 27 July 2026, the European Commission is explicit: without an up-to-date SBOM (Software Bill of Materials) and a per-component vulnerability monitoring process, compliance is impossible.
An SBOM is the formal inventory of all software components in a product: libraries, direct and transitive dependencies, versions, licences. It makes it possible to know in minutes whether a component announced as vulnerable, for example through a CVE published on the NVD, is present in a product. Without this inventory, the detection chain is blind.
The article on SBOMs under NIS2 and DORA details the generation methods and available tools. For the CRA, the requirement is the same but the scope differs: it covers product manufacturers, not only operators of essential services.
What the 11 September deadline does not yet cover
It is useful to separate what takes effect on 11 September from what is still to come. The September 2026 phase covers only the vulnerability and incident reporting obligations. The requirements on secure product design, in particular the obligation to build in security from the outset, provide compliant technical documentation and carry out a conformity assessment, apply from 11 December 2027, for new products placed on the market on or after that date.
This does not mean design requirements can wait until 2027. The conformity assessment bodies (CABs) were designated in June 2026: publishers of products classified as "important" or "critical" under the CRA can already submit their products for assessment. The first certified products will be in a strong position to respond to public tenders and to the purchasing requirements of large groups, which have already built the CRA into their supplier qualification grids.
Three actions to start in the next twenty days
Map the products within the CRA scope. The regulation covers products with "digital elements" placed on the European market. The notion is broad: software sold under licence, a SaaS service with a standalone software component, a connected device. The exclusion covers software developed exclusively in-house and never placed on the market. For each product in scope, identify who is responsible for notification: it is the manufacturer or publisher, not the distributor.
Set up or audit the vulnerability management process. The chain must cover: monitoring of sources (NVD, CERT-FR, CVE lists for the components used), correlation with the SBOM to identify affected products, a 24-hour decision procedure (who validates, who notifies, through which channel), and a traceable register of notifications issued. ENISA published a notification template on its website in July 2026. Testing it before 11 September avoids discovering it under pressure.
Appoint a regulatory point of contact. The notification must come from an identifiable person. The CRA does not require a dedicated function, but the process must be documented: who is the CERT-FR contact, who signs the notifications, who ensures continuity in case of absence. In an SME, this may be the CISO or IT director; in a large organisation, the PSIRT (Product Security Incident Response Team).
What this changes for buyers of digital products
The CRA does not concern manufacturers alone. Organisations that buy digital products (software, connected equipment, SaaS platforms with an on-premise component) have a direct interest in checking that their suppliers comply. A supplier that does not meet the notification obligation is a supplier that will not inform you in time of a vulnerability affecting your infrastructure.
Procurement teams and GRC teams would benefit from adding a CRA clause to their supplier questionnaires now: does the supplier have an SBOM for the products delivered? Does it have a notification process that complies with the CRA? Has it tested that process? These questions overlap with NIS2 obligations on the supply chain and DORA requirements on ICT providers: they do not duplicate them, they complement them.
Conclusion
11 September 2026 is not a symbolic date. It is the first operational milestone of the CRA, the point at which reporting obligations become enforceable for all products already on the market, under penalty of significant sanctions. ENISA has opened its portal. CERT-FR is ready to receive notifications. The question is no longer whether your organisation is concerned, but whether it can meet the 24-hour deadline.
Setting up an SBOM and a vulnerability management process is not a multi-month project: teams that started in June 2026 completed it in six to eight weeks. For organisations that have not started, twenty days are enough to at least map the scope and appoint those responsible: the minimum conditions to avoid a missed notification at the first incident.