The EU Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, introduces mandatory cybersecurity requirements for products with digital elements, ranging from software applications and connected devices to embedded components. Its goal is to ensure that products are secure by design, secure by default, and remain secure throughout their lifecycle.

While the CRA entered into force on 10 December 2024, its obligations apply in phases. The first major milestone is 11 September 2026, when the CRA’s reporting obligations become applicable. The full set of cybersecurity and conformity requirements follows on 11 December 2027. Notably, the reporting obligations, which apply from 11 September 2026, cover all products with digital elements within the CRA scope, including products already placed on the market before that date.

What must manufacturers report?

Starting on 11 September 2026, manufacturers must notify authorities whenever they become aware of:

  • An actively exploited vulnerability in one of their products.
  • A severe cybersecurity incident affecting the security of the product.

Notifications must be submitted through the CRA Single Reporting Platform (SRP). The notification is addressed to the coordinating national CSIRT and to ENISA.

The reporting process follows strict timelines:

  • Within 24 hours: Early warning after becoming aware of an actively exploited vulnerability or a severe incident.
  • Within 72 hours: More detailed vulnerability or incident notification.
  • Within 14 days (actively exploited vulnerabilities): Final report containing the full description, severity, impact, and details on security updates / corrective measures.
  • Within one month (severe incidents): Final report containing the impact, root cause analysis, and mitigation measures.

In addition, manufacturers must inform affected users about actively exploited vulnerabilities and severe incidents when appropriate. Manufacturers should also establish clear communication channels with suppliers and component maintainers, as the CRA requires vulnerabilities identified in integrated third-party components to be reported upstream, and timely supplier coordination can be critical when actively exploited vulnerabilities or severe incidents are discovered.

Why this matters now

Compliance will require not only technical monitoring capabilities, but also defined vulnerability handling processes, clear escalation paths, and the ability to assess when a vulnerability becomes “actively exploited.” Companies that wait until the reporting obligation becomes applicable will almost certainly find themselves struggling to meet the CRA’s tight notification deadlines.

Bottom line: even though the full CRA does not apply until December 2027, manufacturers should already be preparing for the reporting obligations that start on 11 September 2026. Establishing effective vulnerability monitoring, incident response, and reporting procedures now will be essential to meeting the CRA’s first compliance milestone.

CRA Reporting: Key Questions to Ask

The following questions can help assess whether an event may trigger CRA reporting obligations for an actively exploited vulnerability or a severe incident.

Step 1: Is there a vulnerability?

Ask:

  1. What is the weakness, flaw, or susceptibility?
  2. Which product with digital elements is affected?
  3. Can the flaw actually be exploited under practical operational conditions?
  4. Is the vulnerable code/function reachable in the deployed product?
  5. Are there compensating controls that prevent exploitation?

The CRA focuses on exploitable vulnerabilities, not every theoretical vulnerability.

A vulnerability being listed in a CVE database or reported by a researcher does not automatically make it an actively exploited vulnerability.

Step 2: Is it actively exploited?

Ask:

  1. Has exploitation occurred in our product, not merely in a third-party component somewhere else?
  2. Do we have reliable evidence of malicious exploitation?
  3. Has a security breach occurred because someone exploited this flaw?
  4. Do customer reports, telemetry, logs, threat intelligence, security researchers, or government notifications indicate real-world exploitation?
  5. Can we distinguish malicious exploitation from testing, research, or responsible disclosure?

Strong indicators of active exploitation

  1. Confirmed compromise of customer systems through the vulnerability.
  2. Telemetry showing exploitation attempts succeeding.
  3. Threat intelligence reporting attackers using the vulnerability in the wild.
  4. Forensic evidence linking a breach to the vulnerability.

The guidance published by the European Commission specifically mentions customer reports, threat intelligence, security researchers, government notifications, telemetry, and internal monitoring as possible sources of awareness. A vulnerability found by ethical hackers without evidence of malicious use is not an actively exploited vulnerability.

Step 3: Could this be a severe incident instead?

Ask:

  1. Has a cybersecurity incident affected our development environment?
  2. Has our build pipeline been compromised?
  3. Have attackers modified source code, build systems, or release channels?
  4. Has our update delivery mechanism been compromised?
  5. Could users face increased cybersecurity risk because of the incident?

A classic example is an attacker inserting malicious code into the release channel used to distribute software updates.

An incident is considered severe when (see CRA Article 14 (5)):

  1. It negatively affects, or is capable of negatively affecting, a product’s ability to protect the:
    • availability,
    • authenticity,
    • integrity, or
    • confidentiality of sensitive or important data or functions;

    or

  2. It has led, or is capable of leading, to the introduction or execution of malicious code in:
    • the product itself, or
    • the network and information systems of a user of that product.

Step 4: Are users at risk?

Ask:

  1. Which users or systems are impacted?
  2. Could confidentiality, integrity, or availability be affected?
  3. Could exploitation spread to additional users?
  4. Are critical or sensitive environments affected?
  5. Are corrective or mitigating measures already available?

The CRA expects prompt assessment and subsequent reporting as knowledge evolves. Manufacturers may initially know only limited facts and are expected to update notifications as investigations progress.

Practical triage question

A simple decision tree is:

Q1: Do we have reliable evidence that a malicious actor exploited a vulnerability in our product?

  • Yes → Treat as potential actively exploited vulnerability and assess CRA reporting obligations.
  • No → Continue investigation of the vulnerability.

Q2: Has a cybersecurity incident affected our development, production, maintenance, build, signing, or update processes in a way that could increase risk to users?

  • Yes → Treat as potential severe incident.
  • No → Continue monitoring and incident handling.

The single most important question

What reliable evidence do we have that either (a) a malicious actor has exploited the vulnerability, or (b) our development/production/maintenance processes have been compromised in a way that increases risk for users?

That question usually determines whether you’re in ordinary vulnerability management territory or whether you may have a CRA-reportable actively exploited vulnerability or severe incident.