CRA Article 14 reporting obligations: a practical guide for manufacturers

What Article 14 requires

Article 14 obliges manufacturers to notify two kinds of event: any actively exploited vulnerability contained in a product with digital elements that they become aware of, and any severe incident having an impact on the security of such a product. The two definitions come from Article 3. An actively exploited vulnerability is one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without the permission of the system owner. A severe incident is one that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led to the introduction or execution of malicious code in the product or in its users' systems.

Notifications go to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment, and to ENISA, at the same time, through the single reporting platform that ENISA operates under Article 16. The obligation has applied since 11 September 2026 to every manufacturer placing products with digital elements on the EU market, whether or not the rest of the regulation (which applies in full from 11 December 2027) already applies to those products.

The three stages

Reporting is staged so that speed and completeness do not compete. Each stage has its own deadline measured from the moment the manufacturer becomes aware, except the vulnerability final report, which runs from the availability of a fix.

Awareness is the trigger

Every deadline is computed from the awareness moment, and the regulation does not define it mechanically. Organisations should decide in advance what awareness means operationally — for example, confirmation by the security lead that the exploitation evidence is credible — and record the timestamp explicitly with its timezone and the person who confirmed it. Inferring awareness from when a ticket was created is a common and costly mistake in both directions: too early and you miss deadlines you never knew were running; too late and you cannot defend the timeline to a CSIRT.

Evidence of active exploitation can arrive from your own telemetry, a customer, a researcher, a CSIRT, a vendor advisory or an exploitation catalogue such as CISA KEV. A KEV listing for a component you ship is a strong reason to open a reportability review immediately; it is not, by itself, the legal determination.

Who reports, and to whom

The obligation sits with the manufacturer. Non-EU manufacturers may mandate an authorised representative to fulfil it. Which coordinator CSIRT receives the notification follows the main establishment — the Member State where decisions related to the cybersecurity of the products are predominantly taken — not the countries where customers are. The single reporting platform routes the submission to that CSIRT and ENISA simultaneously; national electronic notification end-points are connected to it.

Importers and distributors who become aware of an actively exploited vulnerability or severe incident have their own duty to inform the manufacturer without undue delay; the manufacturer then reports. Open-source software stewards report to the extent they are involved in the product's development (Article 24).

Informing users

Article 14(8) adds a second audience: after becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer informs impacted users — and, where appropriate, all users — without undue delay, including about risk-mitigating and corrective measures they can take. The CSIRT may also ask the manufacturer to inform users, or may do so itself if the manufacturer fails to. Draft the user communication from the same facts as the notification and file the sent version as evidence.

What happens after you submit

The coordinator CSIRT may request further information and provides guidance; ENISA aggregates notifications to inform Member States and, where relevant, other manufacturers of the same component. Notifications are treated confidentially — the early warning can carry a sensitivity indication, and the platform limits dissemination where the manufacturer indicates that publication could harm security. None of this changes the manufacturer's duty to fix the vulnerability and update users under Annex I Part II.

Operationalising the obligation

A reportable event rarely arrives labelled. It emerges from a dependency alert, a customer report, telemetry or a disclosure. The operational chain needs:

1. Continuous component visibility — an SBOM per supported product version, matched continuously against vulnerability intelligence with exploitation signals (KEV, EPSS, advisories).
2. A named reviewer and an explicit reportability state: not reviewed → potentially reportable → confirmed or not reportable, with rationale and a recorded awareness time.
3. A deadline engine that computes the 24-hour, 72-hour and final-report dates server-side from the confirmed awareness time, in the organisation's timezone, and alerts at defined thresholds.
4. Staged forms that reuse known facts — product, versions, Member States, measures — so the 72-hour notification is an update of the early warning, not a new document.
5. A record of the official submission: time, submitter, platform reference, receipt, frozen copy of what was sent.
6. A user communication path and an evidence package for the final report and any later audit.
7. A rehearsal. If you have not run a reporting drill yet, run one now — the obligation is already in force — and one per quarter afterwards.

Common mistakes

• Treating the 72-hour notification as the first step and missing the 24-hour early warning.
• Starting the incident final-report timer at awareness instead of at the notification, or adding 30 days instead of one calendar month.
• Starting the vulnerability final-report timer before a fix exists.
• Deriving awareness from ticket creation or from the CVE publication date.
• Reporting to the CSIRT of the customer's country rather than the coordinator CSIRT of the manufacturer's main establishment.
• Forgetting the Member States field in the early warning — it needs current market-availability data per product.
• Keeping no evidence of what was submitted, by whom, at what time.

What Vellaci does and does not do

Vellaci does not decide legal reportability and does not submit to ENISA on your behalf. It prepares, structures, times, records and evidences: the reportability review with awareness discipline, the server-side deadline engine, staged prefilled forms, the submission record as a frozen revision, user-communication drafts and the evidence package. Keep your legal advisers in the loop for threshold questions.