TL;DR: EU CRA reporting turns vulnerability disclosure into a 24-hour operational workflow, with ENISA and CSIRTs getting the first warning and later filings following on tight deadlines, according to Cycode. Product security now has to connect detection, ownership, and evidence fast enough to keep the filing path open.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “Are You Prepared for 24-Hour EU CRA Vulnerability Reporting in September? Accelerate Your Readiness with Cycode”.
By the numbers:
- Manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.
- Manufacturers must submit a full notification within 72 hours.
- Manufacturers must submit a final report within 14 days of a corrective measure becoming available.
Key questions
Q: Why does the EU CRA create risk even when a product team has good security tooling?
A: Good tooling does not guarantee timely disclosure.
Q: What are the signs that a vulnerability disclosure workflow is not ready for the EU CRA?
A: Common signs include no named filing owner, no timed tabletop, no measured path from detection to notification, and no clean inventory of EU-sold products and shared components.
Q: What fails first when EU CRA reporting is not operationalised?
A: The first failure is usually ownership, not detection.
Practitioner guidance
- Define the 24-hour reporting authority Name the primary reporter, backup reporter, and decision-maker for determining when an issue becomes an actively exploited vulnerability or severe incident.
- Measure the full detection-to-disclosure timeline Time the workflow from first credible signal to filed early warning, including customer impact mapping, evidence gathering, and sign-off.
- Map every EU-sold product to an owner Maintain a current inventory of products with digital elements, supported versions, shared components, and customer geography so notifications can be scoped quickly.
Bottom line: The EU CRA makes rapid reporting part of product security operations, which means disclosure readiness now matters as much as remediation speed.
Glossary terms: Detection-to-Disclosure Gap, Known Exploited Vulnerability, Reporting Authority, Control-to-Asset Mapping
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
CRA readiness is now a governance test, not just a security test: the reporting obligation only looks simple until organisations have to name the reporter, define the approver, and prove the evidence path. The article shows that the real failure mode is ownership ambiguity under time pressure, which turns a legal deadline into an operating-model question. Practitioners should treat disclosure authority as part of security governance, not a side task.
A question worth separating out:
Q: Who should own CRA reporting and sign-off when a vulnerability is actively exploited?
A: Ownership should sit with a clearly designated security or product security lead, supported by a backup and an executive approver who can act under time pressure. Legal should advise, but the reporting decision itself needs a named operational owner so the filing can happen within the deadline.
👉 Read our full editorial: EU CRA 24-hour vulnerability reporting exposes detection-to-disclosure gaps