.png&w=3840&q=75&dpl=dpl_GSH2XAPmfvP8dv9ByxAbrt3ftoW4)
What does "no known exploitable vulnerabilities" mean under the CRA?
Direct answer
The Cyber Resilience Act requires products to be placed on the market without known exploitable vulnerabilities (Annex I). It is a release-quality duty, distinct from the separate obligation to report vulnerabilities that become actively exploited later. The CRA is technology-neutral, so it does not mandate CVSS, EPSS or any specific scoring model.
Key takeaways
- Annex I requires shipping free of known exploitable vulnerabilities.
- Different from an "actively exploited vulnerability," which is the Article 14 reporting trigger (Art. 3(42)).
- Technology-neutral: CVSS, EPSS and CISA KEV are useful inputs, not legal requirements.
- Requires a defensible, systematic triage, not a single number.
- Continuous handling still applies after release across the support period.
The full answer
"No known exploitable vulnerabilities" is a release-quality requirement: a product must be made available on the market without known exploitable flaws and with a secure default configuration (Annex I). It is not the same thing as the reporting trigger. An "actively exploited vulnerability," which starts the 24-hour reporting clock, is one with reliable evidence of real-world malicious exploitation (Art. 3(42)); the Annex I duty is about what you ship, not only what you later detect.
The CRA is deliberately technology-neutral. It requires a risk-based, systematic approach to identifying and handling vulnerabilities, but it does not codify CVSS, EPSS or the CISA KEV catalogue. Using them is sensible for demonstrating a defensible triage process; stating that they are legally mandated is incorrect. What the regulation expects is a documented decision, not a specific score.
How Acuna GRC handles it
- Solution
CRA
Track every vulnerability to a verified fix, keep CRA technical documentation, record exploited vulnerabilities, check component suppliers and reuse NIS2.
- Module
Vulnerability management
Vulnerable items from your scanners rolled up into one issue per vulnerability, with an owner and a due date.
- Module
Integrations and API
Connect Acuna GRC to the security, identity, device, HR, cloud, code, scanner and ticketing tools you already run, with webhooks and an API.
Sources
This page explains the rules in general terms and is not legal advice.
See how Acuna GRC runs this.
Tell us your frameworks and your team. We show you how Acuna GRC runs the program.
Hosted in Switzerland, the EU or the US