Summary: The first operational part of the EU Cyber Resilience Act takes effect on September 11, 2026. Manufacturers must report actively exploited vulnerabilities and certain severe security incidents through ENISA's new platform. An early warning is due within 24 hours and a fuller notification within 72 hours. The easily missed detail is that this reporting regime starts more than a year before most other CRA obligations and can also cover older products.
Companies that only have December 11, 2027 on their CRA calendar may therefore be late. That date applies to most of the broader technical and organisational product requirements. Article 14 reporting obligations become applicable on September 11, 2026.
24 hours, 72 hours, then the final report
For an actively exploited vulnerability, the EU requires an early warning within 24 hours after the manufacturer becomes aware of active exploitation. A fuller notification follows within 72 hours. A final report must be submitted no later than 14 days after a corrective measure becomes available.
Severe security incidents follow the same 24/72-hour structure. The final incident report is due within one month. Notifications are submitted once through ENISA's Single Reporting Platform, or SRP. They are addressed to the relevant CSIRT coordinator and are normally made available to ENISA at the same time.
The real catch: older products can still be covered
ENISA updated its SRP FAQ on September 4 and clarified an important transition issue: the reporting duties can also apply to products with digital elements that were placed on the market before December 11, 2027, provided they fall within the CRA's scope.
The timing of awareness also matters. A manufacturer is not required to retrospectively report active exploitation it already knew about before September 11. If it becomes aware after that date, however, the reporting obligation may apply even when the underlying vulnerability itself is older.
The mosaic: vulnerability management becomes a reporting chain
The CRA therefore changes more than product development. It changes incident operations. Manufacturers increasingly need to determine quickly whether a vulnerability is being actively exploited, which products are affected, when internal awareness began and which facts are reliable enough to report in the first 24 hours.
This becomes concrete in cases such as the MikroTik attack wave analysed by Pandorex. Patch availability, active exploitation, exposed devices and compromise indicators appeared in a tight timeline. Under the CRA, those same technical questions gain a regulatory timestamp: when did the manufacturer become aware of active exploitation, and when did the reporting clock start?
That does not mean every CVE must automatically be reported to the EU within 24 hours. The trigger is narrower: an actively exploited vulnerability or a severe security incident within the meaning of the CRA. An ordinary bug fix without known exploitation is not the same event.
Open source is not automatically exempt
The common shorthand that “the CRA does not apply to open source” is also too broad. The Commission distinguishes free and open-source software supplied outside commercial activity. If a product is made available on the market in the course of commercial activity, it can fall within the CRA.
The Act also defines a role for open-source software stewards. ENISA explicitly lists manufacturers and such stewards as users of the reporting platform. Individual developers who merely contribute code to software outside their responsibility are treated differently.
What companies need to separate now
The first compliance step is therefore not necessarily a new security product. More important is a reliable internal chain connecting Product Security, PSIRT, engineering, legal teams and the people authorised to submit an SRP notification. If an organisation waits for confirmed exploitation before deciding who owns the 24-hour timer, the hardest organisational problem has already arrived too late.
The deadline should also not be confused with a requirement to complete root-cause analysis within one day. The reporting regime is deliberately staged: early warning, fuller 72-hour notification and a later final report.
Pandorex Analysis
The most important near-term CRA date for security teams is not December 2027 but September 11, 2026. From that day, the question “Is this vulnerability actively exploited?” becomes, for many product companies, a regulatory decision with a very short clock.
Pandorex assessment: The main operational risk is not the reporting portal itself but an unclear internal start point for the reporting chain. Organisations shipping software or connected products should already treat the CRA as an incident-response issue, not merely as a 2027 product-certification project.