FAQEUCyber Resilience Act

EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch

Use this CRA FAQ to understand what the CRA launch-time rule requires, when a vulnerability counts as known and exploitable, and how manufacturers should handle late-stage discoveries before placement on the market.

Built for product security, release, engineering, legal, and compliance teams making CRA launch decisions.

Author
Sorena AI
Published
Mar 10, 2026
Updated
Mar 10, 2026
Sections
18

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 10, 2026
Updated Mar 10, 2026
Overview

The CRA does not require products to be free from all vulnerabilities, but it does bar placing products on the market with known exploitable vulnerabilities. This FAQ focuses on what counts as known and exploitable, how published reports and CVEs should be assessed, and how the launch-time rule differs from the CRA's later vulnerability-handling regime.

Search this module

Find a question or answer quickly

18 of 18 sections
Section 1

Does the CRA require a product to be free from all vulnerabilities before launch?

No.

The CRA does not require a product to be free from all vulnerabilities. It requires that, on the basis of the cybersecurity risk assessment and where applicable, the product be made available on the market without known exploitable vulnerabilities.

Citations
Recommended next step

Use EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch as a cited research workflow

Research Copilot can turn EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ.

Section 2

What is an exploitable vulnerability under the CRA?

The CRA defines an exploitable vulnerability as a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions.

That means the issue is not just whether a weakness exists in the abstract, but whether it can actually be used against the product in the conditions in which the product is expected to operate.

Section 3

What makes a vulnerability "known" for the launch-time rule?

The CRA does not define "known" separately in Article 3, but the draft Commission guidance gives a practical interpretation.

It says an exploitable vulnerability should be regarded as known when it is listed in relevant publicly accessible vulnerability databases, such as the European vulnerability database under NIS2 or other prominent databases such as the CVE List. It may also be known through non-public information, such as coordinated disclosure by a security researcher or the manufacturer's own internal testing and analysis, and through prominent reporting in reliable media outlets. At the same time, the manufacturer still has to verify whether the reported vulnerability is real and actually applicable to its own product.

Citations
Section 4

Does every published CVE or component issue automatically mean the product cannot be launched?

No.

The Commission FAQ says not all vulnerabilities are exploitable under practical operational conditions. Whether a vulnerability is exploitable has to be assessed case by case, taking into account the product's actual operational and technical conditions.

Citations
Section 5

Can a vulnerability remain in the product at launch if it is only theoretical or depends on unrealistic conditions?

Potentially yes.

The Commission FAQ explains that some vulnerabilities are only exploitable in theoretical conditions, such as a lab or simulation, or only under conditions that would not occur in the product's operational environment. In those cases, the manufacturer may conclude on the basis of the risk assessment that the issue is not an exploitable vulnerability for CRA purposes.

Citations
Section 6

Can compensating controls or mitigations matter when deciding whether a vulnerability is exploitable at launch?

Yes.

The Commission FAQ says exploitability has to be assessed case by case and expressly lists existing compensating controls as one of the relevant factors. So a weakness is not assessed in isolation; the manufacturer may take account of controls already in place when determining whether the product would still be placed on the market with a known exploitable vulnerability.

Section 7

Does the CRA launch-time rule on known exploitable vulnerabilities apply only at the moment of placing the product on the market?

Yes.

The Commission FAQ states that the obligation to make the product available on the market without known exploitable vulnerabilities applies at the moment of placement on the market. After that point, the manufacturer remains subject to the separate vulnerability-handling obligations that apply during the support period.

Citations
Section 8

What if a new exploitable vulnerability is discovered after placement on the market but before the product reaches the final user?

The Commission FAQ says the manufacturer is not expected to fix that newly discovered vulnerability before the product reaches the final user, because the Annex I Part I launch-time obligation already applied at placement on the market.

But the manufacturer still has to comply with the vulnerability-handling obligations during the support period. Depending on the risk, that can mean providing a security update or other remedy without delay once the product is in use.

