Notifications
Clear all
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.
NHIMG editorial — based on content published by FOSSA: the EU Cyber Resilience Act reporting requirements now in effect
Questions worth separating out
Q: What should teams do first when a CRA reportable vulnerability is discovered?
A: Teams should immediately preserve evidence, timestamp awareness, and decide whether the issue is an actively exploited vulnerability, a severe incident, or both.
Q: Why do product security issues create regulatory risk under the CRA?
A: Because the CRA turns technical findings into timed obligations.
Q: What breaks when filing authority is not pre-assigned for CRA reporting?
A: Reporting becomes slow, ambiguous, and vulnerable to internal bottlenecks.
Practitioner guidance
- Create a CRA reporting decision tree Define who decides whether an event is an actively exploited vulnerability or a severe incident, and record the evidence required at each stage.
- Pre-authorise filing identities and approvals Map Primary AR and Secondary AR responsibilities, enforce multi-factor authentication, and keep a tested backup path for submission if the primary filer is unavailable.
- Align detection outputs to reportable fields Ensure scanners, incident tooling, and case management capture product name, version, awareness time, corrective measures, and user mitigations in a form usable for the SRP.
What's in the full article
FOSSA's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step interpretation of Article 14 triggers for actively exploited vulnerabilities and severe incidents
- Submission workflow details for ENISA’s Single Reporting Platform, including the role of Assigned Representatives
- Field-by-field breakdown of the 24-hour, 72-hour, and final reporting stages
- Practical notes on how to inform impacted users and when machine-readable notices are appropriate
👉 Read FOSSA’s full guide to the EU Cyber Resilience Act reporting requirements →
EU cyber resilience act reporting now: what product teams must file?
Explore further
14/09/2026 10:11 am
Reporting deadlines expose the weakness of traditional split ownership. Many product organisations still separate engineering, security operations, and regulatory response into different chains of command. CRA Article 14 collapses those separations by making awareness, assessment, and filing time-bound obligations that depend on one coordinated workflow. That makes governance design, not just vulnerability detection, the real control question for product teams.
A question worth separating out:
Q: Who is accountable for CRA reporting in a multi-entity organisation?
A: Accountability sits with the manufacturer of the product as placed on the EU market, but the operational filing path may involve assigned representatives, importers, distributors, or open source stewards in limited cases. Organisations need a documented internal owner so the legal obligation and the filing action line up before an incident occurs.
👉 Read our full editorial: EU cyber resilience act reporting now forces faster vulnerability disclosure
