CRA reporting obligations: what manufacturers must report since 11 September 2026, to whom and how fast

Since 11 September 2026, Article 14 of the Cyber Resilience Act has required manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents within 24 hours of becoming aware. A notification follows within 72 hours, then a final report. Reports go to a CSIRT and ENISA through one platform. The maker reports, not the user.

This guide covers what to report, the deadlines and contents, who receives reports, informing users, scope, NIS2, penalties, what the duty leaves open, and a checklist.

Stage	Actively exploited vulnerability	Severe incident
Early warning	Within 24 hours of becoming aware	Within 24 hours of becoming aware
Notification	Within 72 hours of becoming aware	Within 72 hours of becoming aware
Final report	No later than 14 days after a corrective or mitigating measure is available	Within one month after the incident notification
Sent to	CSIRT designated as coordinator and ENISA, via the single reporting platform	The same

What must manufacturers report under the CRA?

Two things, both about the product rather than the company.

Actively exploited vulnerabilities

Article 14(1) covers “any actively exploited vulnerability contained in the product”. Article 3(42) sets the bar: “reliable evidence that a malicious actor has exploited it in a system without permission” of the system owner.

A vulnerability found in good faith testing, with no sign of malicious use, should not be subject to mandatory notification, recital 68 says. Article 15 lets you report it, and near misses, voluntarily.

“Contained in the product” on a plain reading includes components you did not write, a case the Commission’s CRA FAQ addresses in section 5.4. In practice, many reports will start in someone else’s code.

Severe incidents

Article 14(3) covers “any severe incident having an impact on the security of the product”. Article 14(5) calls an incident severe where it:

1. negatively affects, or is capable of affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
2. has led or could lead to malicious code being introduced or executed in the product or in a user’s network and information systems.

The recitals give examples: malicious code introduced into the release channel for your security updates, or an incident in your development, production or maintenance processes that raises the risk for users. Your internal security is in scope where it touches what you ship.

What are the CRA reporting deadlines, and what goes in each report?

The 24-hour and 72-hour deadlines run “without undue delay and in any event within” the stated period.

1. Early warning, 24 hours. The Member States where, to your knowledge, the product is available; for an incident, also whether you suspect an unlawful or malicious act.
2. Notification, 72 hours. General information on the product and the nature of the exploit and vulnerability (or the incident, with an initial assessment), measures taken, measures users can take, and how sensitive you consider the information.
3. Intermediate report. The receiving CSIRT may ask for a status update (Article 14(6)).
4. Final report. A description with severity and impact. For a vulnerability, add any known malicious actor and the security update; for an incident, the likely threat type or root cause and the mitigation applied and ongoing.

CRA ARTICLE 14 NOTIFICATION WORKSHEET

Product, versions affected: ....................................
Type:        [ ] Exploited vulnerability   [ ] Severe incident
Aware at:    date/time (UTC) ...... source ......................
Decided by:  name, role .........................................
Member States where the product is available: ..................

Early warning due (aware + 24h): ...............................
  incident: suspected unlawful or malicious act? Y / N
Notification due (aware + 72h): ................................
  nature of exploit or incident, measures taken, measures for
  users, sensitivity of the information
Final report due: ..............................................
  vulnerability: 14 days after fix or mitigation is available
  incident: one month after the notification
  description, severity, impact, actor or root cause, fix

Users informed (Art. 14(8)): date ..... channel ................
  machine-readable format? Y / N

Who receives CRA vulnerability reports?

You report once, through the single reporting platform ENISA runs under Article 16. ENISA launched its initial operating capability on 11 September 2026. Each notification goes simultaneously to the CSIRT designated as coordinator and to ENISA.

That CSIRT sits in the Member State of your main establishment: where decisions on the cybersecurity of your products are predominantly taken. Without an EU establishment, Article 14(7) sets a fallback order: authorised representative, then importer, then distributor, each by number of products, then the Member State with the most users. These are the same CSIRTs that coordinate vulnerability disclosure under NIS2, described in the NIS2 vulnerability disclosure framework.

The receiving CSIRT passes the notification to the CSIRTs where you said the product is available. In exceptional circumstances, in particular at your request, it may delay that on justified cybersecurity-related grounds, for no longer than strictly necessary (Article 16(2)).

From ENISA’s FAQ:

• Each person who files must have an EU Login account with multi-factor authentication and register as an assigned representative.
• ENISA advises registering when you need to submit; validation runs in parallel and does not block a first report.
• If the platform is down, wait and file once it is back. If you need to communicate sooner, you may contact your CSIRT directly, but must still file on the platform.

Do you have to tell your users?

Yes. Article 14(8) requires you to inform impacted users, and where appropriate all users, of the vulnerability or incident and, where necessary, of measures they can deploy to mitigate it. Where appropriate, use a structured, machine-readable format. If you do not inform them in a timely manner, the CSIRTs you notified may do so.

Who is a manufacturer, and which products are in scope?

A manufacturer is anyone who develops or manufactures products with digital elements, or has them made, “and markets them under its name or trademark, whether for payment, monetisation or free of charge” (Article 3(13)). A product with digital elements is software or hardware and its remote data processing solutions, including separately sold components, where its intended or foreseeable use includes a data connection to a device or network (Articles 2(1) and 3(1)).

