Monday morning, 8 am. A security researcher emails your vulnerability reporting address. They have found a remote-code-execution vulnerability in one of your products. They attach working proof-of-concept code and say attackers are exploiting the flaw. Your product security team reproduces it before midday.
Does legal now have 24 hours to report it under the EU Cyber Resilience Act (CRA)? Not necessarily.
Since 11 September 2026, has required manufacturers to report certain cybersecurity events affecting products with digital elements. Manufacturers must submit an early warning about an actively exploited vulnerability within 24 hours of becoming aware of it.
The difficult part is deciding what the manufacturer has actually become aware of.
When does CRA vulnerability reporting start?
The CRA distinguishes a vulnerability from an actively exploited vulnerability.
An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited the vulnerability without the system owner’s permission.
The European Commission gives a useful example in its . If an ethical hacker discloses a zero-day through a bug-bounty programme, Article 14 does not require reporting where there is no evidence of previous malicious exploitation.
A vulnerability can therefore be serious, easy to exploit and urgently require a patch without yet meeting the Article 14 reporting test.
A working proof of concept may show that the flaw can be exploited. However, it does not necessarily show that somebody has exploited it maliciously in a real system.
Ask security for evidence, not only a severity score
A high Common Vulnerability Scoring System (CVSS) score helps describe technical severity. However, it does not establish the CRA reporting trigger.
The Exploit Prediction Scoring System (EPSS) answers a different question. It estimates the probability that exploitation will be observed in the wild. Therefore, it still does not prove that exploitation has occurred.
For CRA vulnerability reporting, legal needs to establish:
-
which product and version is affected;
-
whether the manufacturer has made it available on the EU market;
-
whether the vulnerability can be exploited in that product;
-
what evidence indicates malicious exploitation;
-
how reliable the evidence is; and
-
when the organisation received it.
Third-party components make this especially important. If attackers actively exploit a component vulnerability and the same vulnerability is exploitable in the finished product, the manufacturer may have to report it.
If attackers cannot exploit it in that product, it is not an actively exploited vulnerability of that product for mandatory reporting purposes.
This also matters when dealing with suppliers and .
Forwarding a Common Vulnerabilities and Exposures (CVE) number to legal is therefore not enough. Product security may need to establish whether the vulnerable code is present and practically exploitable.
When did the manufacturer become aware?
Article 14 starts the 24-hour period when the manufacturer becomes aware of the actively exploited vulnerability.
The CRA does not specify exactly how that awareness occurs. The Commission says it may arise through customer or partner reports, security researchers, threat intelligence, telemetry and other sources.
For CRA vulnerability reporting, this timing matters.
For example, a researcher may send a report to customer support on Friday, but security may only see it on Monday.
Alternatively, the initial report may contain a proof of concept but no evidence of malicious exploitation. A customer might later supply logs suggesting successful exploitation.
Those facts may produce different answers about when the manufacturer had enough information to recognise a reportable event.
The law does not say that awareness occurs only when the CISO, general counsel or product security team formally declares an event reportable. Equally, a bare allegation sent to any employee should not automatically count as proof of an actively exploited vulnerability.
In practice, the safer response is to record the evidence and its timing carefully.
A case that does not meet the actively exploited vulnerability threshold may still trigger the CRA’s separate reporting obligation for severe incidents affecting product security.
Initial triage should therefore consider three outcomes: an actively exploited vulnerability, a severe incident, or neither.
CRA vulnerability reporting can affect non-EU manufacturers
A South African software or hardware manufacturer selling an in-scope product into Europe may need to make the same Article 14 decision. That remains true even if its product security and legal teams sit in South Africa.
The same event may also trigger South African duties. For example, POPIA may apply if exploitation caused unauthorised access to or acquisition of personal information under the organisation’s control.
The CRA and POPIA ask different legal questions. Therefore, do not collapse them into one generic cyber-incident assessment.
CRA vulnerability reporting does not require a completed investigation
Once the Article 14 trigger applies, the manufacturer follows a staged reporting process.
For an actively exploited vulnerability, the manufacturer must submit an early warning within 24 hours of becoming aware. A fuller notification follows within 72 hours. The manufacturer must submit a final report no later than 14 days after a corrective or mitigating measure becomes available.
The manufacturer should therefore not wait for engineering to complete its root-cause analysis or release a patch before making the early warning.
Manufacturers submit notifications through ENISA’s .
Create a CRA vulnerability triage record
The practical control is a time-stamped record joining the product security process to the legal reporting process.
It should capture:
-
the original report and time received;
-
the affected product, version and component;
-
evidence of exploitability and malicious exploitation;
-
the source and reliability of that evidence;
-
when the organisation received it;
-
the Article 14 classification;
-
the reporting decision and reasons; and
-
mitigation, remediation and parallel reporting duties.
The CRA does not prescribe a document called a ‘CRA vulnerability triage record’.
However, the reason to have one is practical. Twenty-four hours is not enough time to invent the relationship between support, product security, engineering and legal.
The record can also form part of your wider process.
Actions you can take next
Article 14 is also part of a wider shift towards cyber resilience. Regulators increasingly expect organisations to show more than preventive security controls.
They also expect organisations to detect problems, decide quickly, respond, recover and produce evidence of what they did.
For manufacturers, the CRA applies this thinking across the product lifecycle. Other regimes apply similar resilience principles to financial institutions, digital infrastructure and AI systems.
Before the next vulnerability report arrives:
-
Identify which products and legal entities may fall within Article 14.
-
Make sure support, security and engineering teams can escalate reports quickly.
-
Agree on what technical evidence legal needs to assess active exploitation.
-
Create a CRA vulnerability triage and decision template.
-
Allocate responsibility for ENISA reporting and appoint backups.
-
Test the process using a realistic vulnerability disclosure scenario.
CRA vulnerability reporting is not simply about whether you have a vulnerability. The real question is whether your evidence has crossed a legal reporting threshold, and whether your organisation can recognise that moment.
