The Cyber Resilience Act’s main product-security requirements are still more than a year away, but one important part of the regime is already operating. Since 11 September 2026, manufacturers have had as little as 24 hours to begin reporting actively exploited vulnerabilities and severe security incidents, turning regulatory readiness into an immediate operational challenge.

The first CRA deadline is already live

Much of the discussion around the EU Cyber Resilience Act has focused on what manufacturers will need to do when its main cybersecurity requirements become applicable on 11 December 2027. Secure-by-design obligations, vulnerability handling, software updates and conformity requirements have understandably dominated the preparation work, particularly for organisations still trying to understand how far the regulation reaches into their existing product portfolios.

One of the regulation’s most important operational requirements, however, has already arrived. Since 11 September 2026, manufacturers of products with digital elements made available in the EU have been required to report actively exploited vulnerabilities and severe security incidents through the Single Reporting Platform operated by the EU Agency for Cybersecurity, ENISA. The process begins with an early warning submitted without undue delay and, in any event, within 24 hours of the manufacturer becoming aware of the problem, with a fuller notification normally following within 72 hours.

For actively exploited vulnerabilities, a final report must then be provided no later than 14 days after a corrective or mitigating measure becomes available. Severe incidents require a final report within one month of the 72-hour notification. The important shift is that the CRA is no longer entirely a regulation organisations are preparing for in theory, because part of it is already an operating requirement that has to function under real-world pressure.

Not every vulnerability starts the clock

The distinction between a vulnerability and a reportable vulnerability matters because the CRA does not require manufacturers to report every weakness they discover within 24 hours. The reporting obligation applies to an actively exploited vulnerability, meaning there is reliable evidence that a malicious actor has exploited it without the permission of the system owner, as well as to severe incidents affecting the security of products with digital elements.

This creates an immediate challenge for manufacturers because identifying a technical weakness is one process, while establishing whether that weakness is being exploited is another. An organisation may receive information from its own monitoring systems, customers, security researchers, national authorities, threat-intelligence providers or other companies within its supply chain, and somewhere inside that flow of information it has to determine whether the regulatory threshold has been crossed.

Once that threshold is reached, the 24-hour period begins. The real operational problem is therefore not simply completing a regulatory submission, but ensuring that the organisation can recognise quickly enough that the obligation to report has been triggered.

Twenty-four hours changes the internal workflow

Product security rarely belongs to one department. A serious vulnerability may involve developers, product managers, vulnerability-management teams, incident responders, legal departments, senior management, communications teams and external suppliers, all of whom may hold different pieces of the information needed to understand what has happened.

Under a conventional process, those groups might spend considerable time establishing the facts before information leaves the organisation. The CRA changes that sequence because the first report is deliberately an early warning rather than a complete forensic account, meaning manufacturers are not expected to know everything within 24 hours but are expected to recognise that a reportable event exists and begin the formal process.

ENISA’s reporting guidance reflects that distinction. The initial submission establishes the basic facts, including the affected product, the nature of the notification and when the manufacturer became aware of the event, while more detailed information about impact, mitigation and corrective measures develops through the 72-hour notification and subsequent final report.

This turns vulnerability reporting into an internal coordination problem as much as a technical one. Organisations need to know who can determine that a vulnerability appears to be actively exploited, who has responsibility for starting the CRA process and who is authorised to communicate with the relevant authorities before an incident occurs.

Awareness becomes a governance issue

The wording of the regulation also places considerable importance on the moment a manufacturer becomes aware of an actively exploited vulnerability or severe incident. In a small organisation that may be relatively easy to define, but in a large or multinational company the point of awareness can be far less obvious.

A security researcher might notify a regional development team, a customer may report suspicious activity to support, threat intelligence could identify exploitation affecting a third-party component, or a subsidiary may see activity before the parent company does. The regulatory clock can therefore begin before senior management, legal teams or central security functions have a complete picture of the event.

