The Cyber Resilience Act’s reporting obligations have applied since 11 September 2026. If you sell software or connected devices in the EU, you must send an early warning within 24 hours of learning that a vulnerability in your product is being actively exploited, followed by a fuller notification within 72 hours. Reports go through ENISA’s Single Reporting Platform, and the obligation covers products that have been on the market for years.
Everything else in the CRA (secure-by-design requirements, update obligations, conformity assessment) only applies from December 2027. Reporting is the part that is already live, and it’s exactly the part small companies tend to park under “we’ll deal with it when the CRA arrives”.
This is an orientation, not legal advice.
Who has to report under the CRA?
The CRA covers “products with digital elements”: software and hardware with a direct or indirect data connection to a device or network (Art. 2 and 3 CRA). That is deliberately broad. It includes the app in the store, desktop software that phones home to a licence server, and a measuring device with firmware and a cloud backend. What matters is that you supply the product in the course of a commercial activity, whether you charge for it or not.
Free and open-source software supplied outside any commercial activity is out of scope. Open-source software stewards, meaning organisations that systematically support free software, get a lighter regime, and their reporting duties only start on 11 December 2027 according to the European Commission.
One detail matters for anyone with an existing product line. Most CRA requirements only apply to products placed on the market (or substantially modified) from December 2027. Reporting is the explicit exception: under Art. 69(3), it applies to every in-scope product, old ones included.
A quick distinction, because the two get mixed up constantly. NIS2 targets operators, companies in certain sectors that must secure their own systems and report incidents (here’s how to check whether you’re in). The CRA targets manufacturers, because of the products they sell to others. A company can be both.
What are the reporting deadlines?
In both cases the clock starts when the manufacturer becomes aware (Art. 14 CRA):
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | within 24 hours of awareness | within 24 hours of awareness |
| Notification | within 72 hours of awareness | within 72 hours of awareness |
| Final report | no later than 14 days after a fix or mitigation is available | within one month of the 72-hour notification |
“Actively exploited” means there is reliable evidence that a malicious actor has actually exploited the flaw without permission. A theoretical weakness found in your own code review doesn’t trigger the duty. An incident is “severe” if it affects the product’s ability to protect sensitive data or functions, or if it has led to malicious code getting into the product or into your users’ systems. You also have to inform affected users, with mitigation guidance where needed (Art. 14(8)).
Where do reports go?
Reports go through ENISA’s Single Reporting Platform (SRP), which launched on schedule on 11 September as an “initial operating capability”. A single submission reaches ENISA and the coordinating CSIRT of the member state where you have your main establishment. For German manufacturers that is CERT-Bund at the BSI, per the BSI. You don’t need to register in advance; the BSI says registration and submission take minutes when needed.
That sounds reassuring. I still wouldn’t try it for the first time during an actual incident.
Why the 24 hours are the hard part
Technically, an early warning is trivial: a form, a few fields, submit. The hard part is that the 24 hours run from awareness. In a company with eight developers, awareness often means one person reading an email to an old support address on a Friday afternoon.
So the reporting obligation is mostly an organisational problem. What a small software maker needs now is modest, but it has to actually exist:
- A way to hear about vulnerabilities. A reachable security contact (ideally published via
security.txt) and monitoring of your dependencies. If you don’t know which libraries ship in which release, you won’t notice an exploited flaw in one of them. An SBOM per release fixes exactly that. - An internal escalation path with a deputy. Who decides whether something counts as “actively exploited”? Who takes over when that person is on holiday? Settle this beforehand, not at 11 pm.
- A pre-drafted early warning. A template with product name, affected versions, countries where it’s sold and a contact. The early warning is meant to be fast, not complete.
- Someone who has seen the platform. ENISA publishes manuals and tutorial videos. Half an hour with them before anything is on fire is enough.
If an agency builds your app, raise this with them. You are usually the manufacturer under the CRA, so the reporting duty stays with you. That makes it all the more important that maintenance, dependency updates and a contact path are in the contract, and not just in the quote for version one.
What are the fines?
Breaches of Art. 14 fall into the CRA’s top fine tier: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64 CRA). Art. 64(10) provides some relief for micro and small enterprises that miss the 24-hour early-warning deadline; read the exact wording before you rely on it. The 72-hour notification and the final report remain mandatory either way.
My point is a different one, though. Fines aren’t the reason to set this up properly. An exploited vulnerability in your product is an emergency regardless, and the reporting obligation just forces you to rehearse that emergency once in advance.
Building software or apps and want the escalation path, SBOM and update process set up properly? Get in touch — it’s part of how I build and maintain software.