Imagine a Saturday morning at 7:15 a.m. A trusted Computer Security Incident Response Team (CSIRT) tells you that a software component in your connected industrial gateway is already being exploited by attackers. Under the Cyber Resilience Act (CRA), the deadline for your early warning expires on Sunday at 7:15 a.m., and nobody asks whether Monday is a public holiday.
In short: Since September 11, 2026, manufacturers of products with digital elements have to report actively exploited vulnerabilities and severe security incidents. The early warning is due within 24 hours, the notification within 72 hours, and the final report after that. Reports are submitted through the Single Reporting Platform (SRP) of the EU Agency for Cybersecurity (ENISA). In Germany, CERT-Bund at the Federal Office for Information Security (BSI) is the competent CSIRT.
The form is the smallest part of the task. What matters is whether, within a few hours, you know which products and versions are affected, who may approve the report, and since when you have known about the problem. This article shows what the obligation requires, what a process for the first 24 hours can look like, and what you should prepare now.
Talk to us if you would like to assess your company’s reporting readiness together: To our cybersecurity consulting
The reporting obligations under Article 14 CRA apply roughly 15 months before the remaining manufacturer obligations, which take effect on December 11, 2027. They cover two events: an actively exploited vulnerability for which there is reliable evidence of malicious exploitation, and a severe security incident that affects product security. A proof of concept or a high severity rating alone does not trigger the obligation.
Reporting runs in three stages:
Two points are often overlooked. The obligation also applies to legacy products that were already on the market before December 11, 2027. In addition, under Article 14(8) you have to inform affected users yourself; the report to the authority does not replace this.
The obligation applies directly under the EU regulation. The fact that the German implementing act for the CRA was still going through parliament in early October 2026 does not postpone it. Violations of Article 14 can result in fines of up to 15 million euros or 2.5 percent of worldwide annual turnover.
What matters is the manufacturer's awareness. According to the European Commission’s interpretation, this is the case as soon as a prompt initial assessment yields a reasonable degree of certainty. The assessment must not be delayed in order to postpone the report. The guidance is not legally binding, but it shows how the Commission reads the provision.
A practical rule follows: every case in the vulnerability process needs a documented timestamp for the receipt of the information, its source and the time of classification. As things stand, the SRP does not fully capture this point in time. Its counter for the 72-hour notification currently runs from the submission of the early warning, not from awareness. You are therefore better off calculating the statutory deadline yourself; ENISA has announced a correction.
The exemptions follow the product, not the company. The same company can have one product outside and another inside the scope of the CRA.
Anyone working in several of these worlds should set up a joint triage: a case is assessed technically once and then branches into MDR or IVDR vigilance, UN R155 reporting or CRA notification. You will find more background in our articles on preparing for the EU Cyber Resilience Act and on the Cyber Resilience Act in medical technology.
The following scenario is an elaboration based on the sources cited, not an official template. The times are internal safety margins, not statutory interim deadlines. Starting point: a machine manufacturer supplies a remote maintenance gateway in several firmware lines in 14 EU Member States; it contains an open-source web server library.
An exercise only becomes meaningful once you inject disruptions: the Primary Assigned Representative is on vacation or has lost the device for multi-factor authentication. The supplier does not respond for six hours. No SBOM exists for a legacy product. Afterwards, check how long it took to reach documented awareness, whether the version list was correct, and whether the buffer to the 24-hour limit was larger than six hours.
If you would like to run through such a scenario for your product portfolio, talk to us.
We say it openly: after a good three weeks, there is hardly any robust practical experience. ENISA and the BSI have so far published neither reporting figures nor evaluations, and no supervisory practice on Article 14 is yet discernible. Statements about what authorities “accept in practice” cannot currently be substantiated.
The starting position before launch was mixed. In a Bitkom survey of 1,003 companies, 29 percent said they knew what the CRA means for them. Still open are also the line between a tip-off and “reasonable certainty”, the required depth of evidence for third-party components, and the interplay with NIS2: an entity that falls under NIS2 can trigger two reports with similar deadlines for the same event. The Commission has proposed simplifications, which are not yet applicable law. The platform keeps changing, so check the ENISA FAQ regularly.
The litmus test of Article 14 is whether your company can answer five questions within a few hours of an external tip-off:
That only works if vulnerability management, SBOM, supplier management, regulatory affairs and communications work as one process.
The good news: much of this can be prepared, and an exercise reveals the gaps faster than any document review. If you are looking for a sparring partner, you will find in us experience from developing and securing safety-critical software in regulated industries. Talk to us!
The BSI states that prior registration is not required. Set up the EU Login accounts with multi-factor authentication in advance anyway, so that you do not lose time in an emergency.
Yes. Article 69(3) exempts the reporting obligations from the transitional rule for legacy products. What matters is that the product is within scope and still on the market.
No. Reportable are actively exploited vulnerabilities with reliable evidence that are contained in your product and exploitable there. Also document negative decisions.
Products under the MDR, the IVDR or vehicle type approval are excluded. Software or components sold separately can still be affected.
Products under the MDR, the IVDR or vehicle type approval are excluded. Software or components sold separately can still be affected. There is no exemption for the financial sector and public administration: manufacturers of products for these sectors report under Article 14, mere operators do not.
No. You also have to inform affected users yourself about the vulnerability and countermeasures.
Firstname:
Lastname:
E-Mail Address:
Phone:
Subject:
Your message:
Yes, I consent to my personal data being collected and stored electronically. My data will only be used for the purpose of responding to my inquiry. I have taken note of the privacy policy.