Connected-product makers now have 24 hours to report exploited flaws under the EU Cyber Resilience Act

According to a practitioner guide posted on dev.to, the trigger is narrower than the headline duty sounds. A vulnerability counts as actively exploited when there is reliable evidence that a malicious actor used it without the system owner's permission ^[5]. A theoretical flaw found in testing is not reportable on its own. The same flaw seen in the wild is ^[5]. The CRA clock then starts at awareness, before anyone has confirmed root cause ^[8].

From that one awareness timestamp, the guide runs three timers in parallel: 4 hours for DORA, 24 hours for CRA and NIS2, and 72 hours for CRA, NIS2 and GDPR ^[9]. By its count, a single incident can mean four deadlines and four recipients, each wanting its own wording ^[10]. A runbook with one "notify the regulator" step puts those filings in a queue. The guide's example of an organisation that could face all four at once is a fintech that ships its own connected app ^[12].

The fix it proposes is good engineering. Triage asks four questions once: whether a product vulnerability is exploited, whether personal data is affected, whether a financial ICT service is disrupted, and whether an essential or important service is impacted ^[13]. Each yes opens its own regulation-specific track ^[13]. Each track has early-warning, notification and final-report templates drafted in advance ^[19]. Every submission draws on one fact sheet, because regulators compare notes ^[15]. Supplying incorrect information to authorities carries its own penalty ^[18]. The design separates establishing the facts from wording them, so the facts get established once. The guide also asks teams to write down who decides an incident is "major" or "significant", and how quickly ^[20].

Supplier code is where I'd expect the first hours to go. The guide warns that open-source components and third-party code can be the source of an exploited vulnerability, and tells manufacturers to keep an up-to-date software bill of materials and clear vendor notification clauses ^[6]. The CRA also expects manufacturers to tell affected users about incidents and the corrective measures available ^[11]. The guide's last step is a tabletop exercise that mixes a CRA vulnerability with a GDPR breach and measures how long a defensible first report takes ^[21].

The deadlines and penalties above are the guide's summary of Regulation (EU) 2024/2847 ^[2]. The post closes with a pitch for VISTA InfoSec's compliance services ^[16]. The checklist above the pitch is the useful part. Its FAQ says CRA reporting does not replace NIS2 or GDPR reporting, and that the CRA covers product security ^[17].