EU Cyber Resilience Act Reporting: Turning the 24-Hour Clock into a Working Process

A connected product can cross borders instantly; information about its failure often moves more slowly. Europe's Cyber Resilience Act makes that organisational delay consequential. Since 11 September 2026, manufacturers of products within its scope must report actively exploited vulnerabilities and severe incidents affecting product security. ENISA launched the initial operating capability of its Single Reporting Platform on the same date.

This is an implementation milestone under an enacted regulation. The CRA's main obligations apply from 11 December 2027, while manufacturer reporting already applies. Open-source software stewards' corresponding reporting duties begin on 11 December 2027. Businesses should distinguish today's reporting process from the broader product-compliance programme still being implemented.

Establish what starts the clock

The two reporting triggers require separate assessment: an actively exploited vulnerability, or a severe incident affecting product security. Active exploitation requires reliable evidence of malicious exploitation; discovering an ordinary software flaw does not by itself establish that trigger. Teams should assess incident severity against Article 14(5), rather than assuming every security alert belongs in the same reporting category.

Early warnings are required without undue delay and within 24 hours of awareness. The fuller notification follows without undue delay and within 72 hours of awareness. For exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available; for severe incidents, within one month after the incident notification. The later stages have exceptions where the relevant information has already been provided.

Keep responsibility outside the dashboard

ENISA's FAQ, updated on 15 October 2026, identifies an important operational detail: the current platform displays its 72-hour deadline as 48 hours after the early-warning submission. It may consequently display an overdue alert before 72 hours have elapsed from awareness. Manufacturers remain responsible for the statutory timetable. The initial platform also lacks an API, so reporting plans should include a person able to use its interface.

The practical response is a short, rehearsed decision process. Record when the organisation became aware, preserve the supporting evidence, identify affected products, and assign submission authority and backup coverage. Keep an independent deadline record. Run a tabletop exercise that tests whether engineering, security and management can assemble the required information promptly.

Institutional purchasers can use the same exercise to examine supplier arrangements: who supplies evidence, who communicates mitigations, and who helps customers respond? These are practical procurement recommendations, rather than additional statutory reporting duties imposed on every buyer.

For an organisation designing that division of responsibility, a useful next step is to discuss a governance or design assignment with a short, non-confidential description of the product, participants and unresolved decisions.