CRA reporting for manufacturers: Art. 14

This guide shows when the duty applies, what belongs in each stage and how the process works day to day.

Who has to report

Manufacturers. You develop a product with digital elements, or have it developed, and market it under your own name or trademark (Art. 3(13)).
Importers and distributors. They count as manufacturers if they place a product on the market under their own name or substantially modify it (Art. 21).
Others who substantially modify. Anyone who substantially modifies a product and makes it available counts as the manufacturer for the affected part, or for the whole product if the change affects its cybersecurity as a whole (Art. 22).

The duty also covers products placed on the market before 11 December 2027 (Art. 69(3)). According to the Commission guidance, it does not end with the support period either (C(2026) 5252, paragraph 210).

Two events trigger a report

Actively exploited vulnerability. There is reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's permission (Art. 3(42)). This includes a vulnerability from a purchased component if it was exploited in your product.
Severe incident. The incident affects the product's ability to protect sensitive or important data or functions, or is capable of doing so. It is also severe if it has led or can lead to malicious code in the product or in a user's network (Art. 14(5)).

What you do not have to report

Not every vulnerability is reportable. The Commission's guidance and FAQ draw clear lines:

Known but unexploited vulnerability. A finding in a component that cannot be exploited in your product, or has not been exploited there, is outside mandatory reporting (paragraph 218).
Finding from testing or a bug bounty. A zero-day found by a test lab or an ethical hacker is not reportable without evidence of malicious exploitation (Commission FAQ on zero-day vulnerabilities).
Exploitation you already knew about. If you were aware of the active exploitation before 11 September 2026, you need not report retroactively. If you only learn of it afterwards, the duty applies, even if the vulnerability itself is older (paragraph 217).

Handling the vulnerability is a separate duty and still applies. You also report it to the maker or maintainer of the component (Art. 13(6)). Art. 15 additionally allows voluntary reports.

When the clock starts

The clock starts when you become aware. The Regulation does not define this moment, but the Commission guidance describes it: you assess a suspicious event immediately. You are aware once that initial assessment gives you a reasonable degree of certainty that active exploitation or a severe incident has occurred (paragraph 213).

So you do not wait for the end of the full analysis. The guidance is not binding, but it shows the Commission's view. Record the date, the time and the reason for your assessment.

Three stages and what belongs in each

You report step by step and add what you have learned since. You need not repeat information you have already provided.

Stage	Deadline	Actively exploited vulnerability	Severe incident
Early warning	Without undue delay, within 24 hours of becoming aware	Member States where you know the product has been made available	Whether unlawful or malicious acts are suspected; Member States where applicable
Notification	Without undue delay, within 72 hours of becoming aware	Product, nature of the exploit and vulnerability, measures taken, measures for users, sensitivity of the information	Nature of the incident, initial assessment, measures taken, measures for users, sensitivity of the information
Final report	Vulnerability: no later than 14 days after a corrective or mitigating measure is available. Incident: within one month of the notification	Description with severity and impact, information on the malicious actor if available, the fix provided	Detailed description with severity and impact, type of threat or root cause, applied and ongoing mitigation

The CSIRT designated as coordinator can also ask for an intermediate report (Art. 14(6)).

Where the report goes

Platform. You report through ENISA's single reporting platform, in operation since 11 September 2026. According to the ENISA FAQ, reports go through the platform interface; no API was provided at launch.
Responsible CSIRT. What counts is the Member State of your main establishment, meaning where decisions on the cybersecurity of your products are mainly taken. If that cannot be determined, it is the establishment with the most employees in the Union (Art. 14(7)). For Germany, the ENISA list names CERT-Bund.
Report once. The report is accessible to ENISA at the same time. The CSIRT forwards it to the coordinators of the states where, according to you, the product has been made available (Art. 16(2)).

Manufacturers without a main establishment in the Union follow the order in Art. 14(7): authorised representative, importer, distributor, then the state with the most users.

The people who report need a personal EU Login account with multi-factor authentication. ENISA advises starting registration only when you need to report and says it takes a few minutes once the EU Login account exists. So settle in advance who has such an account.

Informing users