The CRA’s reporting system anticipates some of this complexity. ENISA states that only one notification is required for a particular vulnerability or severe incident even where a manufacturer has multiple branches or subsidiaries in the EU, including situations where the parent organisation is based outside the Union. The responsibility for coordinating that information internally, however, remains with the manufacturer.

This makes internal visibility critical because a company cannot meet a 24-hour external reporting deadline if it takes longer than that for information to move between its own engineering, security and management structures. For many organisations, CRA readiness will therefore depend as much on information flows, escalation paths and decision rights as it does on technical cybersecurity capability.

One report, but a European response

The Single Reporting Platform is intended to simplify the external side of the process by allowing manufacturers to submit one notification through ENISA rather than separately informing multiple national authorities. The notification is directed to the appropriate CSIRT designated as coordinator and is simultaneously made available to ENISA, with the coordinating CSIRT then able to distribute relevant information to other national CSIRTs where the affected product has been made available.

That creates a more coordinated European vulnerability-reporting system, particularly for products distributed across several Member States. It also means that a report submitted by a manufacturer can become part of a wider European security response rather than remaining an isolated compliance exercise.

Information from confirmed exploitation can feed vulnerability coordination between national CSIRTs and ENISA’s broader vulnerability services, including the EU catalogue of known exploited vulnerabilities. For manufacturers, this raises the importance of both speed and accuracy because the information they provide may influence how security authorities across Europe understand and respond to a developing threat.

The supply chain complicates the picture

Modern digital products rarely consist entirely of software written by one manufacturer. Operating systems, open-source libraries, communications components, embedded software, cloud services and third-party code can all form part of the final product, which means that a vulnerability may originate deep inside a supply chain while creating reporting consequences much further downstream.

The CRA recognises this reality, including specific guidance covering actively exploited vulnerabilities contained in third-party components. ENISA and the European Commission have also been developing detailed guidance to help manufacturers understand how those responsibilities should work in practice, particularly where several organisations depend on the same component.

The operational lesson is difficult to avoid. Manufacturers need to know what is inside their products and where critical components come from if they are expected to assess quickly whether a newly exploited vulnerability affects them.

Software bills of materials, vulnerability intelligence and supplier communication therefore become more than examples of good technical hygiene. They form part of the information infrastructure required to make regulatory decisions quickly and to understand how exposure moves through increasingly complex digital supply chains.

Reporting is becoming part of product security

There is another reason the September deadline matters, because it begins to change the meaning of product-security responsibility before the CRA’s broader requirements arrive. Historically, vulnerability management has often been treated primarily as an engineering or security function in which a weakness is identified, assessed and eventually patched.

Regulatory reporting introduces another layer because the organisation must now demonstrate that it can recognise serious security developments, understand their significance and respond according to a defined process. The CRA therefore connects technical detection with organisational accountability in a way that makes product security a wider management responsibility.

That connection becomes particularly important when products remain in use for years. The European Commission has clarified that CRA reporting obligations can apply to products already available on the EU market, including products placed on the market before the main December 2027 requirements take effect.

The September deadline therefore concerns existing product portfolios as well as products currently being designed for future CRA compliance. Organisations preparing only their next generation of products may therefore be missing the more immediate question of whether their current products, processes and reporting structures are capable of meeting the obligations already in force.

The clock is already running

The broader cybersecurity requirements of the Cyber Resilience Act will become fully operational in December 2027, and manufacturers still have considerable work ahead as they prepare products, processes and documentation for that point. The reporting regime provides an earlier and more practical test of whether that preparation is actually working.

A 24-hour notification requirement forces organisations to answer questions that regulations often leave hidden until something goes wrong. They need to know who recognises that an exploited vulnerability exists, who decides whether it is reportable, who has authority to act, how quickly information can move from engineering to security, legal teams and management, and how accurately the organisation can identify which products and customers may be affected.

Those processes cannot be improvised once an incident is already underway. Europe has effectively placed product security on a clock, and the organisations best prepared for the Cyber Resilience Act will be those that understand that the clock is already running.