EU Cyber Resilience Act: Reporting Obligations From 11 Sep 2026, 24/72-hour Timelines and ENISA Single Reporting Platform

EU Cyber Resilience Act reporting obligations for manufacturers of products with digital elements begin to apply on 11 September 2026, opening a new and demanding chapter in product-security compliance across the European Union. From that date, manufacturers must report actively exploited vulnerabilities and severe security incidents through ENISA’s single reporting platform against tight 24-hour and 72-hour deadlines. The urgency is heightened by an unusual asymmetry: while these reporting duties are among the first CRA obligations to apply, the bulk of the substantive requirements of Regulation (EU) 2024/2847 do not apply until 11 December 2027, leaving an interim window in which companies may need to report incidents before having completed their full compliance programmes.

This guide explains who must report, what triggers a notification, how the ENISA platform works, and how these duties intersect with NIS2 and GDPR, with practical, Ireland-focused steps for manufacturers, in-house counsel, CISOs and product-security teams.

Quick overview: CRA reporting obligations now coming into force

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the EU’s horizontal cybersecurity law for products with digital elements. It entered into force on 10 December 2024. Among its provisions, the reporting duties are among the first to apply, from 11 September 2026. For in-house counsel and security leads, understanding the eu cyber resilience act reporting obligations is becoming an operational priority rather than a distant planning exercise.

The Regulation distinguishes between two categories of reportable event:

• Actively exploited vulnerabilities. A vulnerability in a product with digital elements that is being used by a malicious actor, whether or not the manufacturer has issued a fix.
• Severe security incidents. An incident that has a material adverse impact on the security of the product or on the confidentiality, integrity or availability of the data it processes or the functions it performs.

Each category triggers a staged reporting sequence: an early warning within 24 hours, a fuller notification within 72 hours, and a final report thereafter. For actively exploited vulnerabilities, the final report is generally due no later than 14 days after a corrective or mitigating measure becomes available; for severe incidents, a final report is due within one month of the 72-hour notification. The staged approach recognises that manufacturers rarely have complete information at first detection, and prioritises speed of early notification over completeness.

The interim period between the reporting duties applying (11 September 2026) and the main body of substantive obligations applying (11 December 2027) is significant. During this window, a manufacturer may be legally obliged to report an actively exploited vulnerability even though the wider conformity, documentation and secure-by-design requirements are not yet mandatory. Counsel should treat reporting readiness as a discrete, immediate workstream.

Who counts as a manufacturer and what products are in scope

The Regulation casts the net widely. The core obligation falls on the manufacturer, the natural or legal person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark. But responsibility does not stop there.

• Importers. Businesses placing on the EU market a product from a manufacturer established outside the Union carry obligations to ensure compliance and, in defined circumstances, to act where the manufacturer does not.
• Distributors. Those making a product available on the market must exercise due care in relation to compliance and cooperate with authorities.
• Authorised representatives. Where a manufacturer outside the EU appoints a representative, that representative may carry specified duties on the manufacturer’s behalf.

The concept of a “product with digital elements” is broad: it captures software and hardware products, and their remote data-processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. In practice this reaches consumer IoT devices, industrial control components, operating systems, applications, network equipment and connected appliances.

Certain products regulated under sector-specific EU frameworks, for example, particular medical devices, in-vitro diagnostic devices, aviation products or motor vehicles, are excluded or subject to specialised regimes to avoid double regulation. Manufacturers with product lines that straddle these boundaries should map each product against both the CRA and any sector-specific regime, because an IoT device may sit clearly within the CRA while a connected medical device may be governed principally by medical-device law. Legacy products that remain supported and placed on the market also warrant careful analysis.

Getting scope right is the foundation of any credible approach to the eu cyber resilience act reporting obligations, because the reporting duty presupposes that you have correctly identified yourself as an in-scope economic operator.

What must be reported and the thresholds for notification

Two thresholds drive the reporting duty, and both require judgement.

