CRA incident reporting: the obligation that binds fifteen months early

The short answer

**Article 14 of the Cyber Resilience Act applies from 11 September 2026.** The rest of the regulation applies from 11 December 2027.

**Fifteen months separate the two dates, and almost every compliance plan treats them as one.** A manufacturer whose product is not yet subject to the full essential requirements can already be subject to the reporting duty — and reporting is the obligation that cannot be prepared retroactively, because it is triggered by an event you do not schedule.

Two triggers, reported to the **CSIRT designated as coordinator** and to **ENISA** through a single reporting platform:

Both follow a staged timeline: **24 hours**, then **72 hours**, then a final report.

• an **actively exploited vulnerability** contained in the product;
• a **severe incident having an impact on the security** of the product.

The two triggers, and why the first is harder

**An actively exploited vulnerability**

Not every vulnerability. Not every serious vulnerability. **One that is being exploited.**

The determination requires evidence that a malicious actor has used the vulnerability without authorisation. That evidence rarely arrives labelled. It arrives as a customer report, an anomaly in telemetry, a researcher's message, or a public post.

**The hard part is not the report, it is the decision.** Someone has to conclude, on partial information and within hours, that what is in front of them meets the threshold. If that decision has no named owner, the clock runs while the organisation decides who decides.

**A severe incident having an impact on product security**

An incident affecting the security of the product itself — including one arising from your own development or distribution environment, where it affects the product placed on the market.

**This reaches build infrastructure.** A compromise of a signing key or an update channel is a product security incident, not only an internal IT incident.

The staged timeline

``` 24 hours early warning what you know, that it is a suspected exploitation or severe incident 72 hours fuller notification general information about the product, the nature of the issue, corrective or mitigating measures where available after that final report full description, and for an incident, the root cause where identified ```

**Twenty-four hours starts from awareness, not from understanding.** The early warning is designed to be sent while facts are incomplete. Organisations that wait for certainty miss the first deadline and then report late twice.

Manufacturers must also, where relevant, **inform impacted users** of the product and, where appropriate, advise them on corrective measures they can take.

What this obliges you to have in place before September 2026

**1. A named owner with authority to notify, and a deputy.** Not a team. A person, reachable, with the authority to send a regulatory notification without convening a committee. **This is the single most common gap**, and it does not appear in any technical review.

**2. A written threshold for "actively exploited".** Decided in advance, in calm conditions. The alternative is deciding it during an incident, under pressure, with commercial consequences visible in the room.

**3. Registered access to the reporting path, tested.** The registration is administrative. Doing it during the first incident costs hours you have budgeted for the report itself.

**4. A vulnerability intake that works from outside.** Article 14 assumes you find out. The most likely way you find out is that **someone tells you** — which requires a published contact address and a coordinated vulnerability disclosure policy, both of which Annex I Part II requires anyway.

**5. A customer notification path.** Informing impacted users is part of the duty. If your only channel to customers is the distributor relationship, the notification depends on a third party's response time.

How this relates to your other reporting obligations

**The CRA duty is separate from NIS2 and DORA reporting, and it can coexist with them.** The same event can be a CRA reportable vulnerability for the manufacturer and a NIS2 significant incident for a customer operating the product in a critical sector.

``` CRA manufacturer reports about the PRODUCT it placed on the market NIS2 in-scope entity reports about ITS OWN service disruption DORA financial entity reports an ICT-related incident to its authority ```

**Different reporter, different subject, different authority.** They are not alternatives, and answering one does not discharge another. The practical implication is that a single event may generate several notifications on several clocks — which is a runbook problem, and it is far cheaper to design once than to discover mid-incident.

What to establish first

1. **Diarise 11 September 2026 separately from December 2027.** They are not the same programme and they should not share a milestone. 2. **Name the notifying owner and their deputy this quarter.** It is free and it is the gap most likely to cost the deadline. 3. **Write the "actively exploited" threshold** and have it reviewed by whoever will be accountable for using it. 4. **Publish the vulnerability contact address and disclosure policy now.** They are required under Annex I Part II regardless, they are verifiable from outside, and they are how you find out in the first place. 5. **Run one tabletop exercise against the 24-hour clock** before the date. The exercise surfaces the decision-rights problem; a document review never does.

Tools available on NexCyber

• Free applicability assessment — confirm CRA scope and product classification
• Compliance responsibility mapper — RACI by role
• Penalty calculator — exposure by regulation

Further reading

→ CRA Article 14: the vulnerability reporting workflow → Coordinated vulnerability disclosure → Handling actively exploited vulnerabilities → What is the Cyber Resilience Act → NIS2 incident reporting timelines → CRA regulation overview

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. The reporting platform, the notification templates and the implementing acts detailing the format and content of the reports continue to be developed — verify against the current text of Regulation (EU) 2024/2847 and the guidance issued by your national CSIRT and ENISA. Consult your competent authority or a qualified adviser.*