Back to Blog

Cyber Resilience Act: From 11 September 2026, Notification Obligations Kick In for Software and Connected Device Manufacturers

·5 min read
Cyber Resilience Act - Article 14 Notification Timeline

From 11 September 2026, manufacturers of installable software, firmware, or connected devices sold in the EU market have 24 hours to send an early warning to ENISA every time a vulnerability in their product is actively exploited. The Single Reporting Platform is under construction and will be operational in time: manufacturers who have not yet built an internal notification process have fewer than 100 days to do so.

Regulation (EU) 2024/2847 — the Cyber Resilience Act — has been in force since 11 December 2024, but the bulk of its obligations enter into application in three tranches. The first concerns Articles 14 and 16: mandatory notification of vulnerabilities and serious incidents, with clock-bound deadlines. On 11 September 2026, fewer than 100 days from now, the countdown begins.

This does not only affect major software companies. The Regulation applies to anyone who places a "product with digital elements" on the EU market — a deliberately broad definition.

Who Is Really Affected

"Products with Digital Elements": Software, Apps, Firmware, IoT — Including SMEs

The CRA applies to manufacturers of products with digital elements: any hardware or software that includes digital components and can connect to a device or network (Art. 3(1) Reg. 2024/2847). The practical list includes installable software (desktop, server, mobile), firmware for embedded devices, industrial IoT sensors and actuators, routers, and connected cameras.

An Italian SME that develops an on-premise management system and sells it to customers in Germany is in scope. A firmware supplier for industrial sensors is in scope. A business mobile app published on an app store is in scope.

The most contentious point for software companies concerns cloud-only SaaS: an application delivered exclusively as a cloud service, with no installable components on the client side, tends to fall outside the CRA's scope. However, if the cloud backend constitutes "remote data processing" designed by the manufacturer and necessary for the product's core functions (Art. 3(2)), the distinction becomes less clear-cut. The European Commission published draft guidance on 3 March 2026; the final version is expected during 2026. Companies delivering SaaS with dependencies on proprietary cloud processing should verify their position before September.

Key Exemptions

Outside the CRA's scope: products already regulated by sectoral frameworks with equivalent cybersecurity requirements (medical devices, aviation, automotive), open-source software developed without a commercial purpose, good-faith security research activities, and coordinated disclosure practices compliant with ENISA guidelines.

What Triggers on 11 September 2026

Article 14 of Regulation (EU) 2024/2847 establishes two separate mandatory notification tracks, each with its own chain of deadlines.

Actively Exploited Vulnerabilities — 24h → 72h → 14 Days

When a manufacturer becomes aware that a vulnerability in their product is being actively exploited (exploited in the wild), the following chain is triggered (Art. 14(1)-(2)):

  • Within 24 hours: early warning to ENISA via the Single Reporting Platform — product identification, general nature of the vulnerability, indication that active exploitation is underway.
  • Within 72 hours: detailed notification with classification, severity, potential impact, and available mitigation measures.
  • Within 14 days: final report with complete analysis, remediation plan, and released patches or workarounds.

Serious Incidents — 24h → 72h → 1 Month

For serious security incidents affecting the product, the first two phases are identical; the final report allows a broader window (Art. 14(3)-(5)):

  • Within 24 hours: early warning.
  • Within 72 hours: detailed notification.
  • Within 1 month: final report.

The two timelines frequently overlap: a serious incident is almost always associated with an exploited vulnerability. In such cases, both tracks apply in parallel.

The ENISA Single Reporting Platform

One Notification, Two Recipients

Article 16 of the CRA establishes the Single Reporting Platform (SRP), managed by ENISA. The principle is "notify once, reach all": a submission via the SRP automatically transmits information both to ENISA and to the coordinating CSIRT of the Member State where the manufacturer has its principal EU establishment.

For Italian SMEs, the coordinating CSIRT is ACN — Agenzia per la Cybersicurezza Nazionale. A separate notification to ACN is not required if the SRP is used. The platform will be operational on 11 September 2026; the operational manual and training materials will be available by June 2026.

Required Fields by Phase

The required fields differ across the three phases: the early warning requires product identification and confirmation of active exploitation; the 72-hour notification adds the CVE (if assigned), potential impact on end users, and mitigation measures; the final report includes root cause analysis, released patch with version number, and lessons learned. Pre-filling separate templates for each phase significantly reduces errors under the pressure of a live incident.

What to Do Now

With 98 days to go, there is enough time — but only if you start now.

  1. Inventory CRA-scope products: compile a list of every product with digital elements distributed in the EU market — installable software, firmware, mobile apps, IoT. For each product: verify whether it falls under the exemptions or, in the case of SaaS, whether the "remote data processing" question requires a specific analysis.
  2. Identify the coordinating CSIRT: for Italian SMEs, this is ACN. Companies with bases in multiple Member States should consult the ENISA national CSIRT registry to identify the competent coordinator.
  3. Monitor the ENISA SRP: the operational manual is expected in June 2026. Follow enisa.europa.eu for onboarding materials.
  4. Define internal triggers: what constitutes an "actively exploited vulnerability" for CRA purposes? Documented criteria are needed — confirmed public exploit, notification from a CERT/CSIRT, evidence from threat intelligence — to distinguish it from an ordinary bug. These criteria must be decided before September, not during an incident.
  5. Build a 24/7 escalation process: the 24-hour deadline for the early warning does not observe weekends or public holidays. A named on-call contact with decision-making authority and pre-approved templates for the first notification is required.
  6. Pre-fill templates for all 3 phases: early warning (24h), detailed notification (72h), final report — each has different required fields; preparing them now reduces errors and omissions under pressure.

Manufacturers who already manage NIS 2 notification obligations can partially integrate the two processes: the cascade logic is similar, even though the recipients and triggers differ. See NIS 2 Italy: the 31 October 2026 deadlines for the operational comparison.

Sanctions

Article 64 of Regulation (EU) 2024/2847 provides for three levels of sanctions:

  • Tier 1 — violation of essential security requirements, including the notification obligations of Article 14: €15 million or 2.5% of global annual turnover, whichever is higher.
  • Tier 2 — other violations of the Regulation: €10 million or 2% of global annual turnover.
  • Tier 3 — false or misleading information provided to supervisory authorities: €5 million or 1% of global annual turnover.

An important clarification for micro and small enterprises: these entities cannot be penalised for failure to meet notification deadlines — the 24-hour window for the early warning on an actively exploited vulnerability (Art. 14(2)(a)) and the 24-hour window for the early warning on a serious incident (Art. 14(4)(a)). The obligation to notify exists in every case: the exemption applies to sanctions for late timing, not to exemption from the obligation itself.

Sources