Actively exploited vulnerabilities. A vulnerability moves from theoretical to reportable when there is evidence that a malicious actor is exploiting it. Practical indicators include observed exploitation in telemetry, exploit code circulating in the wild against your product, threat-intelligence reports naming your product, or customer reports of compromise traceable to a specific flaw. The trigger is the exploitation, not merely the existence of the vulnerability.

Severe security incidents. Severity is assessed by impact. Signals include a significant loss of availability of the product or its functions, unauthorised access to or exfiltration of data, loss of integrity of processed data, or a compromise affecting a large number of users or safety-critical functions. An incident affecting the security of the product that could enable an actor to compromise data confidentiality, integrity or availability should be treated as potentially reportable.

At the moment of first discovery, the priority is to capture a minimum evidentiary record so that later reports are accurate and defensible. Record, as a minimum:

• Date and time of detection, and the source of the alert.
• The affected product, version and, where known, the affected component or dependency.
• A short description of the vulnerability or incident and observed impact.
• Evidence of active exploitation (logs, indicators of compromise, threat-intelligence references).
• Actions taken and mitigations in progress.
• The internal owner and escalation path.

This local record is not the report itself, but it is what turns a chaotic first hour into a structured submission and underpins compliance with the eu cyber resilience act reporting obligations under time pressure.

ENISA single reporting platform: the central channel and how it works

The Regulation designates a single reporting platform, established and maintained by ENISA, as the mechanism through which manufacturers submit their notifications. The platform is intended to be operational to coincide with the start of the reporting obligations from 11 September 2026. Manufacturers should treat this platform as the authoritative destination for CRA notifications and should not rely on ad hoc emails or informal contacts as a substitute for a proper submission.

Using the ENISA single reporting platform for CRA reporting obligations

Practically, preparing to use the platform means resolving several operational questions in advance rather than at the point of crisis:

• Access and registration. Confirm how your organisation obtains access, who is authorised to submit, and whether more than one named contact should hold credentials so a report is never blocked by a single absent individual.
• Report types and forms. The platform distinguishes between the early warning, the notification and the final report, and between vulnerability and incident reporting. Understand which fields are mandatory at each stage.
• Attachments and supporting material. Prepare guidance for teams on what technical detail, logs and indicators to attach, and how to structure them.
• Confidential and sensitive information. Consider how to handle information that is commercially sensitive or that could aid attackers if disclosed, and apply appropriate anonymisation or restriction where the platform permits.

Confidentiality and onward sharing

Reports submitted through the platform are not public disclosures in the manner of a press release. The platform is designed to route information to the relevant authorities, including the relevant national CSIRT designated as coordinator and, where appropriate, market surveillance authorities, so that they can coordinate response and, where necessary, protect users. Manufacturers understandably worry about being named or about premature disclosure of an unpatched flaw. The framework recognises the risk that early disclosure can increase harm, and information handling is calibrated accordingly; in defined circumstances a manufacturer may raise justified grounds relating to imminent risk or ongoing investigations.

Nonetheless, counsel should assume that submitted material may be shared with authorities across Member States and should draft reports precisely, factually and without speculation.

To operationalise the platform, prepare internal templates for each report type, agree sign-off responsibilities (who approves a submission and how quickly), and maintain a current list of named platform contacts. These small pieces of preparation are what allow a manufacturer to meet the eu cyber resilience act reporting obligations calmly rather than reactively.

Timelines: the 24-hour early warning, 72-hour notification and final reports

The reporting clocks start when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. “Awareness” is a practical threshold: it is reached when the manufacturer has a reasonable basis to believe that a reportable event has occurred, not the moment a full forensic picture is complete. Because awareness can begin with a single credible alert, escalation processes must be fast enough that the responsible team learns of a potential event within the first hours, not days.

1. 24-hour early warning. This is a minimal, viable notification. It should identify the manufacturer and product, confirm that a reportable event is occurring, describe in outline what is known, and indicate whether the event is believed to be caused by unlawful or malicious action. Completeness is not expected; speed is.
2. 72-hour notification. This fuller submission builds on the early warning. It should include the technical characteristics of the vulnerability or incident, the assessed impact and severity, and the corrective or mitigating measures taken or planned. It updates and corrects the initial picture.
3. Final report. For an actively exploited vulnerability, the final report is generally due no later than 14 days after a corrective or mitigating measure is available. For a severe incident, the final report is due within one month of the 72-hour notification. The final report should give a complete description, root-cause analysis, applied mitigations, and lessons learned.

