Annex I Part I (2)(a) No known exploitable vulnerabilities

Annex I Part I (2)(a): no known exploitable vulnerabilities before EU market placement

Point (2)(a) of Annex I, Part I asks the manufacturer to make a product with digital elements available on the EU market without known exploitable vulnerabilities. The requirement applies on the basis of the manufacturer's cybersecurity risk assessment and where applicable, so the decision is not a checkbox that depends on a single scanner result. Before a product is placed on the market, the team must be able to show what it knew about weaknesses in the product, judge whether each one could realistically be used by an attacker under practical conditions, and record why it released the product. Under Article 3(41), an exploitable vulnerability is one that an adversary could effectively use under practical operational conditions, so a flaw that is theoretical or unreachable in the product's real configuration is treated differently from one that is not.

The point is hard in practice for three reasons. First, most products contain third-party and open-source components whose vulnerabilities the manufacturer did not write and may learn about late. Commission FAQ 4.4.2 lists checking the European vulnerability database or other public databases and performing software composition analysis as due diligence steps for these components. Second, a vulnerability becomes known through several routes: public databases, private reports through coordinated disclosure, internal testing, or prominent reporting in reliable media. Commission guidance C(2026) 5252 treats each of these as making a vulnerability known, so the release team must watch all of them up to the moment of placement. Third, the regulation sets no fixed severity threshold. The guidance allows the manufacturer to weigh severity, exploitability, impact and the risk of delaying release, so the team must confirm its own criteria with its risk owners and write them down before a release date is fixed.

Timing matters. The regulation applies from 11 December 2027, and products already on the market before that date fall under it only if they are substantially modified from that date. Any release made after that point, including a new version of an existing product, must meet this point. Confirm with counsel or your market surveillance contact how your product's release history maps to the substantial modification test, and confirm which of your components are in scope for the vulnerability checks described in the Commission guidance at the Commission's guidance on applying the regulation.

What counts as a known exploitable vulnerability under the CRA

Point (2)(a) turns on two words: known and exploitable. The cards below separate the definitions in Article 3 from the routes by which a flaw becomes known, and show where the manufacturer keeps its own judgment about release timing.

What a vulnerability is

Article 3(40) treats a vulnerability as a weakness, susceptibility or flaw that a cyber threat can exploit. The definition is broad: it covers flaws in code, configuration and design, not only published CVEs. For point (2)(a), check every component and feature the product ships, including third-party libraries, and record which weaknesses your testing has covered and which it has not.

What makes a vulnerability exploitable

Article 3(41) describes an exploitable vulnerability as one an adversary could effectively use under practical operational conditions. A flaw that needs unrealistic access, a lab configuration or an unusual setting may not meet this bar. Assess exploitability against how the product is actually deployed, and document the conditions you assumed so an assessor can test that reasoning.

Public database listings

Commission guidance C(2026) 5252 treats a vulnerability as known when it appears in public vulnerability databases, such as the European vulnerability database. Scan installed components against these sources on a schedule and at each release. A listing found after release still counts, so the process must cover the full support period.

Private discovery and disclosure

A flaw is also known when the manufacturer learns of it privately, through coordinated disclosure, internal testing or a penetration test. Findings from your own security testing and from external researchers reach the same standard, so they must enter the release decision and the vulnerability record. Confirm that your intake channel routes reports to the people who make that decision.

Prominent reporting in reliable media

The guidance also treats a vulnerability as known when reliable media report it prominently. This route is easy to miss because it sits outside security feeds. Assign someone to monitor advisories and press coverage for the components and vendors in your bill of materials, and log the date each item was seen.

Risk-based release discretion

The guidance describes the obligation as risk-based. You may weigh severity, exploitability, impact and the risks of delaying release when deciding whether a newly known flaw must be fixed before the product reaches the market. Record each weighing in writing, with the reasoning, the decision owner and the date, because the decision is what an assessor will examine.

How an assessor tests the no known exploitable vulnerabilities requirement

This table sets out the steps an independent assessor is likely to take when testing Annex I Part I point (2)(a), the evidence each step asks for, and the findings that commonly come up. Read each row as a test the manufacturer should be able to pass with records already in hand. The main takeaway is that the release decision, the scan timestamps and the component inventory must line up, because an assessor will check them against each other.

