Regulations

CRA reporting deadlines: 24 hours, 72 hours, 14 days

When the Article 14 CRA clock starts, who receives the notification and what each of the three reporting stages has to contain.

Michał Jaśniewski October 24, 2026 8 min read

Since 11 September 2026, the manufacturer of a product with digital elements has 24 hours to send an early warning notification, 72 hours to submit the full notification, and 14 days (for a vulnerability) or one month (for a severe incident) to deliver the final report. The clock does not start when a patch is released or an incident is closed. It starts the moment the manufacturer becomes aware of an actively exploited vulnerability or a severe incident — and that single timestamp decides whether every later deadline can be met. Notifications go to the CSIRT designated as coordinator in the Member State of the manufacturer’s main establishment and, simultaneously, to ENISA. You submit once, through the single reporting platform (SRP).

Two separate clocks, not one

The CRA separates two kinds of event and runs them on two different tracks.

The first is an actively exploited vulnerability. Under Article 3(42), this is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. The reporting obligation sits in Article 14(1) and (2).

The second is a severe incident having an impact on the security of the product — Article 14(3) and (4). The severity criteria are set out in Article 14(5): an incident is severe if it negatively affects, or is capable of negatively affecting, 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 is capable of leading, to the introduction or execution of malicious code in the product or in the user’s network and information systems.

In practice there is one difference, and it is an expensive one: the final stage is counted differently. For a vulnerability, the final report is tied to the availability of a fix. For an incident, it is tied to the date the 72-hour notification was submitted.

What exactly the 24 hours count from

The reference point is becoming aware of the event — not a board decision, and not confirmation from a supplier. If an external researcher’s report lands in your security inbox on Friday afternoon, the clock started on Friday afternoon.

That shifts the weight from the legal text to your process. You need a documented “moment of awareness” for every intake channel: the CVD mailbox, the ticketing system, monitoring alerts, notices from component suppliers.

Without that record you cannot later show that the deadline was met — and the burden of proof is on the manufacturer, because it is the manufacturer who, on a reasoned request from a market surveillance authority, provides the information demonstrating conformity (Article 13(22)).

Stage 1: early warning notification (24 h)

The early warning notification is submitted without undue delay and in any event within 24 hours of becoming aware. It is deliberately brief — a signal, not an analysis.

For a vulnerability, it states the Member States in which, to the manufacturer’s knowledge, the product has been made available.

For an incident, it states at least whether the incident is suspected of being caused by unlawful or malicious acts and, where applicable, the Member States in which the product has been made available.

Stage 2: notification (72 h)

Within 72 hours of becoming aware, the manufacturer submits a fuller notification — unless that information has already been provided.

For a vulnerability, it covers general information about the product, the general nature of the exploit and of the vulnerability concerned, any corrective or mitigating measures taken, and the measures users can take. It also states how sensitive the manufacturer considers the notified information to be.

For an incident: general information about the nature of the incident, an initial assessment, the measures taken, the measures available to users, and the same sensitivity indication.

The sensitivity indication is not a formality. Article 16(2) links it to the possibility of temporarily withholding dissemination of the notification to other Member States’ CSIRTs — in other words, to the real risk that news of an unpatched flaw spreads further than the manufacturer can handle.

Stage 3: final report (14 days or 1 month)

Vulnerability: the final report is due no later than 14 days after a corrective or mitigating measure is available. It contains a description of the vulnerability, including its severity and impact; where available, information on any malicious actor that exploited it; and details of the security update or other corrective measures made available.

Severe incident: the final report is due within one month of the 72-hour incident notification. It contains a detailed description of the incident, including its severity and impact, the likely type of threat or root cause, and the mitigation measures applied and ongoing.

On top of that, the CSIRT designated as coordinator that first received the notification may, under Article 14(6), request an intermediate report on relevant status updates. The interim milestones are therefore not limited to three dates.

Who receives it and how to identify the right CSIRT

You submit once, through the single reporting platform operated by ENISA under Article 16. The platform routes it onward.

The first recipient is the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment (Article 14(7)). ENISA receives the notification simultaneously. The CSIRT that received it first disseminates it without delay to the coordinator CSIRTs of the Member States where the product is available, and national CSIRTs pass the necessary information on to their market surveillance authorities.

The main establishment is the Member State where decisions related to the cybersecurity of the products are predominantly taken. If that cannot be determined, it is the Member State of the establishment with the highest number of employees in the Union.

A manufacturer with no main establishment in the EU works down the cascade in Article 14(7): the Member State of the authorised representative acting for the highest number of its products, then of the importer, then of the distributor, and finally the Member State with the highest number of users. In that last case, subsequent notifications can go to the same CSIRT that received the first one.

For a manufacturer whose main establishment is in Poland, the contact point named on ENISA’s list (updated 10 September 2026) is CERT Polska / CSIRT NASK, through the CVD route at cert.pl.

The duty to inform users

Article 14(8) adds a parallel obligation towards the market, not just the authorities. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer informs the impacted users — and, where appropriate, all users — about the event, the risk, and the available corrective and mitigating measures.

The regulation states that, where appropriate, this information should be provided in a structured, machine-readable format that is easily automatically processable. That opens the door to CSAF/VEX as the format for security advisories, instead of a PDF on a web page.

If the manufacturer fails to inform users in a timely manner, the notified CSIRTs may do so themselves, where that is proportionate and necessary to prevent or mitigate harm. Losing control of the communication about your own vulnerability is a real business scenario here.

What it means operationally

Three things decide whether 24 hours is achievable.

Then there are third-party components. Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component (open source included) to report it to the person or entity maintaining that component. The Article 14 clock does not wait for the supplier’s reply.

Without an up-to-date software bill of materials (SBOM) you cannot answer “does our product contain the vulnerable component, and in which versions?” within 24 hours. That is why the SBOM stops being good practice and becomes a precondition for meeting the deadline — just like vulnerability detection on every code change rather than once a quarter, and a release trail that comes from pipeline records rather than the team’s memory.

If this process isn’t running yet, here is an order that makes sense:

  1. Establish whether you are a manufacturer under the CRA — and for which products (roles explained). That defines the scope.
  2. Build component visibility — an automatic SBOM for every release.
  3. Wire vulnerability detection into the build process — so response time doesn’t depend on who happens to notice an alert.
  4. Define and rehearse the reporting path — who decides, where they report, within what time — before the first real notification is needed.

The dates that anchor your planning

Separately: Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025, sets out the conditions for withholding the dissemination of notifications provided for in Article 16(2).

Sources

For information only, not legal advice. This article covers the technical and process layer of the obligations under Regulation (EU) 2024/2847; full compliance also requires organizational and legal work on your side and does not replace legal advice or a formal conformity assessment. Current as of October 2026.

CRAVulnerabilitiesIncident ReportingRegulations