A simple decision-tree helps teams act quickly: Is there credible evidence of active exploitation or a severe impact on the product’s security or the data it handles? If yes, the 24-hour clock has started, issue the early warning even if detail is thin, then schedule the 72-hour follow-up immediately. Sample early-warning wording can be as short as: “[Manufacturer] is notifying an actively exploited vulnerability in [product/version]. Exploitation observed at [time]. Impact assessment and mitigations are in progress; a fuller notification will follow within 72 hours.” Treating the timelines as fixed operational milestones is the single most important discipline in complying with the eu cyber resilience act reporting obligations.

Interaction with NIS2, GDPR and national incident reporting duties

A single event can trigger several parallel legal duties. The same ransomware intrusion might be an actively exploited vulnerability under the CRA, a significant incident under Directive (EU) 2022/2555 (NIS2) if the entity is an essential or important entity, and a personal data breach under Regulation (EU) 2016/679 (GDPR) if personal data is affected.

These regimes are not identical. They have different triggers, different notification recipients and different, though sometimes overlapping, timelines. GDPR requires notification of a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours. NIS2 imposes its own early-warning and reporting cadence on in-scope entities, including a 24-hour early warning and a 72-hour notification. The CRA adds the manufacturer-focused 24/72-hour sequence through the single reporting platform.

The practical answer is coordination rather than duplication of effort. We recommend:

• Appointing a single incident commander who owns the master timeline and ensures each obligation is assessed against its own trigger.
• Maintaining one shared factual record from which each separate notification is drafted, so the narratives are consistent.
• Sequencing notifications deliberately, recognising that CRA and GDPR clocks may run simultaneously from closely related moments of awareness.

For Irish organisations, this means engaging with domestic authorities alongside the platform. Personal data breaches are notified to the Data Protection Commission, which publishes practical guidance and contact points. Significant cyber incidents affecting Irish entities are coordinated with the National Cyber Security Centre. Ireland’s transposition of NIS2 is being given effect through national legislation; organisations should check the current status of the relevant Irish measures. Building both into your escalation matrix ensures the eu cyber resilience act reporting obligations are handled in step with, not in isolation from, national duties.

How CRA reporting compares with NIS2 and GDPR reporting

Enforcement, fines and micro/small enterprise considerations

Non-compliance carries real consequences. The Regulation provides for administrative fines and for the enforcement powers of national market surveillance authorities, which can require corrective action, restrict or prohibit the making available of a product, or order a withdrawal or recall. The CRA sets tiered maximum administrative fines, with the highest tier applying to breaches of core essential requirements and obligations, lower ceilings for other obligations, and a further tier for the supply of incorrect, incomplete or misleading information to authorities. The precise ceilings are set out in the Regulation and are expressed as fixed maxima and as percentages of worldwide annual turnover, whichever is higher; counsel should consult the current text for the applicable figures.

The Regulation also builds in proportionality. When authorities decide on the amount of a fine, they take into account factors such as the nature, gravity and duration of the infringement, whether the operator cooperated, and whether the breach was self-reported. In practice, prompt and candid engagement, including timely use of the reporting platform, is likely to be treated as a mitigating factor, while concealment or delay is likely to aggravate.

Micro and small enterprises benefit from specific tailoring within the framework, and the Regulation directs that the situation of such enterprises be considered in enforcement so that penalties are proportionate. This does not exempt small manufacturers from the reporting duty; the obligation to report an actively exploited vulnerability or severe incident applies regardless of company size. These considerations shape how obligations are administered and how enforcement discretion is exercised, not whether the eu cyber resilience act reporting obligations apply at all.

Practical incident-response playbook for manufacturers

The best way to meet tight deadlines is to rehearse them. A CRA-aware incident-response playbook maps each phase of your response to a specific reporting milestone.

