AA-sec logo AA-sec
Product Security

Known Exploitable Vulnerabilities Under the CRA: Release Gate Evidence

A practical guide to deciding whether a known exploitable vulnerability blocks CRA market placement, with product-specific triage, release-gate evidence, and documented decisions.

AA-sec24 August 2026
  • CRA known exploitable vulnerability release gate
  • Cyber Resilience Act known exploitable vulnerabilities
  • CRA release vulnerability gate
  • CRA exploitable vulnerability market placement
  • CRA Annex I known vulnerabilities
  • CRA vulnerability release evidence
Cover graphic showing a product release gate linked to vulnerability findings, exploitability analysis and retained security evidence.

A vulnerability finding should block Cyber Resilience Act (CRA) market placement when the manufacturer has established that the vulnerability is known and exploitable in the specific product under practical operational conditions, and the product would otherwise be made available on the market with that condition unresolved. The CRA does not create a rule that every CVE, scanner hit or vulnerable component automatically blocks every release. A defensible gate therefore depends on product-specific analysis and retained evidence, not on a raw vulnerability count.

The legal wording matters. Annex I Part I point 2(a) requires, on the basis of the cybersecurity risk assessment and where applicable, products with digital elements to be made available on the market without known exploitable vulnerabilities. Article 6 connects market availability to the Annex I requirements. An internal "release gate" is an engineering control for enforcing that condition; it is not a term defined by the CRA.

Start with the CRA definition of exploitable

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 then defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions.

That definition makes product context essential. A vulnerability identifier may be associated with a dependency version, but the manufacturer still has to determine whether the vulnerable behaviour exists and can be used in the actual product.

Relevant questions include:

  • Is the affected component and version present in the release artifact?
  • Is the vulnerable function compiled, loaded or invoked in the supported configuration?
  • Is the attack path reachable through an interface available under intended or reasonably foreseeable use?
  • What privileges, credentials, network position or prior access are required?
  • Do product controls prevent the conditions needed for successful exploitation?
  • Has a fix or mitigation changed those conditions, and has that change been verified?

These are evidence questions, not an automatic checklist for proving non-exploitability.

Known does not mean only publicly listed

The CRA defines exploitability but does not provide a closed list of when an exploitable vulnerability becomes "known" to the manufacturer. The Commission's July 2026 guidance provides practical interpretation for manufacturers.

The guidance identifies several ways relevant knowledge can arise: a relevant publicly accessible vulnerability database, non-public information such as coordinated disclosure, the manufacturer's own internal testing and analysis, or prominent public reporting in reliable media.

A release gate therefore cannot rely only on one public CVE feed. Inputs should also cover supplier and maintainer advisories, disclosure channels, internal security testing, penetration-test findings and other credible sources that can make the manufacturer aware of a vulnerability.

Awareness of a report is still not proof that the weakness is exploitable in the manufacturer's product. Keep a triage state between "signal received" and "release decision complete" so unverified findings are neither ignored nor automatically treated as confirmed blockers.

Do not confuse exploitable with actively exploited

The CRA uses two different terms.

An exploitable vulnerability has the potential to be effectively used by an adversary under practical operational conditions. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.

Annex I Part I point 2(a) concerns known exploitable vulnerabilities. It does not require evidence that attackers are already exploiting the issue.

Article 14 reporting, by contrast, concerns actively exploited vulnerabilities. Those reporting obligations apply from 11 September 2026. A vulnerability can therefore be important enough to block market placement without yet meeting the separate Article 14 reporting trigger. If reliable evidence of malicious exploitation exists, assess the reporting obligation as a separate workflow.

The legal gate is market placement, not every engineering release

Engineering teams use "release" for builds, release candidates, test deployments, validation images and commercial deliveries. The CRA requirement discussed here is tied to making a product with digital elements available on the market.

The main CRA product obligations apply from 11 December 2027. An internal delivery process can place the vulnerability gate earlier, but that is an engineering control intended to prevent an unresolved known exploitable vulnerability from reaching the market-placement point.

This avoids two mistakes. A failed CI scan should not automatically be labelled a CRA violation: the finding still needs product-specific analysis, and an internal artifact may not yet be made available on the market. Conversely, exploitability analysis should not be postponed until the final commercial hand-off, when remediation may be much harder.

Build the gate around decisions, not severity thresholds

A single severity score is a weak release rule. CVSS and vendor severity can help prioritise investigation, but Annex I point 2(a) asks whether a known exploitable vulnerability remains in the product when it is made available on the market.

A practical gate should maintain at least three states.

Candidate requires investigation

Use this when a scanner, advisory, disclosure or test identifies a plausible vulnerability but product applicability or exploitability is not yet established. Preserve the source, identifier, affected-component claim, first-seen time, product scope and investigation owner. Insufficient evidence should not silently become a pass.

Not exploitable in this product context

Use this only when evidence shows that the vulnerability cannot be effectively used under the product's practical operational conditions.

Evidence might show that the affected component is absent from the shipped artifact, the vulnerable code path is not present, the relevant feature is unavailable, or a verified control removes the practical exploitation path. Scope the conclusion to the exact product, variant and release for which the evidence is valid.

Do not automatically copy that conclusion to later releases. A build flag, dependency update, feature enablement or deployment change can invalidate the reasoning.

Exploitable and unresolved

If the vulnerability is known, applies to the product and remains practically exploitable, treat it as a market-placement blocker for the Annex I point 2(a) condition. Fix it or implement and verify a change that removes practical exploitability before the product is made available on the market.

A plan to issue a security update after launch is not equivalent to satisfying a requirement that applies at market placement. Post-market vulnerability handling remains a separate lifecycle obligation.

Keep the evidence tied to the exact release

A gate is defensible only if another reviewer can reconstruct why the product passed or failed.

