Vulnerability Handling, Reporting & CVD under the CRA

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to build their products securely and to keep them secure throughout the entire support period. Two sets of duties interlock here: the ongoing vulnerability handling under Annex I Part II and the short-fuse reporting obligation under Art. 14. This article explains both - and sharpens the point where mistakes are easiest to make: the reporting cadence. It is general technical and organisational guidance, not legal advice.

Part 1 - Vulnerability handling (Annex I Part II)

Annex I Part II describes what a manufacturer must do continuously throughout the support period. What is required is a process that runs day to day. The core duties:

• Identify & document. Systematically record the product's vulnerabilities and components - including a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies. The CRA mandates no specific format; common formats include CycloneDX and SPDX (guidance, not statutory text). The Commission may specify the format and elements of the SBOM by implementing act (Art. 13(24)). More in our article on SBOM requirements under the CRA.
• Remediate without delay. Handle and remediate vulnerabilities without delay, including through security updates. Where feasible, separate security updates from feature updates, so a pure security fix does not have to wait on a feature release.
• Test & review regularly. Verify the effectiveness of the security measures through regular tests and reviews.
• Disclose publicly. Disclose fixed vulnerabilities once an update is available - with information that lets users apply the fix. In duly justified cases, publication may be delayed until users have been able to apply the patch.
• Enforce a CVD policy. A coordinated vulnerability disclosure (CVD) policy is mandatory. It governs how third parties can report vulnerabilities and how the manufacturer handles them.
• Provide a contact address. Publish a reachable contact address for reporting vulnerabilities.
• Update securely & free of charge. Distribute updates securely, make them available without delay and - for security updates - free of charge, unless otherwise agreed with a business user for a tailor-made product.

Part 2 - Reporting obligation (Art. 14)

Beyond ongoing handling, Art. 14 requires short-fuse reporting to the CSIRT designated as coordinator (Art. 14(7)) and to ENISA - handled via the Single Reporting Platform (Art. 16). There are two triggers:

1. Actively exploited vulnerabilities in a product with digital elements.
2. Severe incidents that affect the security of the product.

The same three-stage cascade applies to both triggers - but the final report follows a different deadline depending on the trigger. That is exactly where the trap lies.

The cadence at a glance

The 24-hour early warning and the 72-hour notification are identical for both triggers. Only the final report diverges: for a vulnerability the deadline is anchored to the availability of a corrective or mitigating measure (no later than 14 days after), for an incident to the notification itself (one month after). Confusing these two reference points means reporting at the wrong time.

From when, and for which products?

The Art. 14 reporting obligation has applied since 11 September 2026. It expressly also covers products already on the market, not just new developments (Art. 69(3)). Reports are submitted via the Single Reporting Platform that ENISA sets up and operates under Art. 16 CRA. Broader context on the deadlines is in our article on the CRA reporting obligation since September 2026.

How handling and reporting work together

The two sets of duties belong to the same process. Ongoing vulnerability handling (Annex I Part II) provides the detection and response capability; the reporting obligation (Art. 14) kicks in the moment a vulnerability is actively exploited or a severe incident occurs. A working CVD policy and a monitored contact address are the bridge: they ensure that a vulnerability reported from outside can quickly trigger the internal cascade. Without this foundation, the 24-hour deadline is hard to meet.

In practice: the deadline is tied to the manufacturer becoming aware (Art. 14(2)(a) and (4)(a)); an internal sign-off or a management decision does not pause it. The CRA does not expressly say when knowledge held by individual employees is attributed to the manufacturer, so plan as if the clock starts when the information first reaches the company. Detection, assessment and the reporting decision therefore need to be closely linked; a long internal approval path uses up the deadline. Equally important is a clear distinction between the two triggers: a vulnerability becomes reportable only once it is actively exploited, and an incident only once it is severe within the meaning of Art. 14(5). A threshold documented in advance shortens the debate in an emergency about whether a report is required at all.

“Prepare now” - checklist

The following steps are general organisational and technical guidance, not legal advice:

• Draft and publish a CVD policy - including a reachable, monitored contact/reporting address for vulnerabilities.
• Build an SBOM in a commonly used, machine-readable format (at least top-level dependencies) and integrate it into the build process.
• Separate security from feature updates where technically feasible, so security fixes can ship quickly and free of charge.
• Define a reporting process for the Single Reporting Platform - responsibilities, escalation paths and a workflow that realistically meets the 24h/72h deadlines.
• Document both final-report deadlines: 14 days (after a corrective or mitigating measure is available, vulnerability) and one month (after notification, incident) - as separate playbooks.
• Rehearse the cascade. Run a tabletop exercise so that 24 hours is not the first time you practise under pressure.
• Include existing products. The reporting obligation also covers products placed on the market before 11 December 2027 (Art. 69(3)). Record which of them are still in use.
• Set the support period: at least five years, shorter only where the expected period of use is shorter (Art. 13(8)). It determines how long vulnerability handling under Annex I Part II must be ensured; the Art. 14 reporting obligation does not depend on it.

Whether and to what extent your products are affected is best clarified first with the applicability check. Only once you know which products are in scope is it worth building the processes described here.

The relevant references: vulnerability handling in Annex I Part II; the reporting obligation in Art. 14; the CSIRT designated as coordinator in Art. 14(7); voluntary notifications in Art. 15; the Single Reporting Platform in Art. 16; the underlying manufacturer duties in Art. 13. For the exact wording, the Official Journal text always governs.