What happened
On 11 September 2026, Cyber Resilience Act Article 14 reporting obligations became applicable to manufacturers of products with digital elements made available in the EU. The scope covers mandatory notification of actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. Manufacturers submit through ENISA’s CRA Single Reporting Platform and select the CSIRT designated as coordinator for the relevant Member State.
The reporting sequence is a 24-hour early warning, a 72-hour notification, then a final report within 14 days after a corrective measure becomes available for an actively exploited vulnerability or within one month after the 72-hour notification for a severe incident. Open-source software stewards become subject to their corresponding reporting obligations on 11 December 2027.
On 12 September 2026, ENISA updated its FAQ and disclosed that the current 72-hour counter can show a notification as overdue before 72 hours have elapsed since awareness. ENISA says the current 72-hour counter calculates a due time 48 hours after submission of the early warning, so the interface can display an overdue status before 72 hours have elapsed since awareness. The legal deadline remains tied to awareness, not the platform display.
The initial CRA Single Reporting Platform release provides no API, so mandatory submissions must be completed through the platform interface. Selecting the wrong CSIRT designated as coordinator can invalidate a notification and require resubmission. Security leaders should therefore test the submission workflow and assign accountable deadline ownership before an incident occurs.
Why this matters now
This is no longer a future compliance programme. The reporting clock can begin as soon as a manufacturer becomes aware of reliable evidence of active exploitation or a severe product-security incident. Security operations, product security, engineering, legal and European regulatory teams therefore need a shared definition of awareness and a hand-off that works overnight, at weekends and during incomplete investigations. Waiting for root-cause confirmation, customer-impact certainty or a finished patch could consume the early-warning window.
The obligation can reach products already on the EU market and can be triggered when exploitation of an older vulnerability becomes known after the start date. That turns asset ownership, release lineage, third-party component visibility and product-market mapping into disclosure controls. The initial lack of an API also means organisations cannot assume their existing incident-orchestration tooling submits the report. A manual platform dependency, incorrect CSIRT selection or inaccessible Assigned Representative account can become a regulatory failure even when technical response is progressing effectively.
The decision for security leaders
Treat the moment reliable exploitation or severe-incident evidence reaches any relevant product, security or engineering function as a controlled governance event. Define who records that timestamp, who determines scope and who can authorise an early warning with incomplete facts. The purpose of the early warning is not to present a finished forensic conclusion; it is to meet the statutory sequence while preserving the ability to update the assessment.
Separate CRA reporting readiness from the broader compliance programme due later. Assign product-market inventory, component lineage, Assigned Representative access and coordinating-CSIRT selection now. Legal should pre-approve the minimum evidence package and uncertainty language. Product security should own technical content, while regulatory or legal leadership owns submission authority and consistency with other incident-notification regimes.
Evidence of closure
- Approved product-scope inventory records EU market status and accountable manufacturer.
- Assigned Representative login succeeds and the coordinating-CSIRT selection is documented.
- Timestamped tabletop shows an early warning prepared within 24 hours.
- Legal approves handling for exploitation known before the start date.
The Security.io assessment
The most consequential weekend change is operational rather than interpretive: the obligation and submission platform are live. Organisations that remain in policy-design mode have no buffer if exploitation evidence arrives today. The greatest near-term weakness is a fragmented awareness chain in which engineering, a researcher, a supplier or a customer knows enough to start the clock but the authorised reporting team learns later.
Products already placed on the EU market can be in scope, and exploitation learned after 11 September 2026 can trigger reporting even when the underlying vulnerability is older. The initial CRA Single Reporting Platform release provides no API, so mandatory submissions must be completed through the platform interface. Selecting the wrong CSIRT designated as coordinator can invalidate a notification and require resubmission. Attribution posture: This is a regulatory implementation development; no threat actor or incident responsibility is at issue.
Questions for the morning meeting
- Who holds authority to submit a CRA notification outside normal European business hours?
- Can product telemetry establish a defensible awareness timestamp for exploitation or severe incidents?
- Which legacy products remain available on the EU market without a named reporting owner?