1. Detection. Ensure telemetry, threat intelligence and customer channels feed a monitored inbox or ticket queue, and that a suspected exploitation or severe impact escalates immediately.
2. Triage. Within hours, assess whether the event meets the “actively exploited” or “severe incident” threshold. Document the reasoning either way.
3. Early warning. If the threshold is met, issue the 24-hour early warning via the platform using a pre-approved template.
4. Fuller notification. Assemble technical detail, severity assessment and mitigations for the 72-hour submission.
5. Remediation. Develop and deploy corrective or mitigating measures, and communicate with affected customers where appropriate.
6. Final report. Complete the root-cause analysis and submit the final report within the applicable window.

Assign clear roles before an incident: an incident commander who owns the timeline and the submissions; legal counsel to assess the parallel CRA, NIS2 and GDPR triggers and manage privilege; and a security lead to drive technical investigation and remediation. Keep two short templates ready, one for the 24-hour early warning and one for the 72-hour notification, so drafting under pressure becomes a matter of populating fields rather than composing from scratch.

Throughout, preserve evidence rigorously. Capture and hold logs, indicators of compromise, forensic images and communications, and maintain a clear chain of custody so that later reports, and any subsequent regulatory scrutiny, rest on defensible records. Sound evidence handling is inseparable from meeting the eu cyber resilience act reporting obligations credibly.

Contractual flow-down to suppliers and component vendors

Modern products are assemblies of third-party components, so a manufacturer’s ability to report on time depends on suppliers reporting to it on time. In-house counsel should update supply and development contracts to flow down the practical substance of the CRA regime. Key clauses to include:

• Reporting obligation. Require suppliers to notify you of vulnerabilities and incidents affecting supplied components, with defined internal deadlines that leave you room to meet your own 24/72-hour clocks.
• Cooperation and information-sharing. Oblige suppliers to provide technical detail, root-cause information and remediation status promptly.
• Evidence preservation. Require suppliers to preserve logs, indicators and forensic material and to maintain chain of custody.
• Remediation commitments. Set expectations for the timely provision of fixes or mitigations.
• Indemnities and liability. Allocate responsibility for losses arising from a supplier’s failure to report or remediate.

Evidence retention, documentation and forensic records

Because the CRA’s final-report windows extend beyond the initial notifications, and because enforcement authorities may later examine an incident, manufacturers should adopt disciplined retention practices. Preserve, for a defined and documented period aligned to the reporting cycle and any limitation considerations, the material that substantiates each report: system and application logs, indicators of compromise, forensic images, timelines, internal decision records and copies of the submissions themselves.

Good documentation practice includes recording the moment of awareness (which anchors the clocks), the reasoning behind threshold decisions, and the sequence of mitigations. Where forensic imaging is undertaken, follow a documented chain-of-custody procedure. Handle legally privileged material with care, keeping legal analysis separate from factual incident records so that the factual record can be shared with authorities without waiving privilege over legal advice. For manufacturers operating across borders, consider how evidence held in different jurisdictions, and any export-control sensitivities in the data, affect what can be shared and when.

Conclusion, next steps for Irish manufacturers and counsel

The eu cyber resilience act reporting obligations are coming into force from 11 September 2026, and readiness cannot wait for the 2027 substantive deadline. Irish manufacturers and counsel should take four immediate actions: confirm how to access and register for the ENISA single reporting platform and name responsible contacts; update the incident-response playbook to embed the 24-hour and 72-hour clocks; audit supplier contracts to flow down reporting and evidence-preservation duties; and build a product inventory that identifies which items fall within scope. Coordinating these steps with existing NIS2 and GDPR processes, and with the Data Protection Commission and National Cyber Security Centre in Ireland, will turn a demanding regime into a manageable, well-rehearsed routine.

This article is provided for information only and is not legal advice; complex or cross-border incidents warrant tailored guidance.

Sources

1. EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act)
2. European Commission, Cyber Resilience Act policy page
3. ENISA, official website
4. EUR-Lex, Directive (EU) 2022/2555 (NIS2)
5. EUR-Lex, Regulation (EU) 2016/679 (GDPR)
6. Data Protection Commission (Ireland)
7. National Cyber Security Centre (Ireland)