CRA reporting deadlines, and the two clocks people get wrong

Two tracks, six submissions

Article 14 sets out two distinct reporting duties. They are easy to conflate because both run on 24 and 72 hours, but they diverge at the end and they are triggered by different things.

Three submissions per track, so six templates to prepare, not three. A product or a checklist that treats “reporting” as a single flow will be wrong whenever the other kind of event happens.

Track one: an actively exploited vulnerability

The trigger is not the existence of a vulnerability. It is a vulnerability in your product being actively exploited. A serious bug nobody is using against your customers is not a reportable event under this track.

Stage one — early warning, 24 hours

Due within 24 hours of becoming aware. Minimal content: it indicates, where applicable, the Member States where you are aware the product is affected. The point is speed, not detail.

Stage two — vulnerability notification, 72 hours

Due within 72 hours of becoming aware — not 72 hours after the early warning. Both clocks start at the same moment, so you have three days total, not four. Content is general information about the product concerned and the general nature of the exploit and the vulnerability.

Stage three — final report, 14 days after a fix exists

Due no later than 14 days after a corrective or mitigating measure is available. It describes the vulnerability including its severity and impact, and where available, information about the malicious actor, plus the security update or other remedy.

Track two: a severe incident

The regulation defines “severe” by effect rather than by scale: an incident that negatively affects your product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions, or that has led or is capable of leading to the introduction of malicious code. You make that judgement about your own product.

Stage one — early warning, 24 hours

Due within 24 hours of becoming aware. Notably, it must say whether the incident is suspected of being caused by unlawful or malicious acts — a judgement you may have to make early and with very little information. Also the affected Member States.

Stage two — incident notification, 72 hours

Due within 72 hours of becoming aware. General information about the nature of the incident and an initial assessment.

Stage three — final report, one month after the notification

Due within one month after the submission of the incident notification. A detailed description of the incident including severity and impact, and the type of threat or root cause.

The coordinator CSIRT may also request an intermediate report at any point between the notification and the final report. That is on request, not on a schedule, so it cannot be planned for beyond having someone available to answer.

The two clocks almost everyone states wrongly

These two are worth reading twice, because both are widely misstated and both errors point in the direction that makes you think you have less time than you do — or, worse, makes you miss a deadline you thought you had already cleared.

The third duty: telling your users

Reporting to ENISA and the CSIRT is not the whole obligation. Article 14 contains a separate duty to inform the impacted users of the product — and where appropriate all users — of the vulnerability or incident and, where necessary, of any risk mitigation and corrective action they can take.

This is the part of the September obligations that produces something customer-facing. It is worth noticing for two reasons:

• It is a real artefact, not a filing. An advisory, written for the people using your product, published or sent when the event happens.
• If you do not, a CSIRT may do it for you. The regulation allows the notified CSIRTs to provide that information to users where they consider it proportionate and necessary. You would rather your customers heard it from you.

The regulation asks for this where appropriate in a structured, machine-readable format that is easily automatically processable. Formats such as CSAF 2.0 exist to satisfy exactly that. Note the hedge, though: the wording is permissive, so machine-readability is something the regulation asks for where appropriate, not an absolute requirement, and anyone telling you a specific format is mandatory is over-stating it.

What “becoming aware” means in practice

Every clock in this article starts at “becoming aware”, and the regulation does not define that moment for you. In practice it means your organisation knew, not that a particular person knew, which has two consequences worth planning for:

• A report can arrive through a channel you are not watching. A researcher emails an address nobody reads; a customer mentions it in a support ticket. The clock is not sympathetic to your internal routing.
• Someone else can tell a CSIRT before they tell you. Anyone may voluntarily report a vulnerability in your product, and the CSIRT then informs the manufacturer. Being told by a regulator is an uncomfortable way to start a 24-hour clock.

The fix is unglamorous: one monitored address that a human reads daily, published in your disclosure policy, with someone accountable for it when they are on leave.

How you actually file

Reports are submitted by hand on ENISA's Single Reporting Platform. There is no API you can wire into your incident tooling. The flow has three steps: log in, select the national CSIRT, then complete and submit.

What that means before an incident:

• An EU Login account, registered in advance, with two-factor authentication set up on a device the filer will actually have with them.
• A named representative for your company, plus a second person as backup. One human with the only login is a single point of failure against a 24-hour deadline.
• A decision about which CSIRT you report to, made in advance. The platform asks for it at registration and again at submission, and the answer is not obvious — it is a separate question with its own rules.

What to do before anything happens

1. Register on the platform. EU Login, two-factor, named filer, backup filer.
2. Settle your CSIRT and write the answer down somewhere the person handling an incident at 2am can find in thirty seconds.
3. Pre-fill six report drafts — three per track — with everything knowable today: your company identifiers, product names and versions, your usual markets, your follow-up contact. On the day you are completing three fields under pressure instead of twenty.
4. Draft your standard advisory text for the user-notification duty, so it is an edit rather than a blank page.
5. Add “file the final report” to your release checklist, and record the date a fix becomes available. That date starts the 14-day clock and nobody writes it down.