CRA reporting from 11 Sep 2026: the 24h/72h clock

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents in their products: an early warning within 24 hours, a notification within 72 hours and a final report afterwards. The obligation also covers products already on the market today.

Article 14 reporting is therefore the first CRA deadline with real operational impact – roughly 15 months before the remaining obligations apply on 11 December 2027. For the big picture see our CRA overview.

What must be reported?

Actively exploited vulnerabilities

Not every vulnerability is reportable – only one where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A theoretical finding in a scan report is not enough; a confirmed attack in the wild is – even if it did not hit your own customer.

Severe incidents

An incident is severe if it affects the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions – or if it has led or can lead to malicious code being introduced into the product or users' networks. A compromised update server is a typical example.

The deadline chain

• Early warning (24h): that something happened and, where applicable, which member states are affected.
• Notification (72h): general product information, nature of the exploit or incident, corrective and mitigating measures taken and recommended, and how sensitive the information is.
• Final report: for vulnerabilities no later than 14 days after a corrective measure is available – with description, severity, information on the actor (if known) and update details. For incidents within one month of the 72h notification, including root cause.

Who receives the report?

Reports go simultaneously to the CSIRT designated as coordinator and to ENISA – via a single reporting platform that ENISA is due to set up by the deadline. The competent CSIRT is generally the one in the member state of the manufacturer's main establishment. In Germany, the BSI is envisaged as the central CRA authority.

You must also inform affected users – and, where appropriate, the public – about the vulnerability or incident and mitigation measures, where possible in a structured, machine-readable format (Art. 14(8)).

Legacy products are covered

Under Art. 69(3), reporting obligations apply to all in-scope products with digital elements – even those placed on the market before 11 December 2027. In practice: the controller software you shipped in 2021 becomes reportable in September 2026 if a library inside it is actively exploited.

Relief for micro and small enterprises

Reporting applies to all manufacturers regardless of size. Micro and small enterprises get relief on penalties: they cannot be fined for missing the 24-hour early-warning deadline. The 72h notification and final report remain subject to fines of up to EUR 15 million or 2.5% of worldwide annual turnover.

Prepare a runbook

1. Product and version inventory: which products are on the market and which versions run at customers?
2. SBOM per version: the only way to answer in hours rather than days whether an exploited component is in your products.
3. Signal sources: intake for external reports (security.txt, CVD policy), monitoring of exploit catalogues such as CISA KEV, customer notices.
4. Roles and deputies: who decides, who writes, who informs customers – including at weekends?
5. Templates: text blocks for early warning, 72h notification, final report and customer notice.
6. Drill: run through a real example once before it happens for real.

A reporting case step by step

A fictitious but typical scenario: a building-automation manufacturer learns on a Friday evening from a customer that a vulnerability in an embedded web-server library is being actively exploited. From that moment the clock runs.

1. Hours 0–4: on-call checks via SBOM which product versions contain the library.
2. Hours 4–12: decide whether there is reliable evidence of active exploitation and whether your product is affected.
3. By hour 24: early warning with product, report type and affected member states.
4. By hour 72: notification with details, measures taken and recommendations, e.g. disabling the web interface.
5. Afterwards: develop and ship the patch, inform users – and submit the final report no later than 14 days after the patch is available.

Without an SBOM the first step alone often takes days. That is why an up-to-date component inventory is the most important preparation.

Vulnerability or incident?

What mid-sized firms often miss

• Purchased components: a vulnerability in a supplier's module also makes your product affected.
• Customer information: a separate duty alongside the authority report, requiring prepared channels.
• Documenting the decision: record why you reported – or why not. It protects you in later enquiries.

Nuowei when it counts

Nuowei, currently in beta, links SBOMs to vulnerability and exploit signals and shows which product versions are affected. A guided 24h/72h workflow prepares the reporting data – the decision and submission stay with you. Launch: November 2026, access via the waitlist.