The CRA Reporting Clock Started on 11 September — And Most Manufacturers Are Measuring It Wrong

On 11 September 2026 the reporting obligations under Article 14 of the EU Cyber Resilience Act became applicable, and ENISA switched on the Single Reporting Platform that manufacturers must use to meet them. The deadlines themselves are not new information — they have been in the legal text since 2024. What is new is that they are now operative, and that the operational detail of how they are met has finally been published in enough depth to test a programme against.

Most of the commentary has settled on the number 24. That is the least interesting part of this.

What is actually in scope

Manufacturers of products with digital elements must notify two things: actively exploited vulnerabilities — defined as vulnerabilities for which there is reliable evidence that a malicious actor has exploited them in a system without the owner's permission — and incidents having a severe impact on the security of the product. Three filings follow: an early warning within 24 hours of becoming aware, a fuller notification carrying an initial assessment within 72 hours, and a final report no later than 14 days after a corrective measure becomes available for a vulnerability, or one month after the 72-hour notification for a severe incident.

Two boundaries matter. Open-source software stewards do not come into scope until 11 December 2027. And there is no retrospective sweep: awareness of active exploitation that you already held before 11 September 2026 does not trigger a filing, but awareness acquired after that date does — including where the underlying vulnerability was already well known.

The clock starts on awareness

This is the point that breaks most existing processes. The trigger is not patch availability, not internal confirmation, not a severity score crossing a threshold. It is the moment the manufacturer becomes aware. The controlled variable in your compliance posture is therefore who inside the organisation is permitted to conclude that reliable evidence of exploitation now exists, and how quickly that conclusion reaches someone with authority to file.

In practice, awareness tends to arrive through a support ticket, a researcher email, a customer incident call, or a threat-intelligence feed — not through the security operations centre. Where those channels lack a defined escalation path with a named owner and an out-of-hours route, the 24-hour window is spent on internal routing rather than on assessment. Organisations that have already run NIS2 or DORA reporting know this discipline. The CRA extends it to product and support teams that have rarely had a regulatory clock attached to their work.

Three launch-phase constraints to plan around

• No API. ENISA has confirmed there is no programmatic submission interface in the initial release. Internal workflow can be automated up to the point of filing, but a human assigned representative has to complete the notification in the portal. Named, trained, reachable people are a control here, not a convenience.
• The 72-hour counter currently runs fast. In the present release the platform calculates the 72-hour due date as 48 hours after the early warning is submitted, rather than 72 hours after awareness. A notification can therefore display as overdue before the legal deadline has passed. ENISA has said this will be corrected in a later release. Until then, keep your own authoritative record of the awareness timestamp: the platform counter is a reminder, not the deadline.
• Access depends on personal accounts. Assigned representatives register using EU Login with multi-factor authentication, and those accounts are personal rather than corporate. There is one primary representative per manufacturer and up to twenty secondary ones. The representative-to-manufacturer association is validated by a national CSIRT, though notifications may be submitted while validation is pending — up to twenty of them.

The determination most manufacturers have not made

Notifications go to a single CSIRT designated as coordinator, selected by the manufacturer, and choosing the wrong one can invalidate the notification and force a resubmission. The default test is the Member State of your main establishment in the EU — defined, notably, as the place where decisions relating to the cybersecurity of your products are predominantly taken. That is not necessarily where the legal entity sits, where the largest office is, or where engineering headcount is highest.

It is a governance question dressed as a jurisdictional one, and answering it honestly tends to expose whether product security decision rights are documented anywhere at all. Make the determination now, record the reasoning, and have it reviewed — not at hour three of an incident.

A reasonable thirty-day list

• Name the primary assigned representative and at least two deputies, and complete EU Login and MFA enrolment before it is needed.
• Document the main-establishment determination, the coordinating CSIRT it points to, and the evidence behind both.
• Define in writing what reliable evidence of exploitation means for your products, and who is authorised to declare it.
• Map every inbound channel through which awareness could arrive, and attach an escalation route with an out-of-hours path to each one.
• Run a single tabletop on a third-party component scenario, and record the awareness timestamp exactly as you would in a real filing.

Reporting regimes are judged on the quality of what arrives in the first twenty-four hours. The CRA's contribution is that it attaches that judgement to products, and therefore to engineering and support functions that have rarely sat inside the compliance perimeter. Submitting the notification is the easy part. Deciding quickly and defensibly that the duty has been triggered is the part worth rehearsing.