Starting September 11, 2026, the first major reporting obligations of the Cyber Resilience Act begin. From that date, any company that brings a device to market in the EU will have to comply with new reporting standards for serious cybersecurity incidents. Here’s what is known today, and what you will need to be prepared for.
What must be reported?
We know that the CRA’s full set of provisions don’t come into effect until December 2027, so why are these additional requirements taking effect earlier? It all comes down to the seriousness and impact of the issue. These reporting requirements only apply to security incidents that actually occur. If it’s just a theoretical vulnerability and you have no evidence of exploitation, the reporting requirement is generally not triggered. So, what does trigger it?
- any vulnerability in the software that is known to be exploited
- severe incidents that impact the security of the software
That means that you might have a reporting requirement even when there isn’t a software vulnerability to patch. For example, if your device communicates with a cloud back-end, and the cloud servers were compromised, that would qualify as an incident. A “known-exploited” vulnerability is a bit more of a moving target: it’s not yet clear whether it’s necessary for a device manufacture to have evidence that their devices are actually being exploited or not. So, if there is a well-known vulnerability discovered, like the xz backdoor, and the manufacturer knows that it could be exploited on their device, is there automatically a reporting obligation? Or is there only an obligation once the manufacturer has concrete evidence of exploitation against their devices? We will have to wait for specific guidance from the regulating agencies. What is clear, at least, is that any incident that actually happens must be reported.
Who must it be reported to?
These issues must be reported to the single reporting platform that ENISA has been charged with creating in Article 16. This single reporting platform, however, does not exist yet. Once it does, we can presume that it will promulgate its own guidance for how to report.
Ultimately, these reports will be handled by the Computer Security Incident Response Team (CSIRT) in each EU country; one of the main reasons the CRA mandates the creation of this single platform is that it would be too burdensome to expect companies to have to report incidents individually to 30 or more different CSIRTs in different countries.
When must I report?
The CRA does establish specific deadlines for reporting of severe incidents and known-exploited vulnerabilities. Bear in mind that all of these deadlines are for confidential reports to ENISA; it does not mean that the reports will be made public.
- A first notification should be published as soon as possible, and before 24h of the entity becoming aware. For an incident, it should include whether it is suspected to have been caused by malicious actions. For a vulnerability, it should include the member states where the product is known to be used.
- As soon as possible and before 72h, an initial assessment and mitigations should be provided.
- As soon as possible and within one month after the initial assessment above, the affected manufacturer should publish a final report detailing the incident or vulnerability, its impact, the root cause and the mitigations. For a vulnerability, it should also include information about any malicious actor known to have exploited or be exploiting it.
Especially in the early stages, these deadlines are quite strict. It’s important that incident response teams, developers, and/or cybersecurity staff are aware of these responsibilities and what the appropriate channels are. It’s also important to have a responsible disclosure policy written before incidents happen, so that you have a plan for the eventual public disclosure.
What about mitigation and response?
This reporting obligation technically doesn’t include an obligation to provide security patches, or mitigations. (You might have those responsibilities under other laws and regulations, like the GDPR.) The obligation of mitigation and security patching only comes into force in December 2027. However, it’s still a good practice to provide workarounds and/or patches. The final report will need to include mitigations documentation regardless, and customers aren’t likely to respond well to a report that simply says “there is no mitigation available”. Additionally, since it will be a requirement to issue patches once the rest of the CRA’s provisions come into force, it’s advisable to already have a plan for how to address issues like this. A robust software update system, including automatic over-the-air software updates is one very important piece of the plan.
To know more about how the CRA impacts your product development reach out to us.