Citations
Section 9

Can a manufacturer rely on a plan to patch later instead of dealing with a known exploitable vulnerability before launch?

No, not if the vulnerability is already known and exploitable at placement on the market.

Inference from the CRA text and the Commission FAQ: Annex I Part I point (2)(a) sets a launch-time condition, and section 4.2.3 of the FAQ makes clear that the later vulnerability-handling obligations are a separate regime that applies after placement on the market. So a post-launch patch plan does not cure a product that was already being placed on the market with a known exploitable vulnerability.

Citations
Section 10

Does the launch-time rule cover vulnerabilities in integrated components as well?

Yes.

The manufacturer's responsibilities apply to the product as a whole, including integrated components. The CRA requires due diligence when integrating third-party components, and both the CRA text and the Commission FAQ make clear that vulnerability handling applies to the product in its entirety, including all integrated components.

Citations
Section 11

Does the CRA launch-time rule require proof that the vulnerability is already being actively exploited in the wild?

No.

The launch-time rule is about known exploitable vulnerabilities. The separate concept of an actively exploited vulnerability appears in Article 14 reporting and uses a different definition. A vulnerability can therefore be relevant to launch compliance even if there is no reliable evidence yet that it has already been exploited by a malicious actor.

Citations
Section 12

Does zero-day status create an exception to the launch-time rule?

No.

The Commission FAQ discusses zero-days only in the context of Article 14 reporting and explains that they become reportable when there is reliable evidence of malicious exploitation. The CRA does not create a separate launch-time carve-out for vulnerabilities merely because no patch is yet available. The relevant launch question remains whether the vulnerability is known and exploitable when the product is placed on the market.

Citations
Section 13

Does the CRA require the manufacturer to have a way to receive and process vulnerability information before launch?

Yes.

The CRA requires appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources. It also requires a coordinated vulnerability disclosure policy, measures to facilitate sharing information about potential vulnerabilities, and a single point of contact for vulnerability reporting. Those obligations are broader than launch alone, but they are also part of how a manufacturer can know whether the product is being placed on the market with a known exploitable vulnerability.

Citations
Cyber Resilience Act

recital 63; recital 76; Article 13(8); Article 13(17); Annex I Part II points (5) and (6); Annex II point (2)

Section 14

What if the manufacturer realises after placement on the market that the product was not in CRA conformity because of a known exploitable vulnerability?

The CRA requires corrective action without delay.

Article 13(21) says that, from placing on the market and for the support period, manufacturers who know or have reason to believe that the product is not in conformity with Annex I must immediately take the corrective measures necessary to bring it into conformity, or withdraw or recall it, as appropriate.

Citations
Section 15

Does a public database entry, CVE, or media report automatically make every product or variant non-compliant at launch?

No.

The draft guidance says that the mere fact a vulnerability is reported as exploitable does not by itself prove that it is exploitable in practice or applicable to the specific product concerned. The manufacturer still needs to investigate the veracity of the report and its applicability to its own product, including the actual operational conditions and any relevant mitigations. A limited period may therefore elapse between the first report and confirmation, but the guidance stresses prompt investigation and reaction.

Citations
Section 16

What if a potentially exploitable vulnerability is discovered shortly before the product is placed on the market?

The manufacturer has to make a risk-based launch decision.

The draft guidance says that late-stage discoveries can happen during the final stages of development, including shortly before the product enters the distribution chain. In that situation, the manufacturer must determine, on the basis of the cybersecurity risk assessment, whether the product can still be securely placed on the market in compliance with the CRA or whether the vulnerability needs to be fixed before launch. The guidance says that decision should take into account the vulnerability's severity, exploitability, potential impact, and the risks arising for the product once in use.

Citations
Section 17

Can unfinished alpha, beta, or release-candidate software be made available for testing even if it is not yet fully compliant?

Yes, under the CRA's specific testing exception.

