Cyber Resilience Act Reporting Requirements Are Live: What Changes for Software Already on the Market

The first obligations of the EU Cyber Resilience Act (EU CRA) had already taken effect on September 11, 2026. Manufacturers of products with digital elements sold in the EU are now obliged to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. An early warning is due within 24 hours of the manufacturer becoming aware that a vulnerability contained in its product is being actively exploited, whether attackers hit this product or another one built on the same vulnerable component. 

Most CRA requirements apply from December 11, 2027, when the products will be obliged to carry the CE marking to be sold in the EU, backed by a conformity assessment and technical documentation that includes an SBOM. 

But the duty to report exploited vulnerabilities and severe incidents still applies since September 11, 2026, also covering products placed on the EU market even before the CRA was adopted.

 

What does the CRA require manufacturers to report?

An Article 14 of Regulation (EU) 2024/2847 covers 2 types of events: actively exploited vulnerabilities and severe incidents. Here’s the difference between these two definitions.

• An actively exploited vulnerability only counts when there is reliable piece of evidence that a malicious actor has unauthorizedly used the flaw.
  
  [IMPORTANT] A vulnerability with no evidence of exploitation doesn’t require a report, even if it counts as a critical one. But the manufacturer may still notify ENISA about it voluntarily.

• A severe incident, on the other hand, covers events that damage (or can damage) product's ability to protect sensitive data or functions and events that lead (or can lead) to malicious code running. 

The CRA defines exploitation as a USE of the flaw "in a system without permission of the system owner”. For example, if attackers exploit a library, e.g. Log4j, in another vendor's product, this counts as an active exploitation for EVERY product that ships with the same library version. 

Each affected manufacturer must notify ENISA about the exploit, according to question 5.4 of the European Commission's CRA FAQ.

[EXCEPTION] But a manufacturer whose product ships the code that cannot be attacked is exempt from reporting. But of course, using this exception also requires proof that the product never calls the vulnerable code.

Under Article 13 (6), a manufacturer that found any kind of vulnerability in his integrated component, must report the flaw to the owner of the vulnerable project and share a fix, if it has one from December 11, 2027.

 

24-hour CRA reporting timeline explained

By definition, the 24 hours start counting from the moment the manufacturer becomes aware of the exploitation’s existence. Weekends and holidays are no exception for a 24-hour reporting rule.

The European Commission's CRA FAQ lists:

• customer and partner notifications, 

• threat intelligence from researchers and security vendors, 

• government agencies, 

• ethical hackers, 

• internal monitoring and telemetry as the manufacturer’s sources to learn about the exploit. 

[IMPORTANT] The CRA doesn't oblige manufacturers to monitor these channels. But once the information from any of them reaches the manufacturer, the 24-hour timer starts.

 

Here's what each of required reports must contain, and when you need to file them:

 

A single submission to the platform reaches both ENISA and the national CSIRT (cybersecurity incident response team) of the EU country where the manufacturer's main office is registered. 

[NOTE] Manufacturers with no office in the EU report to the CSIRT of the EU country where their authorized representative, importer or distributor operates, or where most of their EU users are. Under Article 14 (8), the manufacturer must also inform users that were affected about the vulnerability and the measures they can already take to protect themselves.

 

Does the rule cover the products shipped years ago?

Under Article 69(3), products that were present on the market before December 11, 2027 are exempt from the CRA's essential requirements (like secure design, CE marking, SBOM). 

[NOTE] If the manufacturer substantially modifies the product after December 11, 2027, for example by adding functions that significantly change its original purpose or risk profile, then the exemption terminates. Also, security patches alone do not count as a “substantial modification”. But the REPORTING DUTY under Article 14 has no exemption for older products: it applies to ALL products with digital elements on the EU market, no matter when they were placed there.

For example, a banking terminal shipped in 2019, or a telecom billing module from 2016, or even a medical desktop application that is still sold under a maintenance contract — they are all in the reporting scope since September 11, 2026. And because their dependency trees were assembled years and even decades ago, they most likely aren’t available in a machine-readable form. So, when one of their libraries gets exploited, the team will have to manually reconstruct that from scratch, while the 24-hour deadline will be running ahead of their capabilities.

[IMPORTANT] Formally, an older product doesn’t need an SBOM file. But in practice, without a list of all its components, the manufacturer won’t be able to tell within a 24-hour reporting deadline whether an exploited vulnerability affects their product or not.

 

Why do the first 24 hours matter?

Filing the 24-hour warning itself doesn’t take long. But it takes much more time to answer if the exploited flaw exists in any of the manufacturer’s products, and if it does — in which versions of it?

Log4Shell has shown us how long it can take to get this answer. The Log4j library sat as a transitive dependency (a library pulled in by another library) inside thousands of Java applications, and many vendors spent weeks establishing where it was buried. And under the CRA, the same investigation should now fit into a 24-hour deadline.

Here are 3 reasons that could affect this investigation and make it longer:

• No component inventory per release. Without an SBOM for each shipped version, the team is forced to manually reconstruct the dependency tree.

• Old releases fall out of scanning. Scanners launched in the CI/CD pipeline usually check the current version of the product with every new build. A CVE published AFTER the release is usually not checked against the older versions that customers may still run, unless someone goes and specifically scans them.

• Unknown reachability. A library usually contains hundreds of functions. And an exploit may target just one of them. If nobody has traced whether the product calls that function, the team cannot prove the exception and is doomed to spend time triaging on code that may never run in the product. 

[IMPORTANT] A missed reporting deadline falls into the CRA's top penalty tier: fines may go up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

 

Cyber Resilience Act timeline until December 2027

 

How to get ready for Cyber Resilience Act compliance before the next exploit

1. Build an SBOM for every release still on the market. Start with the latest releases and include older branches that are still under your maintenance.

DerScanner SBOM produces a CycloneDX SBOM directly from source code for Java, Kotlin, Scala, JavaScript, TypeScript, Python, C#, Go, PHP, Ruby, Rust, Swift, C/C++ and Erlang. For Object Pascal and Delphi projects, we’ve specifically developed Delphi SCA. 

2. Answer the reachability question. DerScanner hybrid SAST and SCA engine helps to trace vulnerable functions in a dependency and answer if they are actually called from the application.
This trace is the proof of a "not exploitable in this product" take. The reachability analysis guide explains the method.

3. Set up access to ENISA now. Creating an account in advance and deciding who’s in charge of filing the reports may save you precious time in a 24-hour reporting gap.

 

[IMPORTANT] The 72-hour notification and the final report requires you to demonstrate which versions were affected and what fixes were applied. Use scan history to show which release used the vulnerable component and when it was fixed.

For regulated industries and products generating an SBOM comes with additional constraints. We cover them in the guide, How to Generate an SBOM in an Air-Gapped Environment.

 

If you’re looking for ways to test SBOM generation or reachability analysis on your own codebase, book a demo or request a PoC. We’re always up for a chat.