CRA Rules on Known Exploitable Vulnerabilities

Annex I Creates a Pre-Market Vulnerability Requirement

Annex I Part I point 2(a) states that, on the basis of the cybersecurity risk assessment and where applicable, products with digital elements are to be made available on the market without known exploitable vulnerabilities. The timing is important. This is a product-security condition connected to making the product available on the market, not only a post-market vulnerability-handling expectation. A manufacturer therefore needs visibility into relevant vulnerabilities before release and a process for deciding whether an issue is exploitable in the actual product. The control objective is stronger than simply running a vulnerability scanner. The manufacturer should be able to show how vulnerability information reaches the product team, how affected components and versions are identified, how exploitability is assessed and how blocking issues are resolved before release.

Known Vulnerability and Known Exploitable Vulnerability Are Not Identical

A vulnerability can be known because it has been disclosed, assigned an identifier, reported by a supplier, discovered internally or otherwise documented. That does not automatically establish that it is exploitable in every product that contains the affected code or component. Product context matters. A vulnerable function may not be included, reachable, enabled or usable under the product's actual configuration. Conversely, a vulnerability without a convenient public identifier can still be known to the manufacturer and exploitable in the product. A CRA release process should therefore avoid two extremes: treating every advisory as automatically release-blocking, or dismissing vulnerabilities merely because exploitation has not been observed publicly. The relevant analysis concerns what is known and exploitable in the product context.

• Identify the affected component and version.
• Determine whether the vulnerable functionality is present.
• Determine whether an attacker can reach or trigger it.
• Consider product configuration and privileges.
• Document the basis for the exploitability conclusion.

Component and Dependency Visibility Is Essential

Modern products often include third-party libraries, open-source packages, firmware, operating-system components, embedded modules or other dependencies. A manufacturer cannot assess known exploitable vulnerabilities reliably if it does not know what the product contains. Annex I Part II separately requires manufacturers to identify and document vulnerabilities and components and includes a software bill of materials requirement covering at least top-level dependencies in a commonly used and machine-readable format. For the release requirement, the practical value of this inventory is that advisories and vulnerability reports can be mapped to the actual product. Teams should also understand build-time substitutions, bundled versions and separately updated components so that the inventory reflects what users receive rather than only what a source repository declares.

• Maintain accurate component and version records.
• Map supplier and public vulnerability information to the product.
• Track embedded and bundled dependencies.
• Account for product-specific configuration and feature use.
• Keep records aligned with released product versions.

A Release Gate Should Assess Exploitability Before Market Availability

A practical control is to include a vulnerability review in the release process. The review should combine automated findings with product-security analysis rather than rely on severity scores alone. Relevant questions include whether the vulnerable code exists in the shipped product, whether the attack path is reachable, what privileges are required, whether mitigations prevent exploitation, what impact successful exploitation could have and whether a fixed version is available. The decision should have a clear owner and escalation route. Where a vulnerability is determined to be known and exploitable in the product, the release process should treat that conclusion as a compliance issue rather than a routine backlog item. Evidence of remediation and retesting should remain with the release record.

• Run dependency and vulnerability checks before release.
• Review findings in product context.
• Escalate uncertain exploitability decisions.
• Block release where a known exploitable vulnerability remains.
• Retest after remediation.
• Retain the decision and evidence.

Severity Scores Do Not Replace Product Context

Common vulnerability scoring systems can help prioritise analysis, but a score does not by itself answer the CRA question. A high-severity vulnerability can be non-exploitable in a specific product configuration, while a lower-scored issue can matter materially because of the product's privilege model, exposure or deployment environment. Manufacturers should therefore use scores as inputs rather than legal conclusions. The analysis should consider the actual attack path and consequences in the product. Where the decision depends on a mitigation, such as disabled functionality, sandboxing, authentication, network isolation or compiler-level protection, the manufacturer should verify that the mitigation is present and effective in the released configuration rather than assume it from design intent.

• Use severity as an input, not the final exploitability decision.
• Assess reachability and attack prerequisites.
• Consider the product's actual privileges and exposure.
• Verify claimed mitigations.
• Document the reasoning for non-exploitability conclusions.

The Rule Connects to Part II Vulnerability Remediation

The pre-market requirement does not remove the need for post-market vulnerability handling. Annex I Part II requires manufacturers to identify and document vulnerabilities and components and to address and remediate vulnerabilities without delay in relation to the risks posed to the product, including by providing security updates. Article 13 also requires effective vulnerability handling during the support period. This creates a lifecycle model. Before market availability, teams need to prevent known exploitable vulnerabilities from remaining in the product. After release, new vulnerabilities can be discovered or become known, and the manufacturer needs processes to assess, remediate and communicate them appropriately. The same component inventory, triage criteria and engineering ownership can support both stages.

• Use one product inventory across pre-market and post-market processes.
• Maintain a vulnerability intake and triage workflow.
• Connect remediation to supported product versions.
• Provide security updates where required.
• Retain evidence of decisions and remediation.

This Requirement Is Different From Article 14 Reporting

The phrase known exploitable vulnerability in Annex I should not be confused with the Article 14 reporting concept of an actively exploited vulnerability. Annex I Part I point 2(a) is an essential cybersecurity requirement connected to the product being made available on the market. Article 14 creates reporting obligations when its own statutory conditions are met, including for actively exploited vulnerabilities. A vulnerability can therefore require Annex I release analysis without being an Article 14 reporting event. Compliance systems should keep the two legal questions distinct even if the same product-security team handles both. The release gate asks whether the product is being made available with a known exploitable vulnerability. The reporting workflow asks whether a current event meets the Article 14 reporting trigger and timeline.

• Annex I point 2(a): product-security requirement at market availability.
• Article 14: reporting regime with separate statutory triggers.
• Do not use active exploitation as the only pre-release vulnerability test.
• Maintain separate decision records for release and reporting.

Evidence for the Known-Exploitable-Vulnerability Requirement

A manufacturer should be able to reconstruct the vulnerability status of a released product. Useful evidence can include the component inventory, vulnerability scan output, supplier advisories, internal vulnerability reports, exploitability assessments, release-gate approvals, remediation commits, patch records and verification results. Where a known vulnerability is assessed as non-exploitable, the reasoning should be specific enough to review later if the product configuration or threat information changes. Where remediation was required, evidence should show the affected version, fix, retest and released version. This traceability reduces the risk that the same issue is reintroduced or that an undocumented exception persists across releases.

• Product and component version inventory.
• Vulnerability findings and advisory records.
• Exploitability analysis.
• Release decision and owner.
• Remediation evidence.
• Retest results.
• Released product version.