The CRA Reporting Platform Does Not Solve the 24-Hour Evidence Problem

The portal is live. The hard part is upstream.

From 11 September 2026, manufacturers of products with digital elements must use ENISA’s Single Reporting Platform for mandatory notifications of actively exploited vulnerabilities and severe incidents under Article 14 of the Cyber Resilience Act. ENISA describes the SRP as a report-once mechanism: the manufacturer selects the relevant coordinating CSIRT, and the notification can then be made available to ENISA and disseminated to other relevant authorities.

That removes routing friction. It does not remove the operational problem that precedes submission. Before a manufacturer can make a defensible notification, it still has to establish which product and versions are affected, whether exploitation meets the CRA trigger, what is known about impact and mitigation, and who owns the regulatory decision.

The reporting clock measures evidence latency

The engineering metric that matters is therefore not portal completion time. It is evidence latency: how long it takes to move from an external or internal vulnerability signal to a product-scoped, reviewable decision.

A usable operating model links product identity, deployed software versions, component inventory, supplier ownership, exploitability assessment, mitigations and decision authority. SBOM and VEX can support that chain, but neither replaces product-specific analysis or accountable judgement.

The practical test is whether the organisation can produce a bounded statement while some evidence is still incomplete, preserve the uncertainty explicitly, and update the record as stronger evidence arrives.

Related context. CRA reporting readiness builds on the earlier 24-hour evidence decision problem and depends on the same kind of product-scoped exploitability record discussed in VEX evidence and decision traceability.