The Cyber Resilience Act starts the incident clock
Product security reporting requires a startup to recognise a reportable event, assemble evidence and submit promptly through the European platform. Readiness depends on the people and procedures behind each notification.
An exploited defect in a commercial software product can now start a European reporting clock before the investigation is complete. On 11 September 2026, the Cyber Resilience Act's manufacturer reporting obligations began applying, and ENISA's Single Reporting Platform became operational. The immediate requirement concerns actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
The launch precedes the Act's main obligations, which apply from 11 December 2027. Product conformity work has a later timetable, while reporting already requires people who can recognise the trigger, assemble an initial account and make a submission. Security budgets need to account for both schedules.
An exploit is different from a scan result
ENISA defines an actively exploited vulnerability by reliable evidence that a malicious actor has exploited it without the system owner's permission. A newly discovered weakness and evidence of malicious exploitation are therefore different findings. Severe incidents provide the other reporting route, with criteria concerning the security of the product and its ability to protect data or functions. The assessment needs the facts of the event and the product's role.
This distinction creates a specific operating requirement for smaller teams. A scanner, customer support ticket, researcher message or incident investigation may supply part of the evidence, but someone has to decide what it establishes. The startup needs a record of when it became aware, the facts available at that point and how it classified the event. Those records also help keep later submissions consistent as an investigation develops.
What each reporting stage requires
Manufacturers must submit an early warning without undue delay and within 24 hours of awareness, followed by a notification within 72 hours of awareness. The second deadline does not start when the first form is filed. A final report on an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification.
- Awareness
Reporting trigger
Establish the known facts and whether the event is an actively exploited vulnerability or a severe incident.
- Within 24 hours
Early warning
Submit without undue delay; the outer limit runs from awareness.
- Within 72 hours
Notification
Provide the relevant notification and initial assessment; this clock also runs from awareness.
- Vulnerability final report
Within 14 days of a measure
The final-report deadline follows availability of a corrective or mitigating measure.
- Incident final report
Within one month
The final-report deadline runs from the 72-hour severe-incident notification.
Final reporting follows different deadlines for vulnerabilities and incidents, as set out in Commission guidance and ENISA's FAQ.
The initial warning cannot wait for a complete analysis of the cause. Teams need to separate information required immediately from information that can be added as it becomes available. ENISA's guidance distinguishes mandatory fields, information required when available and fields used at later stages. Recording what remains uncertain allows teams to update a submission as they establish the facts.
The platform does not finish the workflow
Manufacturers report once through the Single Reporting Platform, selecting the relevant national CSIRT coordinator. Information is generally made available simultaneously to ENISA and shared with other relevant national teams, subject to exceptional arrangements. This reduces the need for separate national submissions, but the manufacturer remains responsible for selecting the correct coordinator and organising its own reporting across corporate entities.
ENISA's subsequent FAQ update confirms that the initial release has no application programming interface. Notifications must be submitted through the platform interface. Security software can automate internal evidence gathering and preparation, but submission still requires that manual step. Investors need to check exactly which parts of the process a product supports.
The installed base needs an owner
ENISA's implementation FAQ confirms that reporting reaches products within the Act's scope that were placed on the market before December 2027. It also distinguishes an old vulnerability from an earlier awareness of active exploitation. A manufacturer need not report retrospectively where it already knew of the exploitation before 11 September 2026; awareness arising after that date can trigger the obligation even when the underlying weakness existed earlier.
An acquisition or an abandoned product line can therefore make the product inventory important. A startup needs to know which versions it supplied, which components they contain and where customer reports arrive. A repository of current code alone may miss the software customers still run. Diligence should examine that installed product base and the team's ability to associate evidence of exploitation with the relevant releases.
The platform uses personal EU Login accounts with multifactor authentication and permits primary and secondary assigned representatives. ENISA explains that submitted notifications can be continued by another representative associated with the manufacturer, while drafts remain local to the individual account. That difference is consequential during a handover: a colleague may be able to update a submitted report but cannot assume access to a draft another person started.
For a small company, readiness is visible in an ordinary exercise. Identify a hypothetical reportable event, locate the affected product record and hand the evidence to the person responsible for submission. Check who takes over if that person is unavailable. The reporting launch creates a clear market need for reliable product security operations, while the venture case still depends on whether a tool reduces real investigation and coordination work for the manufacturer.
Investment implications
- Manufacturers must report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform.
- The stages at 24 and 72 hours run from awareness; deadlines for final reports differ for exploited vulnerabilities and severe incidents.
- ENISA's initial platform requires submission through its interface, limiting claims of fully automated regulatory reporting.
Sources
- Cyber Resilience Act - Reporting obligations (opens in a new tab)
European Commission
- Frequently Asked Questions: CRA Single Reporting Platform (opens in a new tab)
European Union Agency for Cybersecurity (ENISA)
- Single Reporting Platform (SRP) (opens in a new tab)
European Union Agency for Cybersecurity (ENISA)
- Cyber Resilience Act (opens in a new tab)
European Commission
Published
