Topic starter
14/09/2026 10:10 am
TL;DR: The EU Cyber Resilience Act’s Article 14 reporting duty now applies to actively exploited vulnerabilities and severe security incidents for products on the market, including older products, with 24-hour, 72-hour, and final reporting stages governed through ENISA’s Single Reporting Platform, according to FOSSA. For IAM and security teams, this turns disclosure, evidence collection, and user notification into a time-bound operational process rather than a later compliance exercise.
Editorial analysis by NHI Mgmt Group, based on content published by FOSSA: “Meeting the CRA's 2026 Reporting Requirements”.
Key questions
Q: What breaks when CRA reporting depends on manual coordination?
A: Manual coordination breaks the CRA model because the regulation compresses discovery, escalation, and notification into a 24-hour window.
Q: Why does a vulnerability become reportable under the Cyber Resilience Act?
A: A vulnerability becomes reportable when there is reliable evidence that it has been actively exploited, or when a severe incident affects the product’s ability to protect confidentiality, integrity, authenticity or availability.
Q: What do product teams get wrong about CRA notification deadlines?
A: They often treat the reporting timeline as a documentation task instead of an incident workflow.
Practitioner guidance
- Define the reportability decision tree Map what qualifies as an actively exploited vulnerability versus a severe security incident, and document who makes the call when evidence is incomplete.
- Pre-register filing roles and backups Assign Primary AR and Secondary AR coverage, and verify the EU Login and multi-factor authentication path before an incident forces submission.
- Inventory in-scope products already on market Maintain a live list of products with digital elements that are already available in the EU, including older releases and support-end products.
Bottom line: The CRA’s early reporting duty changes product security from a release-time concern into a live operational obligation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:11 am
CRA reporting turns vulnerability disclosure into a governed operational control. The article shows that reporting is now time-bound, event-driven and mandatory for products already in market. That means disclosure readiness sits alongside detection, triage and customer notification as a core security process. For product organisations, the real governance question is whether evidence, decision rights and filing paths are already mapped before the first reportable event.
A few things that frame the scale:
- The 2026 Verizon DBIR found that exploitation of software vulnerabilities became the leading initial access vector in confirmed breaches, accounting for 31% of incidents.
A question worth separating out:
Q: Who is accountable for CRA reporting when multiple entities sell the same product?
A: Accountability should sit with the manufacturer of record or the entity treated as the manufacturer under the CRA, but internal responsibility still has to be assigned explicitly. Organisations with importers, distributors or open-source stewards in the chain need a clear decision model so one submission is made through the correct establishment and authority path.
👉 Read our full editorial: EU cyber resilience act reporting now forces faster vulnerability disclosure