CVEs, Vulnerability Handling, and Reporting under the CRA

Two statements come up in almost every conversation about the Cyber Resilience Act. The first: “Since September, we have to report every vulnerability.” The second: “And we have to fix every CVE in our components.” Both are wrong. They drive up effort that the regulation does not require anywhere, and they distract from what must be in place since September 11, 2026.

The confusion comes from mixing up three different obligations. The Cyber Resilience Act (Regulation (EU) 2024/2847), or CRA, requires manufacturers of products with digital elements to do three things that everyday language lumps together as “vulnerability management.” You must report attacks to authorities, fix vulnerabilities in your product, and monitor external sources for new vulnerabilities. Each obligation has a different trigger and starts on a different date. Once you separate them, little is left for the reporting obligation that has applied since September 2026: an account, a responsible person, and a practiced procedure.

Contents

1. Three obligations that are often confused
2. Only attacks must be reported
3. Informing your users is part of reporting
4. You do not need a PSIRT for the reporting obligation
5. Monitoring external sources is a separate task
6. A CVE in a component is not yet a finding
7. What follows from the assessment
8. Tools deliver matches, not assessments
9. Vulnerability handling means separating, assessing, and documenting

Three obligations that are often confused

	Trigger	What you must do	Applies from
Reporting to the CSIRT and ENISA	You become aware of an actively exploited vulnerability or a severe incident	Early warning notification within 24 hours, notification within 72 hours, final report afterwards; inform users in parallel	Sep 11, 2026
Handling vulnerabilities in your own product	You learn of a vulnerability in your product, from any source	Check whether your product is affected, assess exploitability, fix based on risk, document, publish	Dec 11, 2027
Monitoring external sources (CVE monitoring)	Continuously, without a specific trigger	Evaluate public databases, your own tests, and external reports, and relate them to your product	Dec 11, 2027

Article 71(2) of the CRA sets these dates. The regulation applies from December 11, 2027, and the reporting obligations in Article 14 have applied since September 11, 2026. The other early date, June 11, 2026, concerns the notification of conformity assessment bodies and does not affect manufacturers. Our overview of the CRA transition periods shows how all the dates fit together.

One detail is overlooked by almost everyone, although it changes the scope of a project. Under Article 69(2), the CRA applies to products you placed on the market before December 11, 2027 only if they undergo a substantial modification from that date. Article 69(3) makes an explicit exception for the reporting obligations. For products already on the market, this means you must report, but vulnerability handling under Annex I, Part II only applies from the next substantial modification. If you are currently planning legacy products into a CRA project, check this.

Only attacks must be reported

Article 14(1) of the CRA ties the reporting obligation to an “actively exploited vulnerability.” Article 3(42) defines it as “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” So you need evidence that someone actually attacked. The fact that someone could attack is not enough. The second trigger is a severe incident having an impact on the security of the product (Article 14(3), with the thresholds in Article 14(5)).

In practice, there are two cases. In the first, someone attacked your product at a customer site and actually exploited a weakness in it, and you have solid indications of this. In the second, someone attacked your own development, production, or maintenance. Recital 68 of the CRA describes this as an incident that affects these processes in such a way that it could result in an increased cybersecurity risk for users. It gives an example every manufacturer understands at once: an attacker has introduced malicious code into the release channel you use to distribute security updates.

You do not report anything else. If a new CVE appears in a library you use, you work through it, as long as nobody has evidence of an ongoing attack. The same applies to a finding from your own penetration test, or to a security researcher's tip about a flaw that nobody has attacked yet. For this group, Recital 68 even says explicitly that vulnerabilities discovered with no malicious intent in good faith testing, investigation, correction, or disclosure “should not be subject to mandatory notification.”

The reverse also holds. If the actively exploited vulnerability comes from a third-party component, it still sits in your product. You report the product.

Informing your users is part of reporting

What manufacturers overlook most often is in Article 14(8). As soon as you know about the attack, you must inform the affected users and, where appropriate, all users. If users can take measures themselves to reduce the impact, you must tell them that as well. If you do not inform them in a timely manner, the CSIRTs designated as coordinators may inform your users in your place. Besides the line to the authorities, you therefore need a distribution list for your customers and a prepared text that you do not have to write during an incident.

You do not need a PSIRT for the reporting obligation

This is the misconception that costs the most time. What matters is that you know about the attack. Article 14 says nothing about how you learned of it.

The European Commission's guidance on the CRA describes when a manufacturer counts as aware. It only interprets the regulation and is not legally binding, but it shows how the Commission reads it. Either the manufacturer discovers something suspicious itself, or a third party alerts it: a private individual, a customer, an authority, or the media. In both cases, the manufacturer looks at the indication immediately. It counts as aware at the moment it knows with reasonable certainty that an attack is taking place or that a severe incident has occurred. From then on, the 24 hours run.

For the reporting obligation, four things must therefore be in place, and no more:

1. You can access the reporting platform. ENISA has operated it since September 11, 2026. Set up access, determine which CSIRT is competent for you, and run through the procedure once.
2. Someone is authorized and able to report. Name a deputy, because the 24 hours also run over a weekend.
3. Someone looks at indications immediately and decides. Define who that is, who decides in case of doubt, and where you record when you became aware.
4. You can reach your users. Prepare a distribution list and a text, so that informing users does not stall while someone is still drafting.

