No Known Exploitable Vulnerabilities
In this post we explain what CRA means by that products must not have any exploitable vulnerabilities when they are brought to market (Annex I, Part I, 2a). We also cover vulnerability management during the support period, when relevant vulnerabilities must be addressed or mitigated (Annex I, Part II, 1-3). Further, we discuss the CRA reporting requirement for actively exploited vulnerabilities, which is becoming in effect already in September 2026!
What vulnerabilities are relevant
National Vulnerability Database (NVD) reports tens of thousands of vulnerabilities on a yearly basis, and it is not the only vulnerability reporting platform (https://nvd.nist.gov/). On the other hand, CRA expects you to monitor the vulnerability situation and know which of the published vulnerabilities are relevant for your product. Considering the amount of information, it is impossible to manually track the relevant vulnerabilities and an automated approach is a must.
In relation to CRA, we can identify following set of vulnerabilities, from superset to subset:
From all published vulnerabilities, the vulnerabilities in the software components your product uses(Annex I, Part II, 1)
The exploitable vulnerabilities which you must remediate, e.g. by updates (Annex I, Part I, 2)
The actively exploited vulnerabilities which must be reported to your CSIRT and ENISA (Article 14)
You need to identify and document the vulnerabilities which are in the software components used by your product. As we stated, there are far too many reported vulnerabilities to follow them manually. Thus, you need a software bill of materials (SBOM) of your product and a tool which can filter the vulnerabilities related to your SBOM. With a real world product, the frequency of such vulnerabilities may be anything from zero to dozens per week.
Exploitable vulnerabilities
The next subset are exploitable vulnerabilities. These are the vulnerabilities identified by SBOM which actually could be used to compromise your product, your systems, your customers systems, or otherwise cause disruption. This is subset of the vulnerabilities identified by SBOM for two reasons:
You may have stale components which are not used
You may use the vulnerable component in a way which does not allow exploiting the vulnerability, i.e. vulnerability is not in your attack surface
Let's consider a hypothetical vulnerability in the OpenSSL component which would allow the compromise of a TLS server using OpenSSL. A system may have an OpenSSL component, but if it is not using the component, then there is no exploitable vulnerability. Another system may only use OpenSSL as a client, so the vulnerability is not exploitable. Thus, presence of vulnerable OpenSSL in SBOM does not equal exploitability.
Separation of exploitable vulnerabilities from all vulnerabilities identified by SBOM may be laborious manual work. Nowadays AI is getting clever for analysing source code and this phase is likely to be covered to some extent by AI tools. We are sure to see development on this in the near future.
Vulnerability risk assessment and remediation
Once an exploitable vulnerability is identified, it must be remediated if the risk posed by the vulnerability warrants that. The vulnerability risk assessment should be based on the product risk assessment we covered earlier. Remediation may mean releasing an update which addresses it, e.g. by updating the vulnerable component or changing product configuration or parameter to remove the problems (Annex I, Part II, 2).
In some contexts, updating software components is cheap and convenient. This is the case e.g. in cloud services where updates are easy to apply once new patched components are available. Such an approach requires strong regression testing suites, as component updates may also introduce unwanted changes of behavior. But when possible, such early patching strategy supports strong security posture as vulnerabilities may be fixed before they are exploited. However, there have been cases of supply chain compromises where popular components have been injected with malware which is then automatically installed to dependent systems, e.g. see XZ vulnerability (https://en.wikipedia.org/wiki/XZ_Utils_backdoor) or recent The Axios npm compromise (https://www.cisa.gov/news-events/alerts/2026/04/20/supply-chain-compromise-impacts-axios-node-package-manager). Suggested countermeasures include a short delay before applying automatic updates to allow possible supply chain compromise to be discovered.
Actively exploited vulnerabilities
The third subset of vulnerabilities are the exploitable vulnerabilities which are actively exploited. You can detect these vulnerabilities either via your own intrusion detection systems or by following external information sources, such as NVD, EU NVD (https://euvd.enisa.europa.eu), or CISA (https://www.cisa.gov/) known exploited vulnerabilities catalog.
Starting from September 2026 you must report such vulnerabilities to the Computer Security Incident Response Team (CSIRT) designated as coordinator in your jurisdiction and ENISA, using the upcoming reporting system. The details of this reporting system are unpublished when writing this blog post, but information is available by ENISA (e.g. https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp).
You must provide an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days of a mitigating measure being available. Note that also security incidents, e.g. in your own system, must be similarly reported when they have impact to the product security.
Vulnerability management strategies
As you have noted, vulnerability management is not an easy task and we have not even covered the R&D processes for updating and testing. Due to this, it would be best to minimize the vulnerabilities to worry about. One strategy is to minimize the number of used software components, i.e. have the minimal required SBOM. Then you have less vulnerabilities to identify, analyze and report. However, for many functions components provide well-known and hardened implementations which are likely more secure than what you can implement your own. In such cases the use of external components is recommended and makes your system more secure, even when it does add entries to your SBOM.
CRA expects you to separate security updates from other updates which provide new functions or change existing ones. This makes it easier to apply security updates, as breaking changes are less likely, and promotes overall security posture. You feel the difference yourself when you are considering whether to apply an update to a component to fix a vulnerability - if the update only fixes the vulnerability it is an easier decision than an update which also brings new functionality you must account and test for.
In the next blog post we discuss, at least, different strategies on how to obtain an SBOM and how to get information about published security vulnerabilities.
