EU Cyber Resilience Act FAQ Vulnerability Handling

Annex I Part II requires manufacturers to:

- identify and document vulnerabilities and components, including a software bill of materials

- address and remediate vulnerabilities without delay, including through security updates

- apply effective and regular security tests and reviews

- disclose information about fixed vulnerabilities once a security update is available, subject to a limited justified delay option

- enforce a coordinated vulnerability disclosure policy

- facilitate vulnerability reporting, including for third-party components in the product

- provide secure update-distribution mechanisms and, where applicable, automatic security updates

- disseminate security updates without delay and, unless the tailor-made exception applies, free of charge

No.

The Commission FAQ says the CRA does not require a patch for every vulnerability. The manufacturer must assess the risk the vulnerability poses and ensure that remedies are put in place without delay. Depending on the risk, the right remedy may be an immediate patch, a mitigation, configuration guidance, an advisory, documentation changes, or another appropriate measure.

The CRA does not define one universal deadline for remediation under Annex I Part II point (2). The Commission FAQ treats it as risk-based. High-risk vulnerabilities may require immediate patching, while lower-risk issues may be handled through other timely remedies.

What matters is that the manufacturer assesses the vulnerability promptly and takes an appropriate remediation or mitigation path without unjustified delay.

Where technically feasible, yes.

The CRA says new security updates must be provided separately from functionality updates where technically feasible. Recital 57 explains that this is meant to avoid forcing users to install feature changes just to receive security fixes.

Yes, where separation is not technically feasible.

The Commission FAQ gives examples where a security fix necessarily changes functionality, such as replacing an unsafe parser with a safer one that changes product behaviour, or disabling a vulnerable interface. In those cases, the CRA does not require artificial separation.

No.

Manufacturers must ensure, when placing the product on the market and for the support period, that vulnerabilities of the product, including its components, are handled effectively and in accordance with Annex I Part II.

Yes.

The CRA and the Commission FAQ both state that the vulnerability-handling obligations apply to the product in its entirety, including integrated components.

The manufacturer must report the vulnerability to the person or entity manufacturing or maintaining the component, address and remediate the vulnerability in its own product, and share the relevant code or documentation if it developed a hardware or software modification to fix the component vulnerability.

Sometimes, but not completely.

If the component is itself subject to CRA obligations, the integrating manufacturer can rely in part on the component manufacturer's vulnerability-handling work. But the integrating manufacturer still has to fulfil the CRA obligations for its own product, including keeping users informed and ensuring the overall product remains compliant.

If the component is not subject to CRA vulnerability-handling obligations, the integrating manufacturer must still handle the issue in its own product, including by other means if necessary.

That does not remove the product manufacturer's CRA duty.

The Commission FAQ says that if a product still has an active support period and a vulnerability in an integrated component can no longer be addressed through the component's own support path, the manufacturer of the product must remediate the issue by other means, such as switching out the component or developing a patch autonomously.

Not always.

Article 13(10) allows the manufacturer, under specific conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of earlier versions can access the latest version free of charge and without additional costs to adjust their hardware or software environment.

No.

Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period.

No, but the manufacturer is responsible for making the update path work properly.

The CRA requires mechanisms for secure distribution, automatic security updates where applicable, notification to users, and dissemination without delay. The Commission FAQ says the manufacturer is not responsible under the CRA if a user does not install updates, for example because the user opted out.

Yes, unless the tailor-made exception applies.

Annex I Part II point (8) requires that security updates addressing identified security issues be disseminated without delay and free of charge, unless otherwise agreed between the manufacturer and a business user in relation to a tailor-made product.

Yes.

Article 13(9) says each security update made available during the support period must remain available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer.

Yes.

Article 13(11) says manufacturers may maintain public software archives enhancing user access to historical versions. If they do, users must be clearly informed in an easily accessible manner about the risks associated with using unsupported software.

Yes.

Annex I Part II point (3) requires effective and regular tests and reviews of the security of the product. Article 13(7) also requires the manufacturer to systematically document relevant cybersecurity aspects and, where applicable, update the cybersecurity risk assessment.

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.