Reporting, monitoring, remediating: the CRA requires three distinct things. Only actively exploited vulnerabilities must be reported, and not every CVE has to be patched.
This happens because three things are being mixed up. The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to do three different things that are commonly grouped under “vulnerability management”: report attacks to authorities, remediate vulnerabilities in your product, and monitor external sources for new vulnerabilities. Each of these three duties is triggered by something different and starts at a different time. Once you separate them, little remains for September 2026: an account, a responsible person, and a rehearsed process.
| What triggers it | What to do | Effective from | |
|---|---|---|---|
| Report to CSIRT and ENISA | You learn of an actively exploited vulnerability or a serious security incident | provide an early warning within 24 hours, report within 72 hours, submit a final report later, and inform users in parallel | 11 September 2026 |
| Handle vulnerabilities in your own product | You learn of a vulnerability in your product, regardless of its source | check whether your product is affected, assess exploitability, remediate based on risk, document, publish | 11 December 2027 |
| Monitor external sources (CVE monitoring) | continuously, without a specific trigger | evaluate public databases, your own tests and external reports and relate them to your product | 11 December 2027 |
Article 71(2) sets the dates. The Regulation applies from 11 December 2027; the reporting obligations in Article 14 apply already from 11 September 2026. The other early date, 11 June 2026, concerns notifications by conformity assessment bodies and does not affect manufacturers. How the dates distribute overall is shown in our overview on CRA transition periods.
One detail that almost everyone overlooks reshapes projects. According to Article 69(2) the Regulation only applies to products you placed on the market before 11 December 2027 if you substantially modify them afterwards. Article 69(3) expressly exempts the reporting obligations from that rule. For your installed base this means: reporting yes, treating vulnerabilities according to Annex I Part II only after the next substantial change. Manufacturers planning to fold legacy products into a CRA implementation project should check this.
Only what is being attacked must be reported
Article 14(1) ties the reporting duty to an “actively exploited vulnerability”. Article 3(42) defines that as a vulnerability for which reliable evidence exists that a malicious actor has exploited it in a system without the system owner’s consent. You therefore need proof that someone was actually attacked. The possibility that someone could attack is not enough. The second trigger is a serious security incident that affects the product’s security (Article 14(3), thresholds in paragraph 5).
In practice there are two cases. Either someone attacked your product at a customer and truly exploited a weakness in it, and you have solid indications of that. Or someone attacked your own development, manufacturing or maintenance. Recital 68 describes this as an incident that impairs those processes so that an increased cybersecurity risk for users could result, and gives an example every manufacturer immediately understands: an attacker injected malicious code into the release channel you use to distribute security updates.
Everything else is not reportable. A new CVE in a library you use is something you work through as long as no one has evidence of an ongoing exploitation. The same applies to a finding from your own penetration test or a security researcher’s notification of a flaw that has not yet been exploited. Recital 68 even explicitly says that vulnerabilities found without malicious intent during in‑good‑faith testing, research, fixes or disclosures should not be subject to reporting for that group.
Conversely: if the actively exploited vulnerability originates in a third‑party component, it still resides in your product. You report the product.
Informing your users is part of the report
What manufacturers most often overlook is in Article 14(8). As soon as you know about the attack, you must notify your affected customers, and depending on the situation, all customers. And if those customers can take actions to reduce the impact, tell them what those actions are. If you wait too long, the CSIRTs designated as coordinators will inform your users on your behalf. So besides the channel to the authority you need a distribution list for your customers and a template text so you do not have to draft the message in the heat of the moment.
You do not need a PSIRT for 11 September 2026
This is where the main misconception eats most time. What matters is that you know about the attack. How you learned about it is nowhere specified in Article 14.
The EU Commission’s CRA guidance describes when a manufacturer is considered informed. It is only an interpretation and not legally binding, but it shows how the Commission reads the Regulation. Either the manufacturer discovers something suspicious itself, or a third party points it out: a private person, a customer, an authority, a media outlet. In both cases the manufacturer reviews the notice immediately, and it is considered informed at the moment it can, with sufficient certainty, determine that someone is attacking or that a serious incident exists. From that moment the 24‑hour clock starts.
For September 2026 you therefore need four things, and no more:
- Someone must have an account on the reporting platform. ENISA is currently building it; it is scheduled to be operational by 11 September 2026. Set up access, determine which CSIRT is responsible for you, and run the process once.
- Someone must be authorized and able to report. Include a deputy, because the 24 hours also run over weekends.
- Someone must immediately review incoming indications and decide. Who that is, who decides in borderline cases, and where it is recorded that you were informed.
- You must be able to reach your users. A distribution list and a template text so that informing does not fail due to wording.
This is a manageable organizational task. You do not need a fully established Product Security Incident Response Team for this. It is sensible nonetheless, but it counts toward the obligations from December 2027, not the imminent date. If you reverse the order, you might spend eighteen months building a structure and still not have platform access by the deadline. What such a team can look like is described in the FIRST PSIRT Services Framework.
Monitoring external sources is the other project
From 11 December 2027 the obligation that really creates work comes into force. Article 13(8) requires that you effectively address vulnerabilities in your product including its components when you place it on the market and during the expected product lifetime and support period. For this you need strategies and procedures for vulnerabilities reported from internal or external sources. Three channels therefore bring things in:
- Public vulnerability databases. A vulnerability is considered known as soon as it appears in relevant publicly accessible databases, for example in the European vulnerability database, the guidance says. Even when selecting third‑party components recital 34 names checking such databases as one possible due‑diligence measure.
- Your own tests. Annex I Part II(3) requires that you test the product’s security regularly and effectively. “Regularly” does not mean repeating the same test campaign mechanically, the guidance explains, but continuously checking whether new threats or findings change the tests and then testing accordingly.
- External reports. Annex I Part II(5) requires a strategy for coordinated vulnerability disclosure; number 6 requires measures to facilitate exchange about them, including a contact address. How disclosure looks externally is described in ISO/IEC 29147; how you handle it internally, ISO/IEC 30111.
Without a Software Bill of Materials (SBOM) pursuant to Annex I Part II(1) you cannot relate any of these channels to your product. At minimum the top‑level dependencies are required; for a reliable match that is rarely enough. The SBOM tells you whether a report concerns your product. It does not tell you what it means.
A CVE in a component is not yet a finding
The second misconception is the more costly: what is in the database must be eliminated.
The CRA does not require that. Annex I Part I(2)(a) demands that you provide your product “without known exploitable vulnerabilities” insofar as that applies to your product, and on the basis of the risk assessment under Article 13(2). A vulnerability is “exploitable” per Article 3(41) when an unauthorized third party can effectively make use of it “under practical operating conditions”. Not every vulnerability can be exploited under practical operating conditions; some only in the lab or in simulations. And the mere fact that someone reported or found a vulnerability does not by itself mean it is exploitable in practice or that it even affects your product. You must investigate that.
An example typical in mechanical engineering: an industrial PC in a machine runs a BusyBox version with a recorded vulnerability; the scanner reports a hit. Whether this becomes a finding for that machine depends on one question: can anyone or anything in real operation reach the vulnerable function? If no normal user can call it and no script calls it in a way that triggers the weakness, then in that product the vulnerability is inert. It remains listed, it appears in the assessment, and you do not patch it.
This is not a gray area you invent to suit yourself. The requirement at placing on the market is explicitly risk‑based: you decide on the basis of the risk assessment whether you can safely place the product on the market, and you consider severity, exploitability and possible impact. The same applies to products in the field via Annex I Part II(2): you treat and remediate vulnerabilities there “with regard to the risks” without delay. The risk linkage is in the normative text itself.
What follows from the assessment
Every report you receive ends up in one of four outcomes.
| What the review finds | What you do |
|---|---|
| Component not used or version not affected | record the check in an auditable way and do nothing else |
| used, but not exploitable under practical operating conditions | document the assessment and reasoning, do not patch, report the vulnerability to the component’s maintainer or vendor |
| used and exploitable | remediate based on risk, provide an update, then publish what you fixed, and inform the component maintainer |
| used and actively exploited | additionally report to CSIRT and ENISA and inform users |
Decision path from receipt of a vulnerability report to the result: check whether the product is affected, then assess exploitability under practical operating conditions, then check for active exploitation. Only the last branch leads to reporting to CSIRT and ENISA and to user notification. A separate entry sends serious security incidents straight into the reporting branch.
That you inform the component maintainer is required by Article 13(6), and it applies even when the vulnerability is not exploitable in your product. For open source components the report goes to the project, not to an authority.
Article 13(7) also requires that you systematically and risk‑appropriately document all relevant cybersecurity aspects of your product, including the vulnerabilities you learn about. We read this to mean that a documented negative finding (the “no”) also belongs. In an audit, someone who cannot show why a known vulnerability had no consequences is worse off than someone who patched it.
Where is your product with CRA?
The CRA readiness check shows in a few minutes where you stand between reporting obligations and full CRA conformity — and what matters next for you.
Tools deliver hits, not assessments
This also answers the tooling question that usually comes first in projects. Software composition scanners, SBOM platforms and matching services answer exactly one question: is this component in this version present in your product? They do that well, and with significant product variety you cannot manage without them.
They go no further. Whether the affected function is reachable in your product, whether an attacker can access it under practical operating conditions, and what risk results from that — no tool that does not know your product can answer those questions. Buying a tool before you know how you will assess will get you a long list of open items and no procedure to clear them. First define how you will assess and document. Then automate what can be automated.
Vulnerability management means separate, assess, document
By 11 September 2026 you need little: an account on the reporting platform, someone authorised to report with deputies, a quick first look at every notice, and a channel to your users. It does not matter where a notice comes from for that.
The work starts on 11 December 2027. Then the sources must run, you must be able to assess, and the evidence must be in place. For products you placed on the market earlier this obligation only takes effect with the next substantial change.
Report what was attacked. Remediate what is truly exploitable in your product. Everything else you assess and document.
Vulnerability management set up for practice
The reporting obligation for 11 September 2026 can be met with little effort. The real work begins on 11 December 2027, when assessment and documentation become ongoing obligations. We help you classify what of this is really necessary for your products.
