CRA reporting: two triggers, two final-report clocks

CRA reporting: two triggers, two final-report clocks

A security alert reaches a manufacturer of a connected device, but the affected firmware range is still uncertain. Should the team wait for a complete investigation before reporting under the EU Cyber Resilience Act? The first decision is narrower: does the evidence point to an actively exploited vulnerability in a product with digital elements, or to a severe incident affecting that product’s security? Both paths can require an early warning within 24 hours and a notification within 72 hours of awareness. Their final-report deadlines diverge.

Article 14 of Regulation (EU) 2024/2847 has applied to manufacturers since 11 September 2026. The wider CRA regime has a different application schedule. This page is based on Articles 14, 16 and 71 and the Commission’s current reporting guidance, checked on 4 October 2026.

Start with the product and the responsible operator

Article 14 places these mandatory notifications on the manufacturer of a product with digital elements made available on the Union market. A device, software product or associated remote data processing solution must be assessed against the statutory definition and its intended or reasonably foreseeable connection. A digital component alone is not a reliable scope test. Open-source software stewards have a separate reporting provision and later start date; importers and distributors have their own CRA duties but should not automatically be described as Article 14 reporting manufacturers.

A business marketing a private-label product under its own name or trademark should identify who is the manufacturer for that product. A supplier contract can set an escalation route for vulnerability signals, but it cannot make an internal handoff a substitute for the manufacturer’s statutory assessment and notification.

Classify the signal before starting the clock

The first Article 14 route is an actively exploited vulnerability. A theoretical weakness with no evidence of active exploitation is not the same trigger, although vulnerability handling may still be required. The second route is a severe incident having an impact on the product’s security. “Severe” has a defined threshold in Article 14(5); a routine failure or any customer complaint does not automatically meet it.

Keep the first alert, triage notes and the point at which the manufacturer became aware of the reportable condition. An unverified ticket is useful evidence, but its arrival is not automatically the legal awareness time. Record what was known, what was tested, which product versions were implicated and why the classification changed. This protects the calculation of the statutory deadlines without treating uncertainty as permission to leave a credible trigger in an ordinary support queue.

The notification sequence and its two endings

For either reportable route, Article 14 calls for an early warning without undue delay and in any event within 24 hours of awareness, followed by the vulnerability or incident notification without undue delay and in any event within 72 hours of awareness. The 72-hour period does not restart after the early warning. The later notification adds available detail on the product, the nature of exploitation or incident, and corrective or mitigating measures. A team should submit the information it can substantiate at each stage rather than wait for a final root-cause analysis before its first warning.

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after submission of the 72-hour incident notification. These are different reference events. A single “follow up later” calendar entry can therefore create a missed deadline. Article 14 also avoids demanding the same information again where it has already been provided.

Make the report usable for a specific version

Consider a notice that names a software library but cannot identify the affected firmware builds of products sold in the EU. Even a successful platform submission would leave support staff, patch owners and customers working from different product populations. Link the manufacturer identity, model, software and firmware versions, Union market scope, first credible evidence, classification rationale, submission receipts, customer communications and corrected build. This is a practical evidence trail, not a prescribed Article 14 form.

Manufacturers submit once through the CRA Single Reporting Platform. The notification is addressed to the coordinating CSIRT for their main establishment and, subject to the exceptional arrangements described by the Commission, made available to ENISA. The platform does not decide the product’s scope or eliminate remediation, user communication or duties under other applicable law.

A useful rehearsal

Take one product currently sold in the EU and trace a simulated signal from the first technical report to the affected versions, the manufacturer decision, the 24-hour warning, the 72-hour notification, the correct final-report trigger and the released fix. If a step lacks an owner or source record, repair that handoff now. Check the current Commission and ENISA SRP instructions for the actual submission fields. This is an interpretation of the cited rules, not a legal or forensic decision for a particular incident.