There's a part of the Cyber Resilience Act (CRA) that doesn't wait for 2027. The vulnerability reporting obligations under Article 14 start on 11 September 2026. This means that you have 24 hours for an early warning, 72 hours for a fuller notification, and 14 days for a final report.
However, as is often the case with regulations, it is not as clear as it may seem at first. In this article, I’ll show what that actually looks like in practice, and why it's the first place enforcement is likely to bite.
Reporting obligations are clear and strict
The headline cadence is defined as 24/72/14, but there is a one-month deadline that most people miss. Before we dive deeper, I’d like to highlight that the CRA established two main triggers for the reporting actions: the actively exploited vulnerability and a severe incident.
Now let's imagine that it's 11 September 2026, and Organization X has a successful product that is subject to the EU Cyber Resilience Act.
Tuesday, 09:00 - The trigger
The X security team gets a credible security alert: attackers are gaining access to the administrative product configuration through a firmware authentication vulnerability. The important thing is that there's reliable evidence of real exploitation, not just a theoretical bug. It means that the identified vulnerability is actively exploited - Article 14(1) of CRA.
By Wednesday, 09:00 - the 24-hour early warning
Within 24 hours, the X's responsible person files an early-warning notification through ENISA's Single Reporting Platform (SRP). It's deliberately thin: "We have an actively exploited vulnerability in our product and here are the EU Member States where the product is sold." That's enough to satisfy the deadline - they are not expected to have a root cause or a fix yet.
By Friday, 09:00 - the 72-hour notification
Within 72 hours of awareness, the X submits a fuller notification with the details like: general nature of the vulnerability, exploit approach, an initial assessment of impact, etc. In parallel, Article 14(8) of the CRA requires them to inform affected users, so the organization needs to think in advance about how they would do this.
The fix
Obviously, the X’s engineers need to start thinking about the vulnerability mitigation actions. The point is that the CRA does not set a deadline for developing the fix. However, the absence of a statutory deadline does not mean there is no urgency. The obligation to act 'without undue delay' still applies, affected users must still be informed under Article 14(8), and market surveillance authorities may act if an exploited vulnerability remains unpatched.
Final report - 14 days after fix
The final report should contain a full description of the vulnerability, its severity and impact, what's known about the attacker (if applicable), and details of the patch and how users get it.
The 14-day clock starts when either a full fix or a workaround/mitigation is available — not only when a complete patch ships. So you can't indefinitely delay the final report by saying the permanent fix isn't ready.
Severe incident vs exploited vulnerability
Previously, I described the example of a reported workflow for the exploited vulnerability, but for a severe incident, the final reporting timeline is different. Let’s consider an attacker breaching an organization’s build pipeline and slipping malicious code into the firmware update channel. That's a severe incident affecting the security of the product (Article 14(3)). The 24-hour and 72-hour steps look the same, but the final report is due within one month of the 72-hour notification, not 14 days after a fix.
What actually has to be reported is narrower than you think
This applies only to actively exploited vulnerabilities - not every CVE. Under Article 3(42), an "actively exploited vulnerability" requires reliable evidence that a malicious actor has exploited it without the system owner's permission.
A published proof-of-concept, a researcher demonstrating exploitability, or a disclosed-but-not-exploited CVE does not, by itself, trigger the 24-hour clock. Most CVEs never become reportable. This is worth highlighting because it signals the CRA is targeting real-world attacks, not penalizing responsible disclosure.
What creates the greatest urgency
Legacy products are in scope for reporting even though they're exempt from full compliance. Article 69(2) says products placed on the market before 11 December 2027 only fall under the full CRA if substantially modified after that date, but Article 69(3) overrides this specifically for Article 14. The reporting duty applies to everything already on the market. So a product you shipped in 2020 and never touch again still needs a working 24-hour reporting capability from September 2026. Reporting will be the first place fines actually land and it's the easiest non-compliance to catch.
Third-party and open-source components don't shift the duty away from you. If an actively exploited vulnerability comes from a component you've integrated, you still have to report it. Moreover, the component's maker has the same reporting obligations, if they placed it on the market separately. Specifically for SaaS and software clients, the end-of-life dependencies become a legal liability, because if no one maintains the component anymore, you can't produce the "fix" that the 14-day final report assumes.
All of this creates significant obligations for SBOM and supplier management, but that is a topic for another article. Stay tuned for more insights.
