EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch

No. The CRA launch requirement is narrower than that.

Annex I Part I point (2)(a) says that, on the basis of the cybersecurity risk assessment and where applicable, products with digital elements must be made available on the market without known exploitable vulnerabilities. The Commission FAQ confirms that the CRA does not require manufacturers to ensure that a product is free from all vulnerabilities.

The CRA defines a vulnerability as a weakness, susceptibility, or flaw of a product with digital elements that can be exploited by a cyber threat. It defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions.

The practical question is therefore not only whether a weakness exists, but whether it can be used against this product in its intended and reasonably foreseeable operating conditions.

The CRA text does not separately define when an exploitable vulnerability becomes known. The Commission's March 2026 draft guidance gives the most specific public interpretation in the grounding material.

Under that draft guidance, an exploitable vulnerability should be regarded as known when it is listed in relevant public vulnerability databases, including the European vulnerability database under NIS2 or prominent databases such as the CVE List. It may also be known through coordinated disclosure, internal testing and analysis, or prominent reporting in reliable cybersecurity or general media.

No. A public CVE, advisory, or component finding is a triage trigger, not an automatic launch ban for every product variant.

The manufacturer still has to verify whether the reported vulnerability is real, whether the affected code or function is present and reachable in its product, whether the vulnerable component is invoked or loaded in use, what access is required, whether compensating controls change exploitability, and whether the product's actual operational environment makes exploitation practical.

Treat a late-stage potentially exploitable vulnerability as a release gate.

The release decision should record the vulnerability source, affected product and version, component or code path, exploitability analysis under practical operational conditions, severity, potential impact, compensating controls, available fix or mitigation, and the cybersecurity risk assessment conclusion. If the vulnerability is known and exploitable for the product at placement on the market, the grounded answer is to fix or otherwise bring the product into conformity before launch rather than rely on a post-launch patch plan.

No, not as a substitute for the launch-time Annex I requirement.

The CRA separates the placement-on-the-market requirement from the later support-period vulnerability-handling regime. A post-launch patch process is required for vulnerabilities handled during the support period, but it does not cure placing a product on the market while a known exploitable vulnerability is already present and applicable.

The Commission FAQ says the launch-time obligation applies at placement on the market. If a newly discovered vulnerability appears after that point, the manufacturer is not expected to fix it before the product reaches the final user solely because of Annex I Part I point (2)(a).

That does not end the analysis. The manufacturer still has to handle vulnerabilities during the support period, including addressing and remediating vulnerabilities without delay in relation to the risks posed. Depending on the risk, that may mean a security update, workaround advisory, configuration guidance, or another remedy.

Yes. The launch decision is about the product with digital elements as placed on the market, including integrated components.

Article 13 requires due diligence when integrating third-party components so they do not compromise the cybersecurity of the product. Recital 34 and the Commission FAQ also explain that vulnerability-handling obligations apply to the product in its entirety, including integrated components. A component CVE therefore needs product-specific applicability and exploitability triage, not automatic dismissal because the flaw is upstream.

Secure-by-default is a separate Annex I requirement, but it often affects exploitability and launch risk.

If a vulnerable service, interface, algorithm, default credential, or update setting is exposed by default, the release gate should evaluate both requirements together: whether the product is being made available without known exploitable vulnerabilities, and whether the default configuration is secure for the product's intended purpose and reasonably foreseeable use. If a configuration change is the mitigation, the evidence should show that the secure state is the market-delivered default, not only an optional hardening guide.

No. Known exploitable vulnerability and actively exploited vulnerability are different CRA concepts.

A launch decision under Annex I Part I point (2)(a) asks whether the vulnerability is known and exploitable under practical operational conditions at placement on the market. Article 14 reporting asks whether the manufacturer becomes aware of an actively exploited vulnerability, which Article 3(42) defines by reliable evidence of malicious exploitation in a system without permission.

Article 14 is triggered when the manufacturer becomes aware of an actively exploited vulnerability contained in the product with digital elements, not merely because a vulnerability is known, severe, or unpatched.

If the launch triage finds reliable evidence that a malicious actor has exploited the vulnerability in a system without permission, Article 14 reporting may apply. The CRA then requires 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.

Keep evidence that connects the vulnerability finding to the specific CRA launch conclusion.

Useful records include the source of the finding, affected product identifiers and versions, SBOM or component mapping, vulnerable code-path analysis, operational-environment assumptions, access prerequisites, compensating controls, severity and impact analysis, fix or mitigation status, secure-by-default configuration evidence, test results, the risk-assessment update, the release approval or block decision, and any Article 14 or voluntary-reporting assessment. The record should be usable by someone checking why the product was or was not placed on the market.

Yes, but only within the CRA testing exception.

Article 4(3) allows unfinished software to be made available for the limited time required for testing if it has a visible sign clearly stating that it does not comply with the CRA and will not be available on the market for purposes other than testing. Recital 37 and the Commission FAQ add that manufacturers should still release it only following a risk assessment, comply with product security requirements to the extent possible, and implement vulnerability handling to the extent possible.

No. CRA compliance is not only a product-type abstraction.

Recital 38 says the essential cybersecurity requirements apply to each individual product with digital elements when it is placed on the market, whether manufactured individually or in series. It gives the example that each individual product should have received all security patches or updates available to address relevant security issues when it is placed on the market.