That is broader than software vendors: a connected sensor, an industrial controller, a router, embedded firmware, the cloud back end that makes a device work. SaaS on its own generally is not: recital 12 leaves cloud services developed outside a manufacturer’s responsibility out of the CRA and notes that NIS2 covers SaaS. Products under the EU rules on medical devices, in vitro diagnostics, motor vehicle type approval, certified civil aviation products and marine equipment are excluded, as are products made exclusively for national security or defence.

On timing:

• Products already on the market are covered. Article 69(3) applies Article 14 to all products placed on the market before 11 December 2027. A router sold in 2023 is in.
• The rest of the CRA comes later. Essential requirements, conformity assessment and CE marking apply from 11 December 2027, and reach older products only after a substantial modification (Article 69(2)).
• Open-source software stewards report from 11 December 2027, according to the Commission.
• Already past: entry into force (10 December 2024) and the start of the rules on notifying conformity assessment bodies (11 June 2026).

How does CRA reporting relate to NIS2 incident reporting?

NIS2 asks whether your organisation is secure. The CRA asks about the thing you sell. A company can be outside NIS2 and inside the CRA, or inside both and owe two reports for one event.

	NIS2 Article 23	CRA Article 14
Who reports	Essential and important entities	Manufacturers of products with digital elements
Trigger	Significant incident affecting your services	Exploited vulnerability or severe incident in your product
Early warning	24 hours	24 hours
Notification	72 hours	72 hours
Final report	One month after the notification	14 days after the fix, or one month after the notification
Recipient	CSIRT or competent authority	Coordinating CSIRT and ENISA, via the platform

NIS2 Annex II lists manufacturers of computer, electronic and optical products, electrical equipment and machinery; medium-sized and larger ones are in NIS2 scope. At such a company a compromised update server can be a CRA severe incident and a NIS2 significant incident at once. In practice, map which events trigger which report and write both from one incident record. The NIS2 side is in the NIS2 incident reporting timeline and on the NIS2 compliance page.

The CRA also reaches you through customers. An entity under NIS2 must take into account the quality of its direct suppliers’ products and their secure development procedures (NIS2 supply chain security). Expect “how do you report exploited vulnerabilities?” in security questionnaires and contracts, as telecom suppliers under NIS2 already see.

What happens if you miss a CRA deadline?

Article 64(2) sets fines for breaching Article 14 of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher; Member States lay down the penalty rules. Article 64(10)(a) says fines do not apply to micro and small manufacturers that miss the 24-hour early warning deadline (Article 14(2)(a) or 14(4)(a)), and the Commission’s summary reads it that way. The paragraph is worded as a derogation from paragraphs 3 to 9, though, while the Article 14 fine sits in paragraph 2, so do not treat the exemption as settled. It never covers the 72-hour notification or the final report.

Article 71 brings forward only Article 14 and the conformity assessment body rules; everything else, Article 64 included, applies from 11 December 2027. That affects the enforcement timetable, not the duty, which has applied since 11 September 2026.

What does the CRA reporting duty leave open?

The report is the easy half. Article 14 is procedural: name a person, watch the right channels, file within the window. It says nothing about how you find out, which is where the risk sits. Awareness often arrives from outside: a researcher, a customer, a CSIRT advisory. A 24-hour clock is easy to meet if you know at hour zero. It is impossible if you find out on day nine because the security contact address goes to an inbox nobody reads.

The harder question follows the filing: every customer asks how long the vulnerability was there and whether they are affected. Answering needs an inventory of what is inside each product version, a record of which customer runs which version, and logs from your build and update infrastructure. The regulation asks you to report what you know. It does not make you know anything.

Part of this becomes law later. From 11 December 2027, Annex I, Part II requires a software bill of materials covering at least top-level dependencies, a coordinated vulnerability disclosure policy and a contact address for vulnerability reports. Today’s reporting duty assumes you have them already.

Closing the gap means connecting those records, so a CVE in a component becomes a list of affected versions and customers within hours, with a person deciding what is reportable. The CloudSoul platform works that way: automated evidence collection from your systems, with human-in-the-loop expertise. If you are unsure your release and vulnerability process would hold up, a security audit will tell you before an incident does.

CRA reporting checklist

• Decide whether you place products with digital elements on the EU market, including products sold before 11 September 2026.
• Name the person who decides a report is required, and a deputy, both reachable out of hours.
• Give them EU Login accounts with multi-factor authentication now.
• Publish a security contact address and make sure someone reads it every day.
• Keep a component inventory per product version and match vulnerability feeds against it.
• Record, per product, your main establishment, CSIRT and the Member States where it is sold.
• Prepare a channel to inform impacted users, in a machine-readable format where appropriate.
• If you are also under NIS2, map which events trigger one report and which trigger both.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 2, 3, 14, 15, 16, 64, 69 and 71, Annex I and recitals 12, 67 and 68, EUR-Lex.
• European Commission, Cyber Resilience Act: reporting obligations and summary of the legislative text.
• ENISA, The CRA Single Reporting Platform is launched and Single Reporting Platform FAQ.
• Directive (EU) 2022/2555 (NIS2), Article 23 and Annex II, EUR-Lex.

Frequently asked questions