CRA Reporting: Actively Exploited Vulnerabilities & Incidents Explained

One of the most operationally demanding parts of the Cyber Resilience Act is the obligation to handle vulnerabilities and report security incidents. These duties apply to every product with digital elements placed on the European Union market, and they begin well over a year before the full CRA requirements take effect in December 2027.

This article clarifies how the regulation defines an actively exploited vulnerability, how European intelligence sources feed into this definition, and what manufacturers must report starting in September 2026.

Vulnerability Handling Under the CRA

Once a product is in use, manufacturers must keep it secure throughout its entire expected use time. The support period must last for at least five years unless the expected use time is shorter.

When a vulnerability is discovered, manufacturers must provide a security update free of charge and as soon as possible.

The only exception is for tailor made enterprise solutions, where cost sharing is allowed only when explicitly agreed in a contract with a specific business user.

Automatic installation of security updates should be the default setting for most products, with a simple opt out mechanism. However, the CRA recognises that fully automatic updates are not always appropriate in certain professional or industrial environments where unplanned updates could disrupt critical operations. The exemption is contextual rather than universal.

Understanding Actively Exploited Vulnerability Under the CRA

The CRA gives a precise definition: an actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission.

The key factor is not whether the manufacturer has been attacked, but whether the vulnerability is known to have been exploited anywhere. Vulnerabilities discovered through good faith research or internal testing, with no evidence of malicious exploitation, are not considered actively exploited for CRA reporting.

Because of this, public intelligence sources become essential for determining whether exploitation has already occurred.

The Role of Open Intelligence Databases

The CRA links vulnerability reporting to European and global intelligence sources. While the regulation does not mandate monitoring any specific database, the emerging European vulnerability repository and other open intelligence feeds help manufacturers determine whether a vulnerability is known to be exploited.

In practice, manufacturers use these sources to understand:

• whether an exploited vulnerability affects a component they use
• whether the affected component is reachable in their architecture
• whether exploitation is possible in their product context

If a vulnerability is known to have been exploited, the manufacturer must begin the formal CRA reporting process even if:

• the vulnerability has never been used against their own product
• the manufacturer has already issued a fix

This is one of the most significant operational impacts of the CRA. While the regulation does not impose a legal requirement to continuously monitor specific databases, the obligation to notify begins the moment a manufacturer becomes aware, which makes proactive monitoring a practical necessity. If your product contains a component with a known exploited vulnerability, you must report it if the vulnerability can be exploited in your product.

If the vulnerability exists in a dependency but cannot be exploited in your specific implementation, the CRA does not require mandatory reporting; although you still have a duty to inform the component maintainer.

This is a key distinction. ScanDog’s smart prioritisation immediately surfaces actively exploited vulnerabilities and also makes clear the distinction of whether it can be exploited in your specific implementation.

Reporting Obligations Starting September 2026

From September 11th 2026, manufacturers must notify 2 categories of issues:

• actively exploited vulnerabilities
• severe security incidents

This requirement applies even when the vulnerability has already been patched.

Notifications must be submitted through the national reporting platform of the Member State where the manufacturer has its main establishment. The European Network and Information Security Agency automatically receives access to the reports through the EU’s designated CSIRT coordinator.

Reporting Actively Exploited Vulnerabilities

The CRA sets strict notification deadlines.

Early warning within 24 hours

Manufacturers must report:

• the actively exploited vulnerability
• the countries or markets where the product is available, when known

Vulnerability notification within 72 hours

This must include, when available:

• product details and affected versions
• the nature of the exploit
• mitigation measures already taken
• guidance for users
• a sensitivity assessment to avoid unintentionally increasing harm

Final report within 14 days after a patch is available

This must include:

• a detailed description and severity assessment
• information about any known malicious actor, when available
• the security update or corrective measures issued

Tip: Tackling these vulnerabilities before September 11th 2026 dramatically reduces future reporting load. Fixing them early means you remove the duty to notify entirely.

Reporting Severe Security Incidents

A severe security incident is any event that negatively affects or could negatively affect the product’s ability to ensure availability, authenticity, integrity, or confidentiality of important or sensitive data or functions.

This includes incidents within the product in use and incidents affecting the manufacturer’s development or update infrastructure, such as malicious code injected into the update channel.

Early warning within 24 hours

Manufacturers must report:

• whether the incident appears malicious
• where the affected product is available

Incident notification within 72 hours

This must include:

• the nature of the incident
• an initial assessment
• mitigation measures taken
• recommended user actions
• a sensitivity assessment

Final incident report within 1 month

This must include:

• detailed description, severity, and impact
• the likely root cause or threat actor
• all mitigation and corrective measures applied

These obligations apply to all digital products already placed on the EU market, including those released long before December twenty twenty seven.

For older products that are difficult to investigate, manufacturers must still notify what they know and inform users of the risks.

Why This Matters

The Cyber Resilience Act turns vulnerability handling and incident reporting into enforceable duties with hard deadlines. Each newly confirmed exploited vulnerability can trigger a mandatory notification, which makes structured monitoring, triage, and remediation essential for CRA readiness.

ScanDog supports this by identifying known exploited vulnerabilities, correlating them with your assets, and providing CRA ready evidence across SAST, SCA, IaC, container, and dependency data. This reduces manual workload and helps teams meet the CRA’s reporting timelines with confidence.

---