The CRA's First Hard Deadline
24-Hour Vulnerability Reporting from September 2026

Most coverage of the EU Cyber Resilience Act fixes on December 2027 — the date from which products with digital elements must be CE-marked to be placed on the European market. We covered that full timeline in our guide to what manufacturers need to do before December 2027. But there is an earlier deadline that asks something quite different of an organisation, and it arrives first.

From 11 September 2026, Article 14 of the CRA requires manufacturers to report actively exploited vulnerabilities and severe incidents to the EU within strict, short timeframes. This is the regulation's first obligation with genuine operational teeth. CE marking is a project with a fixed end state you can prepare for over months. Incident reporting is a capability that has to exist, staffed and rehearsed, on the day an incident happens — because the clock starts the moment you become aware, not when it suits you.

What Triggers a Report

Article 14 creates two reporting streams, and it is important not to over-read the obligation. It is not a duty to report every vulnerability you discover. It applies to two specific triggers:

• Actively exploited vulnerabilities (AEV). A vulnerability in your product that a malicious actor is exploiting in the wild. "Actively exploited" sets a real bar — it requires reliable evidence that an attacker has exploited the vulnerability in a system without authorisation. A public proof-of-concept, a security researcher's demonstration, or mere disclosure is not, on its own, active exploitation.
• Severe incidents. An incident having an impact on the security of the product with digital elements.

The distinction matters because it protects legitimate security research — the goal is to surface real-world threats to the EU market, not to penalise responsible disclosure. But it also means someone in your organisation must be able to make the "is this active exploitation?" judgement quickly and with authority, because that judgement starts the clock.

The Reporting Cascade

Once the trigger is met, both streams follow the same front end and then diverge on the final report. The timeline runs from the moment of awareness:

• Within 24 hours
  Early warning
  An early-warning notification flagging the actively exploited vulnerability or severe incident, including — where available — whether you believe it is the result of unlawful or malicious action.
• Within 72 hours
  Vulnerability / incident notification
  A fuller notification with general information about the product, the nature of the exploit or incident, its severity and impact, and any corrective or mitigating measures taken or available.
• 14 days / 1 month
  Final report
  For an actively exploited vulnerability: within 14 days of a corrective or mitigating measure becoming available. For a severe incident: within one month of the 72-hour notification. The final report covers a description of the issue, severity and impact, root cause, and the mitigations applied.

This is a more precise picture than the flat "24h / 72h / 14-day" shorthand that circulates online. The 14-day final-report clock for vulnerabilities does not start at awareness — it starts when a fix or mitigation is available, which is a deliberate acknowledgement that root cause and remediation take time. Severe incidents follow a separate one-month track for the final report.

One Platform, One Filing: The ENISA SRP

The mechanism for all of this is the Single Reporting Platform (SRP), a central electronic system that ENISA is required to establish under Article 16 of the CRA. The practical promise of the SRP is significant: you report once. You do not file separately in each of the 27 member states where your product is available. Your single submission is routed to the CSIRT (Computer Security Incident Response Team) designated as coordinator for your situation, and is made accessible to ENISA at the same time. The receiving CSIRT then disseminates to the other affected CSIRTs across the EU.

Why This Lands on Australian Exporters — and Where You Report

It is tempting for an Australian manufacturer to assume the EU's reporting machinery is somebody else's problem. It is not. If you place a product with digital elements on the EU market, Article 14 applies to you regardless of where you are based — and the Act spells out exactly which national CSIRT you report to when you have no establishment inside the Union.

For a manufacturer with no main establishment in the EU — which describes most Australian exporters — the coordinator CSIRT is determined by working down this order until one applies:

1. The member state where your authorised representative acting for the highest number of your products is established;
2. failing that, the member state where the importer placing the highest number of your products on the market is established;
3. failing that, the member state where the distributor making the highest number of your products available is established;
4. failing that, the member state where the highest number of users of your products are located.

The takeaway is that the identity of your reporting authority depends on how your EU route to market is structured — your authorised representative, your importers, your distributors. This determination only needs to be made once, and it is far better made calmly now than reconstructed under a 24-hour clock during a live incident. The EU CSIRTs Network maintains a public map of national CSIRTs you can use to identify the specific contact once you have worked out the member state.

What "Ready" Actually Means

Article 14 does not, by September 2026, require you to have built the full product-security and vulnerability-handling programme that Article 13 mandates from December 2027. What it requires is the narrower — but non-trivial — ability to detect a reportable event and get a compliant notification out the door on time. In practice, that means having the following in place before the first incident:

• A designated reporter and a deputy. A named person who files the notification, with a defined backup for when they are unavailable. "Someone will handle it" is not a process.
• An escalation and decision path. Clear authority over who decides that a signal qualifies as "actively exploited," because that decision starts the 24-hour clock.
• Your coordinator CSIRT identified. Worked out in advance using the order above, mapped to your actual EU route to market.
• SRP registration completed once ENISA's onboarding mechanics go live, so you are not registering for the first time mid-incident.
• A coordinated vulnerability disclosure (CVD) channel. A monitored point of contact so researchers and users can tell you about a vulnerability — often how you become "aware" in the first place.
• Awareness of overlapping duties. A single event can trigger reporting under the CRA and, for organisations that are also essential or important entities, under NIS2 — with different timelines and different recipients. Map these together, not separately.

None of this is exotic, but it crosses engineering, legal, and executive lines, and it has to be agreed and rehearsed in advance. Understanding the full chain of containment, notification, and recovery costs that follows an incident makes the internal case for building this capability far easier to argue — our note on what happens when a business is hacked sets that chain out.

The Penalty Backdrop

Reporting failures sit in the CRA's most serious penalty tier — up to €15 million or 2.5% of global annual turnover, whichever is higher. For an exporting product business, that is not a rounding error, and it attaches to a failure that is entirely within your control to prevent. Australian manufacturers selling into the EU should also confirm whether their cyber insurance responds to European regulatory investigation and enforcement — most domestic policies do not address it explicitly.

Where to Start

The work splits cleanly. The reporting capability above is the September 2026 priority and the more urgent of the two CRA deadlines. The broader secure-by-design, technical-documentation, and conformity-assessment programme is the December 2027 priority, and the more substantial body of work — but it does not have a functioning incident-response process as a prerequisite the way September does.

A structured readiness assessment is the most efficient way to find out where you actually stand against both. Reviewing your organisation's processes against the CRA's requirements — who reports, to which CSIRT, through what channel, against which deadlines, with what evidence — turns the regulation from an abstract obligation into a gap register and a prioritised plan, and starts building the documented record an enforcement authority would expect to see.