Exploitable is not exploited

The Cyber Resilience Act applies in full only from 11 December 2027. One duty under it, however, takes effect on 11 September this year: the manufacturers' reporting obligation. And it reaches further than the rest of the regulation. Products placed on the market before December 2027 are in principle exempt from the product requirements as long as they are not substantially modified. From the reporting duty they are not. The text says so explicitly.

The deadline is 24 hours from awareness. The more interesting question is what exactly one must have become aware of.

Three kinds of vulnerability, one reporting duty

Article 3 defines three terms that tend to blur in everyday use. A vulnerability is a weakness that can be exploited by a cyber threat. An exploitable vulnerability is one that can be effectively used by an unauthorised third party under practical operating conditions. And an actively exploited vulnerability is one for which reliable evidence exists that a malicious actor has exploited it in a system without the system owner's permission.

Only the third triggers a report. Three elements must come together: reliable evidence, a malicious actor, and no permission from the system owner. That last element rules out your own penetration test, even where it successfully exploits the very same gap.

Why this is not hair-splitting

Treat the second stage as the third and you report too much. Fail to track the difference at all and you notice too late that the clock has been running.

You can see the boundary in our CSAF import. It reads the threat section out of security advisories and derives from it whether an exploit is available. That is a heuristic over free text, looking for phrasings such as "known exploit" or "proof of concept". The result has three states, and the third matters most: no statement. An advisory without any note on exploitation status yields not a no, but a nothing.

More importantly, that value sits on the second stage, not the third. An available proof of concept shows that a vulnerability is exploitable. It does not show that anyone has exploited it. The decision whether the 24-hour clock is running remains a human one.

The chain that follows, and it is split in two

Once the case is identified, the report goes simultaneously to the competent CSIRT and to ENISA, via a single reporting platform. From there two strands run in parallel, one for vulnerabilities and one for severe security incidents. Both begin with an early warning within 24 hours and a substantive notification within 72 hours.

The final reports differ, and the difference matters in practice. For a vulnerability it is 14 days, counted from when a corrective or mitigating measure becomes available. For an incident it is one month, counted from the 72-hour notification. One deadline hangs on your own development work, the other sits fixed in the calendar.

Severe is defined, not estimated

For incidents the regulation spares you the argument about damage thresholds. An incident is severe if it adversely 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 to the introduction or execution of malicious code. In both cases it suffices that it can. The conditional is in the regulation, not in our reading of it.

One field carries the whole chain

In the CRA module an incident is flagged as reportable, and exactly one entry is mandatory in doing so: the moment of becoming aware. The deadlines are computed from it, it receives its own reference number, and each of the three reporting stages carries its own status. If someone later asks why the early warning went out at this moment and no other, the answer hangs on that single field.

What the module does not do today belongs in the picture: transmission to the single reporting platform is not connected, because that interface is still being built. Until then the module produces the content for each stage for export and manual reporting. That is a difference worth knowing before relying on an automation that does not yet exist.

The question before that, whether a report is owed at all, is not one the module answers on its own either. It arises from vulnerability management, which matches advisories against the asset inventory, and from the judgement a person draws from it.

The date sits with its legal source in the compliance calendar. Why a register has to maintain such obligations at article level was covered here yesterday. Product-related context, not legal advice. What governs is Regulation (EU) 2024/2847.