One of the most common misunderstandings in CRA preparation is treating vulnerability reporting and incident reporting as the same obligation. They are not. The regulation creates two separate reporting tracks under Article 14, with different triggers, different timelines, and different consequences for missing deadlines. Getting this distinction right is the foundation of any compliant internal process.
When Reporting Obligations Come Into Force
The vulnerability and incident reporting obligations under Article 14 become mandatory on 11 September 2026. This is the earlier of the CRA's two major deadlines. It applies to products with digital elements already on the EU market, not only to new products placed on the market after that date.
Full conformity requirements, including CE marking and the broader set of essential requirements under Annex I, follow in December 2027. But the reporting infrastructure must be operational from September 2026. Manufacturers who wait for the December deadline will be out of compliance for 15 months.
The Two Reporting Tracks
Vulnerability reporting
A vulnerability becomes reportable under Article 14 when it is actively exploited in the field. The test is not severity, not CVSS score, not internal risk classification. It is evidence of exploitation. When that threshold is crossed, the following cascade is mandatory:
- 24 hours: Early warning to the CRA Single Reporting Platform, which routes to ENISA centrally and to the relevant national CSIRT.
- 72 hours: Detailed technical notification covering severity, affected versions, indicators of compromise, and known impact.
- 14 days: Final report covering root cause, fix or mitigation, and the coordinated disclosure strategy.
The 24-hour clock starts from the moment the manufacturer becomes aware of active exploitation, not from when internal triage is complete. This matters operationally: discovery and notification must happen in parallel, not in sequence.
Incident reporting
A significant incident is a broader category that covers disruption to the security or functionality of a product caused by a cybersecurity event, regardless of whether an active vulnerability is the cause. The timelines differ:
- 24 hours: Early warning, same routing as vulnerability reporting.
- 72 hours: Detailed notification.
- 30 days: Final report (one month more than for vulnerabilities).
The distinction between a “significant” incident and a routine one is not explicitly defined in the regulation. The guidance from ENISA treats severity of impact, breadth of affected users, and whether the incident represents a systemic risk as relevant factors.
Which Products Must Report
Article 14 applies to manufacturers of products with digital elements. The definition is broad: hardware or software with a digital component that connects to a network or another device. It covers consumer IoT, industrial equipment, network devices, connected hardware, firmware-embedded products, and software applications with a standalone security function.
Importers and distributors have secondary obligations. If a manufacturer outside the EU has not met the reporting obligations, the importer or authorised representative becomes responsible for compliance.
Products in Annex III (important products) and Annex IV (critical products) have additional conformity assessment obligations, but the Article 14 reporting requirements apply uniformly across all product classes from September 2026.
How Reporting Is Routed
The CRA establishes the Single Reporting Platform (SRP) as the central submission point. Manufacturers submit to the SRP, which then routes notifications to ENISA and to the national CSIRT in the member state where the manufacturer is established. ENISA may also share information with other relevant national authorities.
The SRP is operated by ENISA and has been in pilot testing since early 2026. Manufacturers should register with the platform before the September deadline, not on the day they need it. Credentials, contact details, and product registration must all be in place in advance.
Internal Processes That Must Exist Before September 2026
The reporting timeline cannot be met without internal preparation. The following processes must be operational, not planned, by September 2026:
Detection and escalation path. The organisation must have a defined mechanism for identifying that a vulnerability is being actively exploited. This typically combines threat intelligence feeds, customer and researcher reports via the VDP, ENISA's EUVD database, and CSIRT advisories. When a trigger is identified, escalation to the person authorised to initiate Article 14 reporting must happen within the first hour, not the first day.
Triage authority. Someone must have explicit, documented authority to declare that an event meets the reporting threshold and to initiate the notification cascade without requiring additional approval. Waiting for sign-off from legal or senior management inside a 24-hour window is operationally incompatible with compliance.
Pre-drafted report templates. The early warning and detailed notification forms must exist before an incident occurs. The SRP submission fields should be understood, the templates prepared, and the login credentials tested. Building these under pressure during a live incident is where deadlines are missed.
Audit trail. Every detection event, triage decision, escalation, and notification must be timestamped and retained. This is not optional documentation. It is the primary evidence that the process operated correctly, and it is what a market surveillance authority will request.
Coordinated disclosure planning. The 14-day or 30-day final report must include a disclosure strategy. This requires early thinking about which affected parties need to be notified, whether a CVE identifier should be requested, when public disclosure is appropriate, and how to sequence communication with affected customers. These decisions cannot be made for the first time inside the reporting window.
The SME Readiness Gap
Larger organisations with established PSIRTs and threat intelligence programmes already have most of these capabilities in some form. For the majority of SMEs manufacturing hardware or software for the EU market, none of them exist today.
Building compliant detection, escalation, triage, reporting, and disclosure processes from scratch in the months remaining before September 2026 is achievable. It requires deliberate prioritisation and, for most SMEs, tooling that reduces the engineering burden.
CVD Portal provides the intake, triage, reporting, and audit trail infrastructure required for Article 14 compliance as a service. Manufacturers can be operationally ready with a functioning VDP, structured escalation workflow, pre-built report templates aligned to ENISA's notification format, and full audit trail without building any of it in-house.
The Bottom Line
Vulnerability and incident reporting under the CRA are two distinct obligations with overlapping timelines, separate triggers, and different final report deadlines. Both become enforceable on 11 September 2026, on every product with digital elements in the EU market. The internal processes required to meet those timelines must be in place and tested before that date, not planned for after it.