Test step	Evidence requested	Common findings
Review the cybersecurity risk assessment for the (2)(a) decision	Current risk assessment, the criteria used to weigh severity, exploitability and impact, and the version history showing when it was last updated	Risk assessment does not mention known vulnerabilities at all, or was last updated before the current release
Review the release decision record for each version placed on the market	Signed release decision per version, listing the vulnerabilities considered and the reason each was fixed, deferred or accepted	No decision record exists for a release, or the record names no vulnerabilities despite scan output showing findings
Sample pre-release vulnerability scan results	Scan reports for sampled releases, with tool name, tool version, vulnerability database source and the date the scan ran	Scan timestamps missing or later than the release date, so the scan cannot be shown to precede the decision
Compare the component inventory against what shipped	Software bill of materials for the sampled release, checked against the build artifacts and the scanned inventory	Inventory omits transitive dependencies, container base layers or vendored libraries, so their vulnerabilities were never assessed
Check how known vulnerabilities in third-party components were handled	Records of database checks (such as the European vulnerability database or other public sources), supplier notices and triage tickets with outcome	Known vulnerabilities in integrated components have no triage entry, or triage relies only on supplier statements with no independent check
Confirm that each accepted or deferred risk was justified	Written justification covering exploitability under practical conditions, compensating controls, expected fix date and approver	Accepted risks recorded without justification, approver or review date, or exploitability assumed without evidence
Test whether the decision process is repeatable	Procedure for scanning and release gating, plus evidence that the gate ran for the sampled releases	Procedure exists on paper but the gate was skipped for some releases, with no documented exception
Confirm the scope of the inventory and scan against the product	Product boundary description and list of components in scope, including hosted or third-party cloud services built into the product	Scope excludes components the product actually depends on, so the assessor cannot rely on the scan result

Steps to make the release decision without known exploitable vulnerabilities

This sequence turns the point (2)(a) requirement into a repeatable release gate: the manufacturer inventories what the product contains, scans it before release, triages what it finds, decides how each known exploitable vulnerability is handled, and signs off the decision on record before the product is placed on the market.

Build the component inventory
The product owner and the engineering lead list every component the release contains, including the operating system packages, libraries, containers, firmware, and third-party or open-source dependencies that are built in or shipped alongside the product. The output is a software bill of materials for each release, generated from the build pipeline rather than typed by hand, with versions and supplier or source recorded for each entry. The step is done when the inventory matches the build artifacts and someone other than the author has checked it against the bill of materials for the release candidate.
Scan the release candidate before release
The security engineering team runs vulnerability scans against the release candidate and against the inventory from the previous step, covering the operating system, installed applications and declared dependencies. Dependency-aware tools can scan an existing SBOM as well as the build output, so the result does not depend on one method. The output is a raw findings list tied to the exact release build, with the scanner name, the data source and the date of the vulnerability database used. Ask your tooling team to confirm which sources each scanner consults and how often they refresh.
Confirm which findings are known and exploitable
Security engineers review each raw finding and decide whether it is a known vulnerability in the sense of the regulation: listed in a public vulnerability database, learned privately through coordinated disclosure or internal testing, or prominently reported in reliable media. They then test whether it could be used by an adversary under the conditions the product actually runs in, which is the exploitable vulnerability test. The output is a triaged list that separates confirmed exploitable issues from false positives, unreachable code paths and issues the product does not expose, with the reasoning written next to each entry.
Assess severity, exploitability and impact
For each confirmed item, the product security lead records the severity score, the likelihood of exploitation in the product's intended environment, the impact on users and on the product's essential functions, and the risks that delaying release would create. These are the factors the Commission's guidance says the manufacturer may weigh. The output is a risk record per finding, linked to the cybersecurity risk assessment from Article 13(2), so that the release decision can be traced back to the documented risk model. The step is done when every confirmed finding has a severity, an exploitability judgment and an impact statement.
Decide to fix, defer or accept each risk
The product owner, with security and legal input where needed, chooses for each finding whether to fix it before release, defer it to a scheduled security update with a stated plan, or accept the residual risk with a documented justification and any compensating controls. The decision must rest on the risk record from the previous step, not on schedule pressure alone. The output is a decision log entry per finding stating the option chosen, the reason, the owner and any condition for revisiting it. Ask whether your organization has a defined approval threshold for accepted risk and who holds that authority.
Re-scan and verify the fixes
Engineers apply the chosen fixes, rebuild the release candidate and repeat the scan and triage against the new build. They confirm that each fixed item is no longer present or no longer exploitable in the product, and that no new known exploitable vulnerability has entered through an updated dependency. The output is a verification report that compares the before and after findings for the same release identifier. The step closes when the report shows that every item marked as fix is resolved and every accepted item still matches its record.
Record the sign-off before placing on the market
The accountable manager for the product signs a release record that references the final SBOM, the scan and verification reports, the decision log and the risk assessment version in force. The record states that the product is placed on the market without known exploitable vulnerabilities, except for any residual risks accepted and documented in the decision log. The output is a signed, versioned release record kept with the technical documentation for the support period. Confirm with your compliance lead which evidence the conformity assessment route will require and how long the record must be retained.

