The Cyber Resilience Act is often associated primarily with the year 2027. This is understandable in principle, since most of the requirements of the EU regulation take effect on December 11, 2027. However, anyone who concludes that there is still enough time until then is overlooking a crucial point: The CRA reporting requirements for certain vulnerabilities and security incidents have been in effect since September 11, 2026. For affected manufacturers, this means they must already be capable of conducting a robust assessment and reporting the necessary information within short timeframes.
This is not just about using a reporting portal. Companies need clear lines of responsibility, effective vulnerability management, and a functioning incident response process. This is because the initial deadline is a maximum of 24 hours from the time the manufacturer becomes aware of a reportable incident. Any company that waits until then to determine which products are affected, who is authorized to make decisions, and where the relevant information is located will lose valuable time.
The Cyber Resilience Act does not take effect in 2027
The Cyber Resilience Act, Regulation (EU) 2024/2847, establishes Europe-wide mandatory cybersecurity requirements for products with digital elements. In general, it covers many hardware and software products that are directly or indirectly connected to a device or network. These may include, for example, networked machines, IoT devices, routers, security cameras, mobile applications, or standalone software solutions. Whether a specific product actually falls within the scope of the regulation must be determined based on the regulation itself and the specific manner in which the product is made available on the EU market.
The phased implementation is important here. The regulation entered into force in December 2024. Provisions regarding notifying authorities have been in effect since June 2026. The comprehensive product requirements will largely apply starting December 11, 2027. However, Article 14—and thus the CRA reporting requirements—have applied to manufacturers since September 11, 2026.
These obligations are not automatically limited to products that will be newly introduced to the market starting at the end of 2027. According to current guidance from the European Commission and ENISA, products with digital elements that were already made available on the market prior to that date may also be affected, provided they fall within the scope of the regulation. Manufacturers should therefore evaluate their product portfolios with more than just future developments in mind.
What events must be reported?
Not every vulnerability discovered and not every technical malfunction automatically triggers a report. Article 14 distinguishes between two key categories: actively exploited vulnerabilities and serious security incidents that affect the security of a product with digital elements.
A vulnerability is considered to be actively exploited when there is reliable evidence that a malicious actor has actually exploited the vulnerability without the system owner’s consent. The mere theoretical possibility of an attack or the publication of a proof of concept is therefore not necessarily sufficient. Nevertheless, effective vulnerability management must be able to quickly consolidate and evaluate information from various sources. Information may come, for example, from the organization’s own security monitoring, from customers, security researchers, service providers, or from publicly available alerts.
A serious security incident affects the security of the product and can, in particular, compromise its availability, authenticity, integrity, or confidentiality. Whether an incident meets the legal criteria must be assessed on a case-by-case basis based on its impact. This is precisely where technical analysis, legal assessment, and incident response intersect. A company needs sufficient information to make a quick decision, but it must not delay the assessment until every technical detail has been conclusively clarified.
A real-world example
A manufacturer of connected sensors receives log data from a customer indicating that a vulnerability in the device’s firmware has been successfully exploited. At first, it is unclear which product versions are affected and whether other customers have been attacked. Nevertheless, the deadline does not begin only after the forensic investigation is complete. What matters is the point in time when the manufacturer becomes aware of the actively exploited vulnerability.
In such a situation, the vulnerability management team must log the report, identify the affected product versions, and document existing findings. At the same time, the Incident Response team assesses the technical impact, possible countermeasures, and the need for further escalation. The responsible department must then determine whether the reporting requirements have been met and arrange for timely submission.
24 hours, 72 hours, and the final report
The CRA reporting requirements provide for a tiered process. The initial early warning must be issued without undue delay and no later than 24 hours after the event is discovered. Its purpose is to draw attention to the event and it should contain only the information that is necessary or available at that time.
A follow-up report must be submitted within 72 hours at the latest. In the case of an actively exploited vulnerability, relevant information includes, among other things, general details about the affected product, the nature of the vulnerability, how it is being exploited, and any countermeasures already taken or that may be taken. In the event of a serious security incident, additional information and an initial assessment of the incident are required.
A final report is required thereafter. In the case of actively exploited vulnerabilities, this report must be submitted no later than 14 days after a corrective or mitigating measure becomes available. For serious security incidents, the deadline is generally one month after the 72-hour notification. This phased approach takes into account that a complete picture of the situation is often not yet available within the first 24 hours. However, it does not exempt manufacturers from acting in a structured and transparent manner from the very beginning.
Reports are submitted via the Single Reporting Platform operated by ENISA. There, manufacturers select the appropriate coordinating Computer Security Incident Response Team (CSIRT). Which CSIRT is responsible is generally determined by the company’s main place of business in the EU and by where decisions regarding the cybersecurity of the products are primarily made. Organizational preparation therefore also involves clarifying who within the company is technically authorized to submit the report and who will take over in the event of absences.
Why a contact list alone isn’t enough
The 24-hour deadline makes it clear that readiness to report incidents is a process, not a single document. A contact list can be helpful, but it is no substitute for robust vulnerability management or a well-practiced incident response process. Multiple departments must collaborate quickly: Product development is familiar with versions and components; IT security analyzes technical information; Legal or Compliance assesses regulatory requirements; and Corporate Communications prepares information for customers and partners as needed.
Unclear handoff points are particularly critical. If a support team detects a potential attack, there must be a clear process for when and to whom it should escalate the issue. If an external security researcher reports a vulnerability, the company needs a monitored reporting channel and a defined assessment process. If a third-party component is affected, it must be possible to quickly determine in which of the company’s own products and versions it is used.
A robust product inventory serves as the foundation for this. It should not only include product names, but also list versions, software components, responsible parties, support periods, and relevant dependencies. A software bill of materials can support this analysis because it makes it easier to map affected third-party components to specific products. However, it does not replace the technical assessment of whether a reporting obligation actually exists in each specific case.
This is how a genuine willingness to report issues is fostered
A practical process begins with clearly defined roles. Companies should specify who receives reports, who is responsible for the technical assessment, who makes the legal decision, and who submits the report. Designated alternates are required for each of these roles. In addition, it should be documented what information is required during the various reporting phases and from which systems it can be obtained.
Vulnerability management should be integrated with the product inventory, customer communications, and development processes. Only then can those responsible identify which versions are affected, what mitigations are available, and how users can be informed. At the same time, incident response must be supplemented with product-specific scenarios. A traditional IT emergency plan that focuses exclusively on internal infrastructure is insufficient when an incident affects the security of shipped products.
Regular drills demonstrate whether the established procedures work even under time pressure. A suitable scenario could begin with a customer report of a suspected actively exploited vulnerability. The team would have to assess the plausibility of the report, identify affected products, document the time the issue was first identified, and prepare a decision within a simulated time frame. This often reveals gaps: missing points of contact, incomplete product data, decision-makers who cannot be reached, or uncertainty about the reporting channel.
The results of such exercises should be translated into concrete improvement measures. While the Cyber Resilience Act does not require a complete understanding of all details within 24 hours, it does require that manufacturers act without undue delay and be able to share the available information in a structured manner.
Conclusion: The clock is already ticking
The Cyber Resilience Act is not merely a future issue to be addressed at the end of 2027. The first obligations—which are particularly challenging to implement—are already in effect. Since September 11, 2026, affected manufacturers have been required to report actively exploited vulnerabilities and serious security incidents via the European reporting platform within strict deadlines.
CRA reporting requirements can only be met if product information, responsibilities, and escalation procedures are clarified before an emergency occurs. Companies should therefore verify whether relevant indications are reliably identified, who assesses the reporting obligation, how the time of becoming aware of the issue is documented, and who can submit a report in a timely manner.
Syngenity® GmbH helps organizations integrate the requirements of the European regulation into their existing security and compliance processes in a structured manner. This includes assessing the scope of impact, defining clear roles and escalation procedures, and further developing vulnerability and incident management processes.
After all, the willingness to report a problem doesn’t just arise once the 24-hour deadline has already begun. The key question, therefore, is: Would your company be able today to make the right decision within 24 hours and take the necessary steps?
