Vulnerability Handling, Reporting & CVD under the CRA

The Cyber Resilience Act (Regulation (EU) 2024/2847) does not just require manufacturers to build their products securely once; it requires them 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 one point where most mistakes happen: 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. It is not a document but a lived process. 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; established formats such as CycloneDX, SPDX or SWID satisfy the requirement (this is guidance, not statutory text). More in our article on SBOM requirements under the CRA.
• Remediate without delay. Close vulnerabilities without delay via 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.
• Enforce a CVD policy. A coordinated vulnerability disclosure (CVD) policy is mandatory – not optional. 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.

Part 2 – Reporting obligation (Art. 14)

Beyond ongoing handling, Art. 14 requires short-fuse reporting to the coordinating CSIRT (designated under Art. 15) 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 the fix (≤ 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 applies from 11 September 2026. It expressly also covers products already on the market – not just new developments. The Single Reporting Platform is targeted to be operational by that date. Broader context on the deadlines is in our article on the CRA reporting obligation from September 2026.

How handling and reporting work together

The two sets of duties are not a contradiction but two ends of 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 early warning becomes practically unreachable.

„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 fix 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 already shipped – check which of them are still within the support period.
• Set the support period (at least 5 years or the expected use time) – it defines how long handling and reporting apply.

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 coordinating CSIRT 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.