Article 4(3) says Member States must not prevent the making available on the market of unfinished software that does not comply with the CRA, provided that it is made available only for the limited period required for testing, carries a visible sign stating that it does not comply, and is not made available for purposes other than testing. Recital 37 and the Commission FAQ add that the manufacturer should still perform a risk assessment, comply to the extent possible with the product-property security requirements, and implement vulnerability handling to the extent possible. Article 4(4) adds an important limit: this exception does not apply to safety components covered by Union harmonisation legislation other than the CRA.

Citations
Section 18

If a product type is manufactured in series, can later individual units still be placed on the market without already available relevant patches?

No.

Recital 38 says the essential cybersecurity requirements apply to each individual product when placed on the market, not just to the product type in the abstract. It gives the example that, for a product type, each individual product should have received all security patches or updates available to address relevant security issues when it is placed on the market.

Citations
Primary sources

References and citations

data.europa.eu18 citations
Referenced sections
  • Annex I Part I point (2)(a); Article 13(1)-(3); Article 3(40)-(41)
  • Article 3(40)-(41)
  • Article 13(7)-(8); Article 13(17); Annex I Part II points (5) and (6)
Show 15 more
  • Annex I Part I point (2)(a); Article 3(41)
  • Article 13(2)-(3); Article 3(41)
  • Article 13(2)-(3)
  • Article 13(1); Article 13(8); Annex I Part I point (2)(a); Annex I Part II point (2)
  • Article 13(8); Annex I Part II point (2)
  • Article 13(1)-(3); Annex I Part I point (2)(a); Annex I Part II point (2)
  • recital 34; Article 13(5)-(8)
  • Article 3(41)-(42); Article 14(1); Annex I Part I point (2)(a)
  • Article 14(1)-(2); Annex I Part I point (2)(a)
  • recital 63; recital 76; Article 13(8); Article 13(17); Annex I Part II points (5) and (6); Annex II point (2)
  • Article 13(21)
  • Article 3(41), Article 13(7)-(8), Annex I Part I point (2)(a)
  • Article 13(1)-(3), Annex I Part I point (2)(a)
  • Article 4(3)-(4), recital 37
  • recital 38
ec.europa.eu13 citations
Referenced sections
  • section 4.2.2
  • sections 4.2.3 and 4.3.1
  • section 4.2.3
Show 5 more
  • sections 4.2.2 and 4.2.3
  • sections 4.2.2 and 4.3.6
  • sections 4.2.2 and 5.2
  • sections 4.3.1 and 4.3.4
  • section 1.6
Related guides

Explore more topics

Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking
Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification.
Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking
Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations.
Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking
Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting.
Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking
Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file.
CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales
CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales.
CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies
CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers.
CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities
CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting.
CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products
CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes.
CRA Core Functionality FAQ | Important Products, Critical Products, Classification
CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components.
CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints
CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation.
CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties
CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws.
CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives
CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability.
CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II
CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints.
CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence
Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence.
CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code
CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing.
CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication
CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication.
CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality
CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits.
CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components
CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies.
CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery
CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine.
CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification
CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs.
CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation
CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation.
CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance
CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities.
CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation
CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking.
CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies
CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking.
CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking
CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records.
CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence
CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting.
CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions
CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories.
CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths
CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths.
CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards
CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions.
CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope
CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences.
CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation
CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope.
CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility
CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements.
CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products
CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications.
CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions
CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions.
CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits
CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability.
CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)
CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates.
CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products
CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment.
CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability
CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability.
CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence
CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence.
CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates
CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats.
CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay
CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software.
CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions
CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates.
CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices
CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices.
CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking
Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply.
CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking
Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule.
CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing
CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing.
Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking
Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date.
Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking
Understand the CRA essential cybersecurity requirements in Annex I.
Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking
Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure.
Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking
Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes.
Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking
Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing.
Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking
Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting.
SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking
Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence.
Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking
Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence.
Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking
Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates.