Vulnerability Handling (CRA)

Vulnerability handling under the Cyber Resilience Act (CRA) covers the requirements the EU places on manufacturers to continuously identify, document, report and remediate security vulnerabilities in products with digital elements. The requirements apply throughout the product's support period and include reporting to ENISA within 24 hours for actively exploited vulnerabilities.

Back to Dictionary

Vulnerability handling requirements

CRA Annex I, Part II, specifies the requirements for vulnerability handling. It is one of CRA's two pillars of requirements. Whilst the first pillar addresses product security design, this pillar addresses what happens after the product is launched.

The manufacturer must establish and document a process to:

Identify and document vulnerabilities in the product, including in third-party components
Prioritise vulnerabilities based on risk and develop remediation
Distribute security updates to users without undue delay
Report actively exploited vulnerabilities to ENISA
Publish information about remediated vulnerabilities
Maintain a policy for coordinated vulnerability disclosure

The requirements apply throughout the support period, which must be at least five years from the product's placement on the market. This represents a significant change for producers who have historically regarded products as complete upon launch.

Reporting to ENISA

CRA introduces a reporting obligation for actively exploited vulnerabilities. This obligation is the first to enter into force, already in September 2026.

The reporting process follows three stages:

Within 24 hours: An early warning to ENISA identifying the vulnerability and indicating whether it is being actively exploited. The warning need not be comprehensive.
Within 72 hours: A more detailed notification describing the vulnerability, its severity and preliminary remediation measures.
Within 14 days: A final report with full analysis, impact assessment and implemented remediation.

The timeframes are reminiscent of GDPR's 72-hour notification obligation for data breaches and NIS2's reporting requirements for security incidents. For organisations with established incident response processes, the structure will be familiar.

ENISA serves as the central recipient and forwards reports to the relevant national CSIRTs. Reporting is conducted via a common EU reporting platform.

Coordinated vulnerability disclosure

CRA requires manufacturers to establish a policy for coordinated vulnerability disclosure (CVD). It must be possible for security researchers and users to report vulnerabilities to the manufacturer in a structured manner.

The policy must at a minimum define:

A contact channel for reporting vulnerabilities (typically a security@ address or a dedicated web form)
Timeframes for when the manufacturer acknowledges receipt and delivers a fix
Guidelines for when and how the vulnerability is disclosed publicly

CVD is not new. Many mature software producers already have such programmes. CRA makes it a legal requirement for all manufacturers of products with digital elements.

A well-functioning CVD process is closely linked to penetration testing and vulnerability scanning. Where you actively search for vulnerabilities yourself, CVD provides a channel for external parties to contribute.

Security updates

When a vulnerability is identified, the manufacturer must develop and distribute a fix. CRA sets clear requirements for this process:

Security updates must be provided free of charge throughout the support period
Updates must be distributed without undue delay
Security updates must be separated from functional updates, so users can install security patches without being forced to update functionality
The product must be designed with a mechanism for automatic updates that the user can disable

The requirement to separate security and functional updates is important. It ensures users do not refrain from installing critical security patches out of concern that a functional update will alter the product's behaviour.

The manufacturer must document all delivered security updates as part of the technical documentation. This supports the CE marking's requirement for ongoing conformity.

SBOM and continuous monitoring

Effective vulnerability handling requires that you know what your product contains. A Software Bill of Materials (SBOM) is the foundation for continuous monitoring.

By matching your SBOM against vulnerability databases such as NVD, OSV and GitHub Advisory Database, you can automatically detect when a component in your product is affected by a new vulnerability. Without an SBOM, you are dependent on someone manually discovering the problem.

CRA's requirements for vulnerability handling are closely linked to the principle of security by design. A product designed with security from the outset will have fewer vulnerabilities and be easier to update. Encryption, access control and network segmentation reduce the impact of the vulnerabilities that do arise.

Frequently Asked Questions about Vulnerability Handling (CRA)

What does CRA require regarding vulnerability handling?

CRA requires manufacturers to establish a process for identifying, documenting and remediating vulnerabilities throughout the product's support period. Actively exploited vulnerabilities must be reported to ENISA within 24 hours, and security updates must be provided free of charge to users.

When must vulnerabilities be reported under CRA?

Actively exploited vulnerabilities must be reported to ENISA within 24 hours of discovery with an early warning. Within 72 hours, the manufacturer must provide a more detailed notification. A final report must follow within 14 days.

What is coordinated vulnerability disclosure?

Coordinated vulnerability disclosure (CVD) is a process in which security researchers report found vulnerabilities to the manufacturer, who is given time to develop a fix before the vulnerability is made public. CRA requires manufacturers to establish a CVD policy.

How long must the manufacturer provide security updates?

The manufacturer must provide security updates throughout the product's expected lifetime or for at least five years from the date of placing on the market. Updates must be free and available without undue delay.