SSolarc Labs
Practical Article 9 min read

CRA Reporting Starts 11 September 2026: What the 24-Hour and 72-Hour Clocks Mean for Product Teams

Published September 2026 by Solarc Labs

The EU Cyber Resilience Act reporting obligations for actively exploited vulnerabilities and severe incidents start on 11 September 2026. Product teams should know what evidence and ownership they need before a real clock starts — without automating the legal reportability decision.

11 September 2026 is an operational date, not just a compliance-calendar note

The European Commission states that from 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The Commission’s reporting guidance says an early warning is due within 24 hours of awareness and a fuller notification within 72 hours. The practical implication is that a product team cannot wait until an incident occurs to decide who owns awareness, triage, evidence collection and escalation. The preparation job is to make those responsibilities observable before the reporting clock matters.

The first question is when the manufacturer became aware

A deadline workflow needs a defensible awareness timestamp and a record of what was known at that point. That does not mean every security alert is automatically reportable. It means the team needs a controlled way to record the event, preserve evidence and route the case to the people responsible for technical and legal assessment. Keep detection, awareness, severity assessment and reportability as distinct states. Collapsing them into one automated “CRA incident” label can create false certainty and poor auditability.

Prepare evidence for the 24-hour and 72-hour stages before the first real case

Article 14 of the CRA sets out the staged notification model for actively exploited vulnerabilities, including the 24-hour early warning and the 72-hour vulnerability notification. The Commission also describes a single reporting platform and separate final-report timing. A tabletop should therefore test whether the team can identify the affected product, describe the event at the level actually known, record corrective or mitigating measures, identify owners and preserve the evidence needed for later updates. The goal is readiness, not a rehearsed assumption that every scenario is legally reportable.

Use a readiness desk to expose missing ownership — not to replace legal judgement

A controlled incident-readiness workflow can make missing evidence, unclear ownership and clock handling visible. It should not decide that a vulnerability is “actively exploited”, that an incident meets the legal threshold or that a regulatory submission must be made without the responsible human review. CRA Incident Desk is scoped to one private readiness tabletop: scenario intake, awareness timestamp, human triage, preparation clocks, evidence checklist and an exportable preparation pack. It is not a vulnerability scanner, reporting gateway, legal service or CRA certification.