- Since 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of their products (Article 14 of Regulation (EU) 2024/2847).
- Three steps: early warning within 24 hours, notification within 72 hours, and a final report 14 days after a fix is available (vulnerabilities) or one month after the notification (incidents).
- Reports go to the CSIRT designated as coordinator in your main EU establishment's Member State, and simultaneously to ENISA, via the Single Reporting Platform.
- It applies to all products already on the market, not only new ones. The rest of the CRA follows on 11 December 2027.
Who has to report: manufacturers and the products in scope
The Cyber Resilience Act (CRA) covers products with digital elements: hardware and software whose intended or foreseeable use includes a data connection to a device or network. That ranges from routers, cameras and smart-home devices to desktop and mobile apps, firmware and software libraries that are sold or otherwise monetised.
A manufacturer is anyone who "develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge" (Article 3(13)). An importer or distributor that puts its own brand on a product, or substantially modifies one, becomes a manufacturer too (Article 21).
Points to note for SMEs:
- Pure SaaS is generally out of scope. The CRA covers cloud only as a "remote data processing solution" that is needed for a product to work, such as the app backend of a smart thermostat. The recitals say cloud services designed outside the responsibility of a product manufacturer are not covered, and point to NIS2 for SaaS, PaaS and IaaS.
- Sector carve-outs exist for products under their own regimes, such as medical devices, motor vehicles, civil aviation and marine equipment.
- Size does not exempt you from reporting. Micro and small manufacturers only escape fines for missing the 24-hour early-warning deadline (Article 64(10)(a)), not the duty itself.
What triggers a report
1. An actively exploited vulnerability
A vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3(42)). A vulnerability reported by a researcher, or found in your own testing, is not "actively exploited" until there is evidence of real-world malicious use. Then the clock starts when you become aware of that evidence.
2. A severe incident having an impact on the security of the product
Under Article 14(5), an incident is severe where it:
- 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
- has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.
The classic example is a compromise of your build pipeline or update server that could push malicious code to customers. Note that the incident is about your product's security, which can include your own development and distribution infrastructure.
Deadlines and content
| Stage | Actively exploited vulnerability (Art. 14(2)) | Severe incident (Art. 14(4)) |
|---|---|---|
| Early warning | Without undue delay, within 24 hours of becoming aware. Where known, the Member States where the product is available. | Within 24 hours. Whether it is suspected to be caused by unlawful or malicious acts, and where known the Member States concerned. |
| Notification | Within 72 hours: general information on the product, the nature of the exploit and the vulnerability, corrective or mitigating measures taken, measures users can take, and how sensitive you consider the information. | Within 72 hours: the nature of the incident, an initial assessment, measures taken and measures users can take, and the sensitivity of the information. |
| Final report | No later than 14 days after a corrective or mitigating measure is available: description, severity and impact, information on the malicious actor where available, details of the security update. | Within one month after the 72-hour notification: detailed description, severity and impact, likely threat type or root cause, applied and ongoing mitigation. |
| Intermediate report | Only if the coordinating CSIRT requests status updates (Art. 14(6)). | |
Each later stage applies "unless the relevant information has already been provided", so a complete early warning does not have to be repeated. Use our breach deadline calculator to turn an awareness timestamp into concrete due dates, and set calendar reminders.
How to report: the Single Reporting Platform
Notifications go through ENISA's Single Reporting Platform (SRP), which went live on 11 September 2026 at portal.cra-srp.enisa.europa.eu. You submit to the electronic end-point of the CSIRT designated as coordinator in the Member State of your main establishment in the EU: where cybersecurity decisions about your products are predominantly taken, or failing that, where you employ the most staff in the EU (Article 14(7)). ENISA receives the notification at the same time, and the coordinating CSIRT shares it with CSIRTs in other Member States where the product is available. In exceptional cases it may delay that dissemination on cybersecurity grounds.
Manufacturers without an EU establishment report to the CSIRT of the Member State where, in this order, their authorised representative, importer or distributor for the most products is established, or where most of their users are.
According to ENISA's FAQ, the people who report for a manufacturer need an EU Login account with multi-factor authentication, and the platform launched in English. Register your reporters before you need them: a 24-hour deadline is a bad moment to set up accounts.
Informing your users
Article 14(8) adds a duty that is easy to overlook. After becoming aware of an actively exploited vulnerability or a severe incident, you must inform the impacted users, and where appropriate all users, together with the mitigation and corrective measures they can take, where appropriate in a structured, machine-readable format. If you do not do this in time, the CSIRT may inform your users itself. A security advisory page and a CSAF or similar feed are the practical answer.
Open-source stewards and open-source components
An open-source software steward is a legal person, other than a manufacturer, that systematically supports the development of specific free and open-source products intended for commercial activities and ensures their viability. Foundations are the typical example. Stewards have a lighter regime (Article 24): a documented cybersecurity policy, cooperation with market surveillance authorities, and reporting under Article 14 only to the extent they are involved in development, or for incidents affecting the infrastructure they provide for development. ENISA's FAQ states that steward reporting applies from 11 December 2027. Stewards cannot be fined under the CRA (Article 64(10)(b)).
Hobby open-source projects that are not monetised are not manufacturers. But if you ship a product containing an open-source library and that library is actively exploited in your product, the reporting duty is yours as the manufacturer of the product. From 11 December 2027 you must also report vulnerabilities you find in integrated components, open-source ones included, to whoever maintains them (Article 13(6)).
The rest of the CRA timeline
- 10 December 2024CRA enters into force (published in the Official Journal on 20 November 2024).
- 11 June 2026Chapter IV applies: rules for conformity assessment bodies (notified bodies).
- 11 September 2026Article 14 reporting applies to all products in scope, including those placed on the market before 11 December 2027 (Article 69(3)).
- 1 October 2026: you are here
- 11 December 2027Full application: essential cybersecurity requirements (Annex I), vulnerability handling, CE marking, conformity assessment, support periods, technical documentation, and obligations for importers, distributors and open-source stewards. Products placed on the market before this date only fall under these requirements after a substantial modification.
- 11 June 2028Existing EU type-examination certificates for cybersecurity requirements under other legislation expire, unless they expire earlier.
Fines for breaching Annex I or Articles 13 and 14 reach EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)).
CRA and NIS2 reporting side by side
The two regimes look alike (24 hours, 72 hours, a final report) but answer different questions. NIS2 asks whether your service to customers was significantly disrupted. The CRA asks whether your product is being exploited or its security was compromised.
| CRA Article 14 | NIS2 Article 23 | |
|---|---|---|
| Who | Manufacturers of products with digital elements (any size) | Essential and important entities in Annex I/II sectors |
| Trigger | Actively exploited vulnerability; severe incident affecting product security | Significant incident affecting the provision of the entity's services |
| Recipient | Coordinating CSIRT and ENISA via the Single Reporting Platform | National CSIRT or competent authority, via national channels |
| Timeline | 24h / 72h / final 14 days after the fix (vulnerability) or 1 month (incident) | 24h early warning / 72h notification / final report within 1 month |
| Since | 11 September 2026 | Depends on national transposition (the deadline was 17 October 2024) |
A company can be in both. A medium-sized maker of network equipment can fall under NIS2 (manufacture of computer, electronic and optical products is an Annex II sector) and under the CRA. A compromise of its update server could then be both a significant incident under NIS2 and a severe incident under the CRA, with two reports to two channels. Plan for both in one playbook. The CRA recitals encourage Member States to offer national single entry points, and in November 2025 the Commission proposed an EU-level single entry point for incident reporting as part of its Digital Omnibus package. Until such a point exists in your country, assume you report separately. If personal data is affected, the GDPR's 72-hour breach notification runs alongside both. If you are a NIS2 entity, our NIS2 significant-incident checker helps with the "significant" test.
Readiness checklist
- List your products with digital elements and the Member States where they are available.
- Determine your main establishment and therefore your coordinating CSIRT.
- Register at least two reporters on the Single Reporting Platform with EU Login and MFA.
- Define "actively exploited" and "severe incident" in your vulnerability and incident procedures, with examples.
- Set up intake: a security contact (for example security.txt), a coordinated vulnerability disclosure policy, and monitoring of threat intelligence such as the CISA KEV catalogue and CSIRT advisories.
- Keep an SBOM so you can tell within hours whether an exploited component is in your products.
- Prepare templates for the 24h, 72h and final reports, plus a user advisory.
- Log awareness timestamps: the clock runs from when you become aware.
- Rehearse once with a tabletop exercise, combining the CRA, NIS2 and GDPR clocks where relevant.
Run the clocks from one incident record
Dazr Compliance's incident register records the awareness time once and shows each deadline: GDPR 72 hours, NIS2 24h, 72h and one month, and custom clocks such as the CRA final report. It keeps evidence and authority case references in an exportable audit trail.
FAQ
Does CRA reporting apply to products sold before 11 December 2027?
Yes. Article 69(3) makes the Article 14 reporting obligations apply to all in-scope products, including those placed on the market before 11 December 2027. The design requirements only apply to such legacy products after a substantial modification.
When does the 24-hour clock start?
When the manufacturer becomes aware of the actively exploited vulnerability or severe incident. For vulnerabilities, that is when you have reliable evidence of malicious exploitation, not when the bug was first reported.
Is our SaaS platform covered by CRA reporting?
Generally not, unless it is a remote data processing solution without which a product with digital elements cannot perform one of its functions. SaaS as such falls under NIS2 if you meet its size and sector criteria.
Are small companies exempt?
No. Micro and small manufacturers must report too. They cannot be fined for missing the 24-hour early-warning deadline, but the other obligations and fines still apply.
Related
Sources (as of 1 October 2026)
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 3, 13, 14, 16, 21, 24, 64, 69 and 71.
- ENISA: The CRA Single Reporting Platform is launched, 11 September 2026.
- ENISA Single Reporting Platform FAQ.
- European Commission: Cyber Resilience Act reporting obligations.
- Directive (EU) 2022/2555 (NIS2), Article 23.
This guide explains the CRA as of 1 October 2026 and is not legal advice.