CRA reporting starts 11 September 2026

From that date, any manufacturer of a product with digital elements sold into the EU has 24 hours to file an early warning once it becomes aware that a vulnerability in its product is being actively exploited. Not 24 business hours. This page sets out what the obligation actually says, who it binds, and what to have in place before the date.

until CRA Article 14 applies
11 September 2026

The reporting cascade

Article 14 sets four clocks, all of them running from the moment the manufacturer becomes aware — not from the moment it finishes investigating.

The 24-hour clock is the part teams underestimate. It presumes someone is already watching, already empowered to declare, and already knows which CSIRT to file with. Most hardware organisations have none of those three on a weekend.

Who it binds

Manufacturers of products with digital elements made available on the EU market. That is a deliberately wide category: software, IoT devices, industrial and OT systems, networking gear, connected appliances, and embedded systems.

Two points that catch teams out:

Where the report goes

Manufacturers file once, through the CRA Single Reporting Platform. The notification goes to the CSIRT designated as coordinator in the member state of the manufacturer's main establishment, and reaches ENISA at the same time. The receiving CSIRT then forwards it without delay to the CSIRTs of other member states where the product is available.

Practically, that means one thing worth settling before September: know which CSIRT is yours, and know who in the organisation is authorised to press send at 2am.

The wider CRA timeline

What to have ready

September is a reporting deadline, not a compliance deadline — the CE-marking work is a year further out. But the reporting duty is the one that can be triggered by someone else's disclosure, on someone else's schedule. A minimum posture before the date:

  1. A named on-call owner with authority to declare, and a documented deputy.
  2. The identity of your coordinating CSIRT, written down where the on-call owner can find it.
  3. A vulnerability intake channel that a researcher can actually reach — and that someone reads.
  4. A current inventory of supported products and their software components, so "which products are affected" is answerable in hours rather than weeks.
  5. A pre-drafted early-warning template, because 24 hours is not the time to start writing one.

Free tools to check where you stand

Three companion tools from Tangibles, all free and requiring no sign-up to run:

IoT Security Scorecard → A 19-question audit aligned with ETSI EN 303 645. Returns a risk grade, mandatory-compliance flags, and prioritised fixes. Regulatory Landscape → Which frameworks bind your product, by archetype, market, and buyer — CRA, PSTI, IEC 62443, ISO 27001 and more. Security Requirements Generator → An archetype-specific requirement list mapped to EN 303 645 provisions. Exports to Markdown or CSV for a PRD. Chapter 18 sources → The attack-surface case studies behind the chapter, with primary sources and archived snapshots.

Primary sources

Where this comes from. Chapter 18 of Tangibles — "Connected AND Secured? Think Again" — works through the attack surface across silicon, firmware, radios, and cloud, and Chapter 19 covers the regulatory response.

Read the chapter preview → · About the book →

This page summarises publicly available regulatory material for product teams planning their readiness work. It is not legal advice, and it is not a substitute for reading Regulation (EU) 2024/2847 or taking qualified counsel on how it applies to a specific product. Last reviewed 4 August 2026.

© 2026 Yoel Frischoff / TheRoad. All rights reserved. · Press · Teaching · Privacy · Terms · Accessibility