Search every question across sub-FAQs

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.

No.

Article 69(2) says products with digital elements placed on the market before 11 December 2027 are subject to the CRA requirements only if, from that date, they are subject to a substantial modification.

Yes.

Article 69(3) creates a specific derogation for reporting. It says Article 14 applies to all in-scope products that were placed on the market before 11 December 2027, and Article 71(2) says Article 14 starts to apply on 11 September 2026.

Yes.

The Commission FAQ explains that individual products placed on the market before 11 December 2027 do not need to be brought into CRA conformity simply because they remain in the distribution chain after that date.

No.

The Commission FAQ gives a direct example: units already placed on the market before 11 December 2027 do not need to be brought into CRA compliance even if they have not yet reached the final user. The legal question is whether the individual product was placed on the market, not whether it was already sold to the final customer or put into service.

No, not unless those newly placed units comply with the CRA.

The Commission FAQ stresses that Union harmonisation legislation, including the CRA, applies to individual products, not to abstract product types or models. So a product is not grandfathered just because an earlier unit of the same type was placed on the market before 11 December 2027.

Then the CRA starts to apply to that product.

Article 69(2) makes substantial modification the trigger. The CRA definition in Article 3(30) covers changes made after placing on the market that affect compliance with the essential cybersecurity requirements in Annex I Part I or change the intended purpose for which the product was assessed.

No.

The Commission FAQ gives a direct example: a smart TV placed on the market before 11 December 2027 does not become subject to full CRA requirements merely because it receives a later bug-fix update. Recital 39 of the CRA also says that a security update designed to decrease cybersecurity risk, without modifying intended purpose, is not considered a substantial modification.

The Commission FAQ gives an example where a smart TV placed on the market before 11 December 2027 later receives an update enabling smart-home control. The FAQ treats that as a substantial modification.

That result is consistent with recital 39, which says feature updates that modify original intended functions or the type or performance of the product and increase cybersecurity risk should be treated as substantial modifications.

No.

Recital 42 says refurbishment, maintenance, and repair do not necessarily lead to a substantial modification. That will depend on whether the intended purpose and functionalities change and whether the level of risk remains unaffected.