Search every question across CRA sub-FAQs

Yes, once a security update has been made available.

Annex I Part II point (4) requires disclosure of information about fixed vulnerabilities, including the vulnerability description, affected products, impact, severity, and clear remediation information. The CRA allows delay only in duly justified cases where publication risk outweighs publication benefit until users have had the possibility to apply the patch.

Yes.

Annex I Part II points (5) and (6) require a coordinated vulnerability disclosure policy and measures to facilitate sharing of information about potential vulnerabilities, including a contact address. Article 13(17) and Annex II also require a single point of contact for users.

The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate.

The Commission FAQ says recall or withdrawal is likely to be exceptional, but it can be required where a very significant vulnerability cannot be adequately addressed, especially for hardware products.

Yes.

Article 13(7) requires the manufacturer to systematically document, in a manner proportionate to the nature and cybersecurity risks, relevant cybersecurity aspects concerning the product, including vulnerabilities of which it becomes aware and relevant information provided by third parties. Where applicable, it must also update the cybersecurity risk assessment.

The Commission FAQ adds that this includes updating the risk assessment where relevant information about the product's cybersecurity emerges from regular tests and reviews.

Yes.

Vulnerability handling under Article 13 and Annex I Part II applies more broadly during the support period. It covers identifying, documenting, assessing, remediating, testing, updating, disclosing fixed vulnerabilities, and handling component vulnerabilities.

Article 14 is narrower. It applies only when the manufacturer becomes aware of an actively exploited vulnerability or of a severe incident having an impact on the security of the product. So not every vulnerability-handling event triggers mandatory CRA reporting, even though it may still require remediation or other action under Annex I Part II.

Yes.

Article 15 provides for voluntary notification of actively exploited vulnerabilities and severe incidents. The Commission FAQ also gives examples where mandatory reporting does not apply, such as a zero-day vulnerability with no reliable evidence of malicious exploitation, or a vulnerability in an integrated component that is not exploitable in the manufacturer's own product. In those cases, voluntary reporting remains possible.

That does not replace the manufacturer's ordinary vulnerability-handling duties. For example, where the issue concerns an integrated component, Article 13(6) still requires reporting the vulnerability to the person or entity manufacturing or maintaining that component.

Yes.

Article 13(8) requires appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources. So the CRA does not treat internal testing, internal security reviews, researcher disclosures, customer reports, and similar outside inputs as separate optional tracks. The handling process has to be able to deal with both.

ISO/IEC 30111 in the local CRA corpus points in the same direction as practical implementation guidance: it treats vulnerability handling as covering internally found vulnerabilities, externally reported vulnerabilities, and publicly disclosed vulnerabilities that reach the vendor from outside.

No.

The March 2026 draft guidance says manufacturers are required to report upstream only the vulnerabilities that exist in the integrated component itself, and only for the version of that component that they actually integrate. They are not required to report upstream vulnerabilities that arise only from the way the manufacturer integrated that component with its own code or with other components.

The same draft guidance adds that where integration reveals useful security-relevant information about the component that was not apparent in isolation, manufacturers are encouraged to share that information upstream, but that is framed as good practice rather than as the strict Article 13(6) duty.

Not in those cases.

The March 2026 draft guidance says upstream reporting is not required where the component no longer has a maintainer, or where the manufacturer has duplicated a free and open-source component and no longer relies on the original maintainer for new versions or security fixes. But the same guidance also warns that a manufacturer is not treated as maintaining an independent fork if it still relies on the upstream project for new versions or security fixes, for example by regularly synchronising local copies with upstream.

The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance.

The March 2026 draft guidance says a manufacturer sharing an upstream fix should, where appropriate, share it in a machine-readable format, such as a merge request, in a way that can be verified and integrated by the maintainer. For free and open-source components, the fix should be shared in a way compatible with the component's licence, and manufacturers should generally follow the maintainer's guidelines on how fixes should be shared.

But the same guidance is explicit that the CRA does not require manufacturers to ensure that their fixes are accepted or integrated upstream, and it does not require manufacturers to accept a maintainer's proposed fix if they prefer another suitable mitigation.

A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths.

Recital 76 says coordinated vulnerability disclosure policies should facilitate the reporting of vulnerabilities either directly to the manufacturer or indirectly and, where requested, anonymously via CSIRTs designated as coordinators under Directive (EU) 2022/2555. The same recital says manufacturers should be able to use bug bounty programmes as part of those policies, but it does not make bug bounties compulsory.

No.

Annex I Part II point (4) concerns fixed vulnerabilities: once a security update has been made available, the manufacturer must share and publicly disclose information about those fixed vulnerabilities, subject to the limited justified delay option. Article 14(8), by contrast, concerns actively exploited vulnerabilities and severe incidents and requires manufacturers to inform impacted users and, where appropriate, all users.

The March 2026 draft guidance adds that Article 14(8) is risk-based and proportionate. It does not require indiscriminate public disclosure in every case, and detailed information may in some situations be limited to the relevant affected users or customers.