CRA Reporting Is Live: What Manufacturers Need Ready for the 24-Hour Clock
Since 11 September 2026, the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents within 24 hours. Here is what applies and what to prepare.
On 11 September 2026 the first binding part of the EU Cyber Resilience Act (CRA) took effect. Manufacturers of products with digital elements must now report two kinds of events to EU authorities on fixed deadlines: actively exploited vulnerabilities in their products, and severe incidents that affect product security. The earliest deadline is 24 hours.
Most of the CRA, including the essential cybersecurity requirements, applies from December 2027. Because of that, many teams still treat the regulation as a future project. Reporting is the exception. It already applies, including to products that were on the market before the CRA. This guide covers what the obligation asks for and what a software or device maker should have in place now. It also covers the questions buyers can ask their suppliers.
What must be reported, and when
According to the European Commission's CRA reporting page, Article 14 sets a three-stage timeline:
- Early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
- A notification within 72 hours with available information on the affected product, the nature and impact of the issue, and any corrective or mitigating measures.
- A final report. For a vulnerability, this is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month of the 72-hour notification.
Manufacturers must also inform impacted users without undue delay and, where appropriate, all users. That information includes measures users can take to reduce the risk, as summarised by the National Law Review.
The two triggers are defined narrowly. ENISA's FAQ describes an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without authorisation. A theoretical flaw found by your own testing is not, by itself, reportable under Article 14. A severe incident is one that negatively affects the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions.
Legacy products are in scope
The obligation is not limited to new releases. ENISA's FAQ states that reporting applies to all products with digital elements from 11 September 2026, including those placed on the market earlier. An analysis by Hogan Lovells Cadwalader adds that reporting continues to apply after a product's support period has ended.
In practice, this means old firmware lines, discontinued appliances and unmaintained desktop clients can all generate a reporting duty. If nobody in your organisation owns those products today, that is the first gap to close.
One platform, one report
Reports go through ENISA's CRA Single Reporting Platform (SRP), which went live on 11 September 2026. A manufacturer submits once. The CSIRT designated as coordinator in its Member State of main establishment receives the notification and shares it with CSIRTs in other countries where the product is available. ENISA receives it at the same time.
Access is tied to named people. ENISA's FAQ says assigned representatives need an EU Login account with multi-factor authentication enabled. A primary representative registers the manufacturer and can invite secondary representatives. Registration is something to finish before an incident, not during one.
A readiness checklist
Hogan Lovells Cadwalader recommends confirming scope, defining reportability thresholds, preparing SRP access and testing the procedure. The steps below turn that into work a team can start this week:
- Inventory in-scope products. List every product with digital elements you place on the EU market, including legacy and end-of-support versions. Name an owner for each.
- Register on the SRP. Choose a primary representative and at least one deputy. Make sure each has EU Login with MFA and has completed registration.
- Define "aware". The same analysis notes that awareness means a reasonable degree of certainty that exploitation or a severe incident has occurred. Write down who makes that call and how the time is recorded, because the 24-hour clock starts there.
- Connect your intake channels. Exploitation evidence often arrives through a vulnerability disclosure inbox, a customer support ticket, a threat intelligence feed or a CSIRT contact. Route all of them to the team that decides on reportability.
- Prepare templates. Draft the early warning, the 72-hour notification, the final report and the user advisory in advance, with fields for product, versions, impact and mitigations.
- Rehearse. Run a tabletop exercise with a realistic scenario, such as exploitation of an old firmware version reported by a customer on a Friday evening. Time each stage against the deadlines.
- Keep records. Retain assessments, timestamps and correspondence. If a decision not to report is ever questioned, the written reasoning is your evidence.
What buyers should ask suppliers
If you buy software or connected devices rather than make them, the CRA still matters to you. It gives you a clear set of due diligence questions:
- Have you registered on the SRP, and who are your assigned representatives?
- How do you decide that a vulnerability is actively exploited, and how quickly can you make that call?
- How will you notify us as an impacted user, and through which channel?
- Which of the products we use are past their support period, and how do you handle reporting for them?
- Can you show evidence of a rehearsed procedure, not only a written policy?
Supplier answers to these questions are a useful signal of overall security maturity. A vendor that can state its reporting path clearly usually has a working vulnerability handling process behind it.
Conclusion
The CRA's reporting obligation is short, specific and already in force. It does not need a large programme to meet. It needs a product inventory, registered people, a clear definition of when the clock starts, and a rehearsed path from first signal to first report. Teams that put these in place now will also be better prepared for the wider requirements that apply from December 2027.
For buyers comparing vendors, transparency is part of the evidence. Oten publishes its security controls, compliance progress and subprocessors in the Oten Trust Center, and that is the kind of material worth requesting from any supplier.