EU Cyber Resilience Act Vulnerability Handling and Disclosure

Annex I Part II is the core operating checklist for CRA vulnerability handling. It requires component and vulnerability documentation, an SBOM in a commonly used machine-readable format covering at least top-level dependencies, remediation without delay in relation to the risk, regular security tests and reviews, public information about fixed vulnerabilities once a security update is available, coordinated vulnerability disclosure, a reporting contact, secure update distribution, and timely advisory messages for users.

The process should therefore connect product inventory, vulnerability intake, engineering triage, release management, customer communications, legal reporting, and technical documentation. A scanner finding alone is not enough; teams need a traceable decision that shows what product version is affected, what risk the vulnerability creates, what remedy was selected, when users were informed, and whether Article 14 reporting was triggered.

The Commission FAQ explains that the CRA does not require a dedicated patch for every vulnerability discovered during the support period. The obligation is to assess the risk and put appropriate remedies in place without delay. Depending on the risk, the remedy may be a security update, configuration mitigation, workaround, documentation change, customer advisory, component replacement, withdrawal, or recall where a serious issue cannot be adequately addressed.

This distinction matters for evidence. The record should show why the chosen remedy was adequate for the product, not merely that a vulnerability was closed in an issue tracker.

Article 14 is narrower than vulnerability handling as a whole. It applies when the manufacturer becomes aware of an actively exploited vulnerability contained in the product with digital elements, or a severe incident having an impact on the security of the product. These reports must be submitted through the ENISA single reporting platform simultaneously to ENISA and the CSIRT designated as coordinator.

From 11 September 2026, the Article 14 clock requires staged reporting. For an actively exploited vulnerability, the manufacturer submits an early warning within 24 hours of awareness, a vulnerability notification within 72 hours of awareness, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident, the early warning and 72-hour notification also apply, while the final report is due within one month after the incident notification.

The reporting duty also covers in-scope products placed on the market before 11 December 2027. This is an express exception to the transition that otherwise generally applies CRA requirements to those earlier products only after a substantial modification from that date.

Article 16 establishes a single reporting platform managed by ENISA. Article 14 says the manufacturer uses the electronic notification endpoint of the CSIRT designated as coordinator for the Member State of the manufacturer's main establishment in the Union. The main establishment is where cybersecurity product decisions are predominantly taken; if that cannot be determined, it is the Union establishment with the highest number of employees.

If the manufacturer has no main establishment in the Union, Article 14 provides a routing order based on the authorised representative, importer, distributor, and finally the Member State with the highest number of users. That routing decision should be prepared before an incident so the first 24 hours are not spent debating the endpoint.

As of 24 July 2026, the Commission says the Single Reporting Platform will be operational by 11 September 2026 and will have a testing period before then. ENISA describes it as the single entry point for mandatory and voluntary CRA reports. Teams should use the official platform and onboarding information available at the time of submission rather than inventing an internal filing endpoint.

The CRA requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy and to provide a contact address for vulnerability reports. Annex II also requires the product to be accompanied by the single point of contact where vulnerabilities can be reported and where the coordinated disclosure policy can be found.

Once a security update is available, Annex I Part II requires public information about fixed vulnerabilities. The advisory must identify the affected product, describe the vulnerability, explain impact and severity, and give clear remediation information. Publication may be delayed only in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits until users have had the possibility to apply the relevant patch.

CRA security updates must be distributed securely, disseminated without delay when available for identified security issues, and free of charge unless a tailor-made product agreement with a business user provides otherwise. Where technically feasible, new security updates must be separate from functionality updates. Automatic security updates are required where applicable, but user information must explain how security-relevant updates can be installed and how automatic installation can be turned off where that setting exists.

The support period must reflect expected product use, taking into account in particular reasonable user expectations, the nature and intended purpose of the product, and relevant Union law. The manufacturer may also consider comparable products, the availability of the operating environment, and support periods of core integrated components. Component end-of-support does not automatically end the product manufacturer's CRA responsibility during the product's own support period. If an integrated component vulnerability is identified, Article 13(6) requires reporting it to the component manufacturer or maintainer, addressing it in the product, and sharing relevant fix code or documentation where appropriate.

Annex VII makes vulnerability handling part of technical documentation. It requires information and specifications for the vulnerability handling process, including the SBOM, coordinated vulnerability disclosure policy, evidence that a reporting contact is provided, and a description of the technical solutions chosen for secure update distribution. It also requires test reports verifying the product and vulnerability handling process against the applicable essential cybersecurity requirements.

A useful evidence pack should let a reviewer reconstruct the path from discovery to user protection: how the issue was received, how risk was assessed, what was reported, what was fixed or mitigated, how users were informed, and which support-period commitments were affected.