This is a manageable organizational task. You do not need a fully established product security incident response team (PSIRT) for it. Setting one up still makes sense, but it pays off for the obligations that apply from December 2027, not for the reporting obligation that already applies. If you reverse the order, you spend more than a year building a structure and, when an incident occurs, still have no access to the platform. The FIRST PSIRT Services Framework describes how such a team can be organized.

Monitoring external sources is a separate task

From December 11, 2027, the obligation that creates the real work is added. Article 13(8) requires you to ensure that vulnerabilities of your product, including its components, are handled effectively when you place it on the market and for the support period. For this, you need policies and procedures for vulnerabilities reported from internal or external sources. That gives you three channels through which information comes in:

• Public vulnerability databases. According to section 9.2.2 of the Commission's guidance (paragraph 233), a vulnerability counts as known as soon as it is listed in relevant publicly accessible databases, such as the European vulnerability database. Recital 34 of the CRA already names checking against such databases as one possible due diligence measure when you select third-party components.
• Your own tests. Annex I, Part II, point 3 requires you to apply effective and regular tests and reviews of the security of the product. According to section 9.2.3 of the guidance (paragraph 238), “regular” does not mean repeating the same test campaign mechanically. It means checking continuously whether new threats or findings change the tests, and then testing accordingly.
• Reports from outside. Annex I, Part II, point 5 requires a policy on coordinated vulnerability disclosure. Point 6 requires measures that facilitate the sharing of information about vulnerabilities, including a contact address. ISO/IEC 29147 describes what this looks like toward the outside, and ISO/IEC 30111 how you handle reports internally.

Without a software bill of materials (SBOM) under Annex I, Part II, point 1, you cannot relate any of these channels to your product. The CRA requires the SBOM to cover at least the top-level dependencies, which is rarely enough for a reliable match. The SBOM tells you whether a report affects your product. It does not tell you whether the report matters.

A CVE in a component is not yet a finding

The second misconception is the more expensive one. It says that whatever is in the database must go.

The CRA does not require this. Annex I, Part I, point 2(a) requires that your product is made available on the market “without known exploitable vulnerabilities.” This applies where applicable and on the basis of the cybersecurity risk assessment under Article 13(2). Under Article 3(41), a vulnerability is exploitable if it “has the potential to be effectively used by an adversary under practical operational conditions.” Not every vulnerability can be exploited under practical operational conditions; some can only be exploited in a lab or in a simulation. The fact that someone has reported or found a vulnerability does not in itself mean that it can be exploited in practice, or that it affects your product at all. You must investigate that.

Here is a typical example from machine building. An industrial PC in a machine runs a BusyBox version with a registered vulnerability, and the scanner reports a match. Whether this becomes a finding depends on one question: in real operation, can anyone or anything reach the vulnerable function? If no regular user can call it, and no script calls it in a way that triggers the weakness, it has no effect in this product. It stays in the list and in the assessment, and you do not patch it.

This is not a gray area you construct for yourself. When you place a product on the market, the obligation is explicitly risk-based. You decide on the basis of the risk assessment whether you can place the product on the market securely, guided by severity, exploitability, and potential impact. The same applies to products in the field under Annex I, Part II, point 2: you must address and remediate vulnerabilities without delay “in relation to the risks.” The reference to risk is in the legal text itself.

What follows from the assessment

Every report you receive ends in one of four outcomes.

Result of the check	What you do
Component not used, or version not affected	Record in a traceable way that you checked, nothing else
Used, but not exploitable under practical operational conditions	Document the assessment with a rationale, do not patch, report the vulnerability to the manufacturer or maintainer of the component
Used and exploitable	Fix based on risk, provide an update, then publish what you fixed, and also inform the component maintainer
Used and actively exploited	In addition, report to the CSIRT and ENISA and inform users

Article 13(6) of the CRA requires you to inform the component maintainer, and this applies even if the vulnerability cannot be exploited in your product. For open-source components, the report goes to the project, not to an authority.

Under Article 13(7), you must also systematically document relevant cybersecurity aspects of your product, in proportion to the nature of the product and its risks. This includes the vulnerabilities you become aware of. We read this as including the “no.” If you cannot show in an audit why a known vulnerability had no consequences, you are in a weaker position than someone who patched it.

Tools deliver matches, not assessments

This also settles the tool question that usually comes first in projects. Software composition analysis scanners, SBOM platforms, and matching services answer exactly one question: is this component, in this version, in your product? They do this well, and with a large product range you cannot manage without them.

That is as far as they go. Whether the affected function is reachable in your product, whether an attacker can get to it under practical operational conditions, and what risk follows: no tool that does not know your product can tell you. If you buy a tool before you know how you assess, you get a long list of open items and no procedure for working through them. First define how you assess and document. Then automate what can be automated.

Vulnerability handling means separating, assessing, and documenting

For the reporting obligation that has applied since September 11, 2026, you need little: access to the reporting platform, someone authorized to report and a deputy, a quick first look at every indication, and a line to your users. Where an indication comes from does not matter for this.

The real work comes on December 11, 2027. By then, your sources must be monitored, you must be able to assess, and the evidence must be in place. For products you placed on the market before that date, this obligation only applies from the next substantial modification.

Report what was attacked. Fix what is actually exploitable in your product. Assess and document everything else.