Regulation (EU) 2024/2847

CRA reporting readiness checklist

What manufacturers should have in place before 11 September 2026, when the Article 14 reporting obligations begin. Twenty-four things to be able to answer yes to. No email required, and useful whether or not you ever use Legalithm.

Scope

Reporting duties attach to a product, so the first question is which products they attach to.

We know which of our products are products with digital elements placed on the EU market.
Each of those products has a named accountable owner.
We know whether we are the manufacturer for each one, including where we place someone else’s component under our own name.

Awareness

Every clock in Article 14 runs from awareness, and awareness is a decision somebody has to be able to make.

We have defined who determines that the organisation has become aware.
That person is reachable outside working hours, and has a named backup.
We understand that awareness is not the same moment as detection, as classification, or as when a scanning tool happened to run.
We record the awareness time when it happens, not when we get round to writing it down.

The first 24 hours

The early warning is due within 24 hours of awareness, to the CSIRT designated as coordinator and to ENISA.

We know who prepares the early warning.
We know what the early warning has to contain, including the Member States where the product has been made available.
We know where the report goes and who has access to file it.
We could do this on a Friday evening, not only on a Tuesday morning.

The first 72 hours

The fuller notification is due at 72 hours and needs information the early warning did not.

Responsibility for the further investigation is assigned, and it is not necessarily the same person.
We can assemble the nature of the exploit, the corrective or mitigating measures taken, and what users can do.
We know who decides how sensitive the reported information is.

The final reports

The two final reports do NOT share a trigger, and assuming they do is the most common way a plan goes wrong.

Actively exploited vulnerability, Article 14(2)(c): no later than 14 days after a corrective or mitigating measure is AVAILABLE.
Severe incident, Article 14(4)(c): within one month after the SUBMISSION of the incident notification.
Our team knows that neither is computable from the awareness time alone.

Evidence

Afterwards, the question is what you knew and when. That is only answerable if it was written down at the time.

We retain when we became aware, and who decided that.
We retain what was known and what was still missing at each stage.
We retain submission timestamps and any reference returned to us.
Those records survive the person who made them leaving.

Practice

A plan nobody has run is a document, not a capability.

We have walked through one scenario end to end before 11 September.
Tuesday, 10:15: we become aware of an actively exploited vulnerability in Product X. We can say what is due, when, and what we are missing.
We know what we could not answer, and we have fixed it.

Running the last item

The Tuesday-10:15 exercise can be done on your own machine. It computes the deadlines from the awareness time you give it, writes nothing, and needs no account:

npx legalithm cra simulate \
  --scenario exploited-vulnerability \
  --became-aware-at 2026-09-15T10:15:00Z

Readiness check in the browser Free session, 3 September All CRA tools