The Cyber Resilience Act does not require manufacturers to report every vulnerability or remediate every CVE immediately. Its early reporting duties begin on 11 September 2026, while broader vulnerability-handling duties generally apply from 11 December 2027.
Separate reporting from vulnerability handling
Two common assumptions about the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, are misleading: that every vulnerability must be reported from September 2026, and that every CVE affecting a component must be fixed. The Regulation does not say either.
It distinguishes between immediate reporting of certain events and the wider, ongoing work of handling vulnerabilities in products with digital elements.
| Duty | Trigger | What is required | Application date |
|---|---|---|---|
| Report to the designated CSIRT coordinator and ENISA | The manufacturer becomes aware of an actively exploited vulnerability in its product, or of a severe incident affecting product security | Submit an early warning within 24 hours, notification within 72 hours and the applicable final report; inform impacted users and, where appropriate, all users | 11 September 2026 |
| Handle vulnerabilities in the product | A vulnerability in the product or its components becomes known | Assess applicability, practical exploitability and risk; address and remediate vulnerabilities without delay in relation to risk; document the work | Generally 11 December 2027 |
| Monitor and receive vulnerability information | Ongoing | Maintain processes for internal and external vulnerability sources, testing, coordinated disclosure and a reporting contact | Generally 11 December 2027 |
Article 71(2) makes the timing clear: the Regulation applies from 11 December 2027, but Article 14 reporting applies from 11 September 2026. The earlier date does not bring every CRA vulnerability-management duty forward.
The transitional rules also matter. Article 69 applies Article 14 reporting to in-scope products placed on the market before 11 December 2027. A legacy product should therefore not be treated as outside the reporting regime merely because it predates the general application date. The wider obligations require their own assessment against the Regulation's scope and transitional provisions.
What must be reported
Article 14 creates two main reporting triggers.
First, a manufacturer must report an actively exploited vulnerability contained in its product when it becomes aware of it. This is narrower than a vulnerability that could be exploited. The CRA defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission.
Second, a manufacturer must report a severe incident affecting the security of the product. Under Article 14(5), an incident is severe where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It is also severe where it has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user's network and information systems.
A new database entry, a penetration-test finding or a report from a security researcher is therefore not automatically an Article 14 report. It must still enter the manufacturer's vulnerability-handling process. But, without reliable evidence of malicious exploitation, a finding discovered through good-faith testing, research, remediation or disclosure does not by itself meet the actively exploited vulnerability trigger described in the CRA.
The reporting timetable is staged
The Regulation sets different stages and final-report deadlines for vulnerabilities and incidents.
| Report stage | Deadline |
|---|---|
| Early warning | Within 24 hours of becoming aware |
| Notification | Within 72 hours of becoming aware |
| Final report for an actively exploited vulnerability | No later than 14 days after a corrective or mitigating measure is available |
| Final report for a severe incident | Within one month after the 72-hour notification |
Reports are made simultaneously to the designated CSIRT coordinator and ENISA. The current operational route is ENISA's Single Reporting Platform. ENISA currently advises manufacturers to use EU Login and to arrange access through assigned representatives; those operational details can change, so they should be checked in the current ENISA platform guidance before use.
Informing users is part of readiness
Reporting to authorities is not the only immediate task. Article 14(8) requires the manufacturer to inform impacted users and, where appropriate, all users of the vulnerability or incident. Where necessary, it must also communicate risk-mitigation and corrective measures users can take.
A practical readiness arrangement for September 2026 therefore includes:
- access to the reporting platform and clarity on the relevant CSIRT coordinator;
- a named reporter and a workable out-of-hours deputy arrangement;
- a rapid process for reviewing credible reports and recording when the manufacturer became aware of the issue; and
- a reliable way to contact users, with clear incident communications prepared in advance.
A fully developed product security incident response team may support this work, but Article 14 does not prescribe a particular organisational model. What matters is that the manufacturer can recognise a trigger, act within the deadlines and reach affected users.
A CVE is an input, not the reporting trigger
A CVE identifier helps people identify and catalogue a publicly disclosed vulnerability. It is useful coordination infrastructure, but it is not the CRA's general reporting trigger and is not a general condition of compliance.
The legal trigger is active exploitation in the manufacturer's product, or a severe product-security incident. Current ENISA reporting guidance lists a CVE ID as optional in the 24-hour report template. That does not mean CVE information will never be useful or requested later; it means a CVE identifier is not a substitute for assessing the product-specific facts.
ENISA's roles in the CVE programme and its operation of the EU Vulnerability Database can support discovery and coordination. They do not determine whether a component issue applies to a particular product or whether an Article 14 report is required.
Assess component vulnerabilities in context
The CRA requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials. It also requires them to address and remediate vulnerabilities without delay in relation to the risks posed by the product.
A database match is only the beginning of the analysis. A manufacturer needs to establish whether:
- the affected component and version are present in the product;
- the vulnerability affects the way that component is used in the product;
- an adversary could use it effectively under practical operational conditions; and
- the resulting risk requires remediation, mitigation or another documented response.
The CRA defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions. That calls for a product-specific assessment, not an automatic conclusion from a scanner result.
| Assessment outcome | Appropriate next step |
|---|---|
| The component is absent, or the version is unaffected | Record the assessment and its basis |
| The component is present but the issue is not exploitable under practical operational conditions | Document the reasoning, consider applicable component-notification duties and continue to monitor relevant changes |
| The component issue is applicable and exploitable | Address and remediate it without delay in relation to risk, document the decision and communicate relevant corrective information |
| There is reliable evidence of malicious exploitation in the product | Take the vulnerability-handling steps and make the Article 14 reports; inform users as required |
A non-exploitable finding should not simply disappear from view. Article 13 requires systematic, proportionate documentation of relevant cybersecurity aspects, including known vulnerabilities. A clear record of why a finding does or does not affect the product is often as important as the technical result.
Build the broader process for December 2027
From the general application date, vulnerability handling becomes a broader operational discipline. The CRA requires risk assessment, vulnerability-management processes, regular and effective security testing, coordinated vulnerability disclosure measures and a contact address for reporting vulnerabilities. Manufacturers also need an SBOM that helps them connect external information to their own products.
Useful inputs include public vulnerability databases, component and supplier information, internal testing and reports from external parties. None of these inputs makes the legal decision on its own. The manufacturer must relate them to its product, its deployment conditions and the relevant risks.
Tools for software composition analysis, SBOM management and vulnerability matching can help identify possible exposure at scale. They do not usually establish whether a vulnerable function is reachable, whether exploitation is practical in the product's operating environment, or what risk follows. Define the assessment and documentation process first, then automate the repeatable parts.
Focus on the right obligation at the right time
For 11 September 2026, the immediate priority is a functioning reporting and user-communication process. Manufacturers should be able to recognise actively exploited vulnerabilities and severe incidents, submit staged reports on time and notify users where required.
For 11 December 2027, the focus broadens to continuous vulnerability handling: discovery, assessment, risk-based remediation, documentation, testing, disclosure arrangements and component visibility.
In short, report what meets the Article 14 trigger. Assess each known vulnerability in the context of the product. Remediate vulnerabilities in relation to risk, and keep the evidence that supports the decision. This is general regulatory information, not legal advice.