Besides the authorities, you inform the impacted users, and where appropriate all users, of the vulnerability or incident. Name the measures users can take themselves, where appropriate in a structured, machine-readable format (Art. 14(8)).

This does not mean publishing the details. According to the guidance, you may limit the information to the customers concerned, particularly for products in sensitive environments (paragraph 220).

Vendor advisory in CSAF format with an operator's affected assets (test data) — How a machine-readable advisory reaches the operator: Complass matches it to their assets.

The process in six steps

Assess what comes in. A report comes from customers, researchers, authorities or your own monitoring. A named person assesses it at once.
Record awareness. If the event is reportable, note the time and the reasoning. The deadlines run from here.
Send the early warning. Report what you know. This stage asks for no more.
Add the notification. Within 72 hours at the latest, add the nature of the event, an initial assessment and the measures.
Inform users. Tell those affected what to do, and record whom you informed and when.
Submit the final report. No later than 14 days after the fix, or one month after the notification, close the case and note what you have learned.

Example from industry

This example is invented. A maker of industrial gateways gets a call from a plant on a Friday:

Friday, 3:10 pm. An operator reports unexplained configuration changes on a gateway. Support passes the case to the named person.
Friday, 6:40 pm. The logs show third-party access through the device's web server. That is reliable evidence, and the time of awareness is recorded.
Saturday, 10:00 am. The early warning goes to CERT-Bund through the platform and names the countries where the gateway was sold.
Sunday, 4:00 pm. The notification adds the nature of the exploit and a workaround.
Monday, 9:00 am. Affected customers get a direct advisory recommending that they block the web interface.
Twelve days later. The corrected firmware is available. The final report follows within 14 days.

Reporting in Complass

With Excel and email, you hold deadlines, drafts and evidence together yourself. In Complass, it all sits in one case:

Incident from the finding. If an actively exploited vulnerability affects one of your own products, you create the Art. 14 incident pre-filled, from the finding, the vulnerability report or the product version.
Deadlines from awareness. The portal calculates the stages from the time you enter. Running deadlines appear as a band on the dashboard.
Assessment with reasons. Assessment questions lead to a proposal per reporting track. You make the decision and record the reason.
Draft per stage. Complass prepares the content for copying field by field or as a PDF. You submit the report yourself through the reporting platform; Complass transmits nothing.
Informing users. You write security advisories, publish them as CSAF, send them to your recipient lists and prove the dispatch.
Evidence. You enter the time and reference for each stage. You download the reporting record as a PDF.

Checklist

The products in scope are known, including older products in the field.
A reporting person and a deputy are named, also for weekends.
Both have an EU Login account with multi-factor authentication.
The responsible CSIRT is determined.
Criteria for "actively exploited" and "severe" are written down.
The time of awareness is documented with the reasoning.
The list of countries where the product was made available is current.
Text blocks and distribution lists for informing users are ready.
The process has been rehearsed once.

Frequently asked questions

Does the duty also apply to devices that have long been in the field?

Yes. Art. 14 applies to all products in scope, even if they were placed on the market before 11 December 2027 (Art. 69(3)). The vulnerability handling requirements of Annex I Part II, by contrast, do not apply to these products unless they are substantially modified (Art. 69(2), paragraph 210).

Do weekends and public holidays count?

Art. 14 sets deadlines in hours and makes no exception for weekends or public holidays. So plan for a reachable deputy. The early warning deadline can be met with very little information.

Is there any relief for small companies?

Yes, one. Fines do not apply to micro and small enterprises for missing the 24-hour early warning deadline (Art. 64(10)). The duty itself and the other deadlines apply to them as to everyone else.

An incident affects our product and our company. Do we report twice?

That can happen, because NIS2 or the GDPR may apply alongside the CRA, each with its own recipients and deadlines. In Complass, you add another reporting track to the same incident. The whitepaper on reporting duties sets the rules side by side.

The free calculator works out the deadlines for your case, without sign-up. In a demo, we show you the path from the finding to the final report.

Request a demo Calculate CRA reporting deadlines

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The Commission's guidance and FAQ are not binding. ENISA information as of 15 October 2026.

CRA reporting duty for manufacturers: what Art. 14 requires and how to report