For each material vulnerability decision, retain:

  • the vulnerability identifier and source;
  • the date the manufacturer became aware of the signal;
  • the product, variant, release and artifact identity in scope;
  • the relevant component identity and version;
  • the SBOM or component evidence used to establish presence;
  • the exploitability analysis under practical operational conditions;
  • assumptions about configuration, privileges, connectivity and deployment;
  • fix or mitigation details;
  • verification and regression-test results;
  • the updated cybersecurity risk assessment where applicable;
  • the decision owner and reviewer; and
  • the final approve, investigate or block outcome.

Artifact identity matters. A decision attached only to a product name may not establish which binary or firmware image entered distribution. Use a version, build identity, hash or another stable release reference.

Connect the gate to the cybersecurity risk assessment

Annex I point 2(a) is explicitly connected to the cybersecurity risk assessment in Article 13(2). The gate should therefore not operate as an isolated scanner policy.

The risk assessment provides context for intended purpose, reasonably foreseeable use, relevant threats and applicable essential cybersecurity requirements. Vulnerability analysis contributes product-specific facts back into that assessment. Article 13 also requires manufacturers to document relevant cybersecurity aspects, including vulnerabilities of which they become aware and relevant information provided by third parties, and to update the cybersecurity risk assessment where applicable.

A useful flow is:

  1. The risk assessment defines the product context against which exploitability is evaluated.
  2. Vulnerability intake identifies new facts that may change the risk picture.
  3. The exploitability decision records whether the finding affects the product under those conditions.
  4. A required fix or mitigation is implemented and verified against the exact release.
  5. The market-placement decision references the current vulnerability state and supporting evidence.
  6. New information can reopen the decision and, where applicable, the risk assessment.

This keeps the gate connected to the technical documentation instead of becoming a separate spreadsheet.

Use SBOM data as discovery evidence, not as the decision

A release-specific SBOM is a strong input to vulnerability triage because it helps establish which components are present. It is not an exploitability conclusion.

Correlate the SBOM with public vulnerability information, supplier advisories and internal findings, then create a separate product-specific vulnerability decision. If a component is reported as vulnerable, use the SBOM to establish presence and version scope before analysing reachability and practical exploitation conditions.

VEX can help communicate the result. A VEX record can express a product-specific affected, not-affected, fixed or under-investigation status with rationale. The CRA does not require VEX by name, and a VEX status is not a conformity decision.

Treat mitigations as claims that require verification

A mitigation should not become a release pass merely because it exists in a ticket.

If the conclusion is that a control removes exploitability, retain evidence showing that the control is present in the release and works under the conditions assumed by the analysis. Depending on the issue, this can involve configuration tests, negative exploitation tests, code-path analysis, access-control checks, network exposure checks or regression tests.

"Risk accepted" is not the same as "not exploitable under practical operational conditions." The first is an internal governance statement. The second is a technical conclusion relevant to the Annex I market-placement requirement and needs evidence.

If a mitigation depends on user action or a specific deployment condition, document that dependency and verify that the assumption is consistent with intended purpose, reasonably foreseeable use and other applicable CRA requirements.

Use emerging standards work as implementation guidance, not as law

Current ETSI STAN4CRA draft work maps "no known exploitable vulnerabilities" to technical requirements and points to evidence such as vulnerability scanning results, recognised public sources, product identification and documented conclusions.

That work is useful for designing a gate, but draft standards work is not the CRA itself. A draft does not create a presumption of conformity merely because a team follows it. Keep the legal decision anchored to Regulation (EU) 2024/2847, the applicable conformity-assessment route and current official guidance.

A compact release-gate workflow

A practical workflow can be implemented without turning every vulnerability into a release meeting.

  1. Freeze product scope. Identify the product, variant, release and artifact that could be made available on the market.
  2. Collect current vulnerability signals. Correlate component data with public databases, supplier advisories, disclosures and internal testing.
  3. Resolve identity. Confirm that component names and versions refer to what is actually present.
  4. Investigate applicability. Determine whether the reported weakness exists in this product.
  5. Assess practical exploitability. Evaluate attack path, required access, configuration, reachable functionality and relevant controls.
  6. Fix or remove exploitability. Implement the required change when a known exploitable vulnerability affects the product.
  7. Verify the change. Retest the exact release candidate and retain the result.
  8. Update risk and technical evidence. Connect the decision to the risk assessment and release documentation.
  9. Approve or block market placement. Record the accountable decision against the exact release.
  10. Preserve and revisit. Keep superseded decisions and reopen them when new information or product changes invalidate earlier assumptions.

The same workflow can feed post-market vulnerability handling after market placement. The difference is the decision point: before placement, the gate supports Annex I Part I point 2(a); after placement, Part II vulnerability handling, security updates and, where relevant, Article 14 reporting govern the next actions.

Release-gate evidence becomes difficult to govern when SBOM data, vulnerability findings, exploitability analysis, verification evidence and approvals live in separate systems. AA-sec is designed around traceability between SBOM and component data, vulnerability work, security evidence, release decisions and exact product or lifecycle context, which fits this control pattern. AA-sec does not determine whether a vulnerability is exploitable or whether a product conforms to the CRA; those remain engineering and legal decisions for the manufacturer.

Key takeaway

The CRA does not turn every vulnerability alert into an automatic release prohibition. The market-placement question is narrower: does this exact product release contain a vulnerability that is known to the manufacturer and exploitable under practical operational conditions?

A useful release gate answers that question with evidence. It connects current vulnerability signals to the exact product and artifact, records the exploitability analysis, verifies fixes or mitigations, updates the cybersecurity risk assessment where needed, and preserves the approve-or-block decision. That is stronger than a severity threshold, a scanner screenshot or a generic "risk accepted" note.

Official sources