Evidence that shows no known exploitable vulnerabilities at release

An assessor looking at point (2)(a) will ask one question: what did the manufacturer know about exploitable vulnerabilities when the product was placed on the market, and how was that knowledge acted on? The cards below describe the records that answer it, and how each release carries its own copy of them through the support period.

Release software bill of materials

A component inventory for each release lists every first-party and third-party component, with versions, licenses and supplier. It is the starting point for everything else, because a vulnerability can only be matched against components you know you ship. Keep it in a machine-readable format such as CycloneDX or SPDX, generated from the build rather than typed by hand, and confirm that it covers firmware, container layers and bundled libraries, not only the application code.

Dated scan outputs and sources

Each scan record should state the date it ran, the tool and version, and the vulnerability sources it queried. A result without those details cannot be reproduced or defended later. Ask the team to confirm which databases were used, including whether an offline copy was synchronized, and to keep the raw output alongside the summary so an assessor can see what was reviewed.

Triage record for each finding

Every finding needs a recorded disposition: fixed, mitigated, not affected, or under review with an owner and a date. Record whether the vulnerability is known in the sense of the Commission guidance, meaning listed in a public database, reported privately to the manufacturer, or prominently reported in reliable media. Triage notes should state the severity, exploitability and impact that were weighed, so the decision can be traced.

Documented decisions on accepted risk

Where a known vulnerability stays in a release, the risk acceptance must name the approver, the reasoning and the compensating controls. The guidance treats the decision as risk-based and weighs the risks of delaying release, so the record should show that delay was considered against exposure. Re-review accepted risks whenever a new fix, exploit or deployment change appears, and state the review date.

Link to the risk assessment

Each triage decision and accepted risk should point back to the Article 13(2) cybersecurity risk assessment and to the point (2) requirements it affects. This shows why a finding was treated as it was, and it lets an assessor check that the risk assessment was actually applied at release. Confirm that the reference is stored in the record itself, not only in someone's memory of the review.

Per-release currency through support

Each release needs its own copy of this record, generated from that release's build and dated at its release. Earlier records are not updated to describe later code. Ask how the team ties a release identifier to its SBOM, scan run and decisions, and how it re-runs scans on the support schedule so that new vulnerabilities in already-shipped components are identified and handled through the process in Annex I Part II.

What meeting this requirement costs in money and effort

This table lists each cost component of meeting point (2)(a), who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, since no fixed amounts are published for this requirement. The main takeaway is that most of the cost recurs with every release, so the cheapest route is an inventory and triage process that runs automatically.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Scanning tools and licenses	Tool vendors, or no license fee for self-hosted open-source scanners	Recurring if commercial; open-source tools carry no license fee but still need hosting	Number of products and environments scanned; self-hosting Wazuh, Dependency-Track or Trivy can remove license spend, though hosting and staff time remain
Initial software inventory and SBOM build	Internal engineers or an implementation partner preparing the build pipeline	One-time for pipeline setup, then mostly recurring maintenance	Dependency count, build system complexity and number of languages or package managers in use
Engineering time for triage	Internal product security or development staff	Recurring, every release and every new public or private disclosure	Number of components, quality of vendor advisories, and whether exploitability analysis is documented per finding
Risk-based release decisions and documentation	Internal security, product owner and legal or compliance reviewers	Recurring per release	Number of open findings at release time and how many need a documented exception with reasoning
Evidence upkeep per release	Internal release engineering, sometimes supported by an implementation partner	Recurring per release	Release frequency, number of product variants and how much of the evidence is generated automatically
External penetration testing or code review	Independent testing firm, chosen by the manufacturer	Recurring if performed each cycle; optional under the requirement	Product size, attack surface, and whether testing is scoped to the release under assessment; request a written scope and deliverables
Notified body or auditor sampling effort	Notified body or auditor for the assessed products, plus internal staff for requests	Per assessment; repeats when substantial changes occur	Applicable conformity route, sample size chosen by the assessor, and quality of evidence already on file; confirm the route first

How open-source scanners can produce the release evidence

Open-source tooling can produce much of the evidence a manufacturer needs to show that no known exploitable vulnerabilities were in a product at release. The starting point is an inventory. Trivy (Apache-2.0) identifies the OS packages and software dependencies in a build target and can output them as a software bill of materials, or scan an existing SBOM supplied by a component vendor. Run against each release candidate, the scan output, the SBOM and the scan timestamp form a dated record that ties a specific artifact to the components it contains. Confirm with your engineering team which artifact types (container images, firmware images, package archives) your pipeline can feed into the scanner, because coverage depends on the target format.

OWASP Dependency-Track (Apache-2.0) takes that inventory one step further. It consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities and outdated or modified components, and tracks license risk by SPDX license ID. VEX statements are where the risk-based decision is recorded: a manufacturer can document that a listed vulnerability is not exploitable in the product's configuration and explain why, which is the kind of reasoning the Commission guidance expects to see. Decide who signs off on each VEX entry and keep the project history, since that history becomes part of the technical documentation.

Wazuh (GPL-2.0-only) and Fleet (MIT) match installed software against vulnerability sources, but they monitor deployed endpoints rather than unreleased builds. They may fit build or operations evidence, such as showing the state of a managed test or staging fleet, but they are unlikely to replace a pre-release component check on their own. Confirm with your assessor and your pipeline owner whether an endpoint-based record satisfies your release process for your product type before relying on it.

Who owns this requirement inside the team and who can help

The manufacturer owns Annex I point (2)(a) in full. Under the regulation, the obligation to place products on the market without known exploitable vulnerabilities sits with the manufacturer, and no outside party can take over the release decision or the documented reasoning behind it. Product security defines the risk-based criteria for what must be fixed before release, engineering maintains the component inventory and fixes findings, release management applies the gate before each placing on the market, and legal checks the declaration and technical documentation wording.

Product security: sets severity and exploitability thresholds, owns the triage policy and signs off on accepted risks.
Engineering: keeps the software bill of materials current, fixes or upgrades vulnerable components and records the fix version.
Release management: enforces the scan result as a release gate and stores the decision record with the build.
Legal and compliance: confirms that the documented position matches what the product declares and what the risk assessment states.

Check that each role has a named owner, a backup and a documented decision authority before the first release under the regulation.

Where manufacturers usually fall short on this point and how to close each gap

Most failures under point (2)(a) are not about missing a scanner. They come from incomplete inventories, stale checks, undocumented decisions and release gates that never see the risk assessment. The cards below take each gap in turn and give the fix that closes it.

Inventories that miss transitive components

Teams often inventory only the libraries they declared directly, while the vulnerable package sits two or three layers down in a dependency tree or inside a vendored copy checked into the repository. Under point (2)(a) a known exploitable flaw in any integrated component counts, so the inventory has to be built from the build output, not the manifest. Generate an SBOM from the built artifact and check that it lists nested and vendored code. Ask whether the inventory covers code copied into the source tree without a package manager record.

Scans run once, not per release

A clean scan from the first beta says little about the build shipped six months later, because new advisories are published against components that were already in the product. Point (2)(a) applies at the moment the product is placed on the market, so the check must run against each release candidate. Gate the pipeline so that a release candidate is scanned and the result is stored with the build identifier. Confirm that a scan result cannot be reused for a build with different components.

Undocumented risk acceptances

Commission guidance treats the release decision as risk-based, which means a known vulnerability may ship if the manufacturer has weighed it. An accepted risk that exists only in a chat thread or a developer's memory cannot be shown to an assessor or market surveillance authority. Record each accepted vulnerability with its severity, the exploitability assessment, the affected function, the compensating controls and the person who approved it. Set a review date so that acceptances do not persist silently into later releases.

Reliance on a single vulnerability source

A product checked only against one database will miss flaws that another source has already recorded, and an empty result from one feed does not prove that no vulnerability is known. Known status can arise from public databases, private disclosure and reliable media, so the check should draw on several sources. Combine the European vulnerability database with other public databases and vendor advisories for the ecosystems you ship. Confirm which sources your tooling queries and whether it can run against a local, offline copy of the data.

Release decisions detached from the risk assessment

When the scan result goes to one team and the risk assessment lives in another document, release decisions drift away from the stated risks of the product. Point (2)(a) is applied on the basis of the manufacturer's cybersecurity risk assessment, so the assessment should define how severity and exploitability are judged and which vulnerabilities must block release. Link each release record to the assessment version it relied on. Check that a change in the assessment, such as a new intended use, triggers a fresh review of open findings.

Questions buyers ask about meeting point (2)(a)

How much effort does meeting Annex I point (2)(a) take?

The effort depends mostly on how many third-party and open-source components a product contains, how many release lines it has, and how mature the existing vulnerability triage process is. Work falls into three parts: building a software bill of materials for each release, scanning components and internal builds against public vulnerability sources, and recording a release decision for every newly known vulnerability. A product with a small, well-inventoried dependency tree needs far less effort than a product built on a large stack of inherited libraries. The one-time work is setting up the inventory, scanning pipeline and decision template. The recurring work is triage of new findings for every release through the support period. Ask any partner to size the effort from your actual component count and release cadence, not from a generic estimate.

How long does a first pass at point (2)(a) usually take?

No duration for this work has been fixed in the regulation or in the Commission guidance, so any timeline you hear should come with its assumptions written down. A first pass usually covers the current product release, its full component inventory, one scan of that inventory, and a documented decision for each finding that is not clearly fixed. The main variables are the size of the inventory, whether an SBOM already exists, and how many findings need an engineering decision. Ask a partner to state the scope, the products and releases included, the deliverables, and the dates in a written plan before work starts. DeployOpen agrees scope, deliverables and timelines in writing before work begins, so a first pass should be scoped against your products rather than quoted as a standard duration.

What does the internal engineering team need to provide?

The internal team owns the product, so it must supply the knowledge that a scanner cannot produce. Engineers need to provide:

Build and release pipeline access, so the inventory reflects what ships rather than what a developer remembers.
Component ownership, including which team is responsible for each third-party library and each vendored dependency.
Decisions on exploitability in the product's real configuration, since a vulnerability in an unused code path may carry different risk.
Approval of the release decision, recorded against the Article 13(2) cybersecurity risk assessment.

Product and security leads also need to agree the severity, exploitability and impact criteria used in the risk-based decision. Without those inputs, any outside help can build tooling and documents, but the decisions remain unsupported.

Can a small team meet point (2)(a) without outside help?

A small team can meet point (2)(a) alone if it owns a clear build pipeline, keeps a current component list, and has someone accountable for triage. The open-source tools used for this work, including Dependency-Track, Trivy and Wazuh or Fleet for endpoint inventory, are free to use under their licenses, so the main cost is staff time rather than licensing. Teams most often struggle with the decision record: they fix the obvious findings but do not document why a deferred finding was acceptable at release. A small team should confirm three things before starting: who signs release decisions, how new vulnerability sources are monitored, and how the records will be kept for the support period. Outside help is most useful for setting up the tooling, reviewing the first set of decisions, and preparing the technical documentation.

Does point (2)(a) require a notified body?

Point (2)(a) does not by itself require a notified body. Under the regulation, most products follow self-assessment under module A, and a notified body is needed only for certain class I important products, class II important products and critical products. The conformity route depends on the product's classification, so the first step is confirming which category applies. Even where a notified body is involved, it assesses the manufacturer's conformity; it does not perform the vulnerability work for you. Confirm the classification and conformity route against the regulation and the Commission FAQs before budgeting for any third-party assessment.

What should I ask a partner for in a quote for point (2)(a)?

A quote should follow from a written scope, so ask for the scope before the price. Request a list that states:

The products, versions and release lines covered, and the component inventory method.
The scanning sources used and how they are kept current.
The deliverables, such as the SBOM, scan results, decision records and a documentation template.
Which tasks the partner performs and which remain with your engineers and product owners.
What is one-time work and what recurs for each release through the support period.
What the partner does not provide, including the independent assessment or any certificate, which only an independent body can issue.

DeployOpen does not publish a price list and provides a quote from the written scope.

How DeployOpen scopes and prepares evidence for point (2)(a)

DeployOpen works on point (2)(a) as an implementation partner: we prepare the scanning, component analysis and release records that show how known exploitable vulnerabilities were checked before release. The manufacturer keeps the risk-based release decision, and DeployOpen does not issue any conformity assessment, report or certificate.

How we scope

Our written scope names the products, release pipelines and component inventories that fall under point (2)(a).
We agree which public vulnerability sources and private disclosure channels the release decision will check.
The scope states who owns the risk-based release decision and which roles sign off on it.

How we build

We deploy self-hosted software inventory and vulnerability detection inside your own infrastructure, with no data leaving your environment.
We connect SBOM generation and component analysis to your build pipeline so each release has a recorded component list.
We test the pipeline gates on a sample release and confirm that findings reach the people who make the release decision.

How we hand over

You receive a documented procedure for checking known vulnerabilities, with the sources, tools and thresholds used.
Release records show each scan, the findings reviewed, the decision taken and the reasoning for any accepted risk.
Handover includes runbooks and a review of the evidence set so your internal team or your assessor can trace each decision.

How we support

Ongoing support is available as a retainer, covering tool upgrades, database updates and changes to the component inventory.
We can review new findings against the release decision record and help you update the documentation when a product changes.
Confirm with us in writing which support level covers vulnerability database maintenance and how quickly changes to the scope are handled.