Cyber Resilience Act: the reporting clock starts on 11 September

The deadline that arrives before general application

The Cyber Resilience Act entered into force on 10 December 2024 and most of its obligations apply from 11 December 2027. Its calendar has an earlier operational milestone: Article 14 applies from 11 September 2026.

On 27 July, the Commission published its first practical guidance on the Regulation. The guidance is non-binding and does not replace the legal text, but it addresses scope, substantial modification, support periods, reporting and risk assessment. On 31 July, the Commission updated the manufacturer and reporting pages, confirming that the Single Reporting Platform is expected to be operational when the duty starts.

This does not bring every design, conformity and CE-marking requirement forward to September. It means that a specific capability — detect, decide, report and inform — starts earlier and must work against the product catalogue that already exists.

The clock belongs to the manufacturer — the whole chain must be able to trigger it

Article 14’s mandatory duty is addressed to the manufacturer: the person or entity that develops or has a product with digital elements developed and markets it under its name or trademark. A reseller, importer, integrator or customer does not automatically become the manufacturer by receiving an alert.

That distinction does not authorise passivity. An importer or distributor receiving a customer vulnerability report should know the manufacturer, product version and escalation channel. A manufacturer integrating third-party components still has to assess whether a vulnerability is contained and exploitable in its own product.

The decision belongs at product and economic-role level, not in a team label. One group may manufacture its own application, distribute a third-party device and use another service at the same time.

Two triggers, not a CVE list

The first trigger is a vulnerability contained in the product with digital elements that the manufacturer knows is being actively exploited. A CVE, public proof of concept or high severity score alone does not establish active exploitation in the product concerned.

The second trigger is a severe incident affecting product security. The Regulation treats an incident as severe where it affects or can affect the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or has led or can lead to malicious code being introduced or executed in the product or a user’s systems.

The decision record should retain the incoming signal, time, product and version, confirmed reach, exploitation analysis, severity assessment, decision-maker and missing facts. Without this, the deadline becomes an argument from memory during an incident.

24 hours, 72 hours and two different endings

For both triggers, the manufacturer submits an early warning without undue delay and within 24 hours of awareness, followed by a fuller notification within 72 hours. Content grows with the investigation; the first delivery does not require the completeness of the last.

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after the 72-hour notification. The CSIRT may also request an intermediate report.

A parallel track applies: the manufacturer must inform impacted users and, where appropriate, all users, including measures they can deploy. Indiscriminate public disclosure is not automatically synonymous with that duty; reach and detail should be proportionate to risk.

Older products also enter the reporting inventory

The transitional rule is material: Article 14 applies to every in-scope CRA product placed on the market before 11 December 2027. A search starting only with future launches omits the installed base most likely to produce the first real case.

The inventory should answer which versions were made available in which Member States, who still uses them, the support period, relevant components and how impacted users can be contacted. Notification asks for territories and user communication needs reach; neither dataset appears by magic in the first 24 hours.

Inventory inclusion does not settle legal scope. Excluded products or those covered by specific sectoral legislation need a documented decision. The goal is not to label everything in scope, but to prevent decisions without facts.

The Single Reporting Platform receives the report; it does not decide for the company

ENISA manages the Single Reporting Platform, which routes the notification to the coordinating CSIRT endpoint of the manufacturer’s main-establishment Member State and makes it simultaneously accessible to ENISA. The initial CSIRT disseminates it to CSIRTs in territories where the product was made available, subject to strict exceptions.

For the CRA, the main establishment is first the Member State where product-cybersecurity decisions are predominantly taken. If that cannot be determined, it is the establishment with the largest EU workforce. Manufacturers without an EU main establishment follow the Article 14 order covering authorised representative, importer, distributor and user location.

Before the first case, the company should validate access, deputies, out-of-hours contact and a minimum facts package. A credential held by one person or a platform known only to legal is not operational readiness.

A 72-hour exercise that produces evidence

Choose a material product already placed on the market and simulate a third-party-component vulnerability with credible exploitation indicators. The team does not receive every fact at the outset: it must confirm reach, identify territories, decide the trigger, prepare the warning and update the narrative.

The exercise passes only if each decision has an owner and timestamp, a deputy can execute the report, legal does not block on missing technical facts and support can segment users and distribute mitigation without exposing dangerous detail.

Retain the result as a file: scenario, timeline, participants, decisions, message versions, platform fields, gaps, actions and retest. A meeting without artefacts does not demonstrate capability.

Preparation plan to 11 September

The priority is not a long policy. It is making the chain from signal to product, decision, report, mitigation and user executable. Start with the highest-reach or highest-impact products, declare gaps and expand coverage in cycles.

This plan is a Velqory operational recommendation inferred from the Regulation and official implementation pages. It does not replace legal product classification, validation of the competent authority or technical instructions that ENISA and CSIRTs may issue.