Under the Cyber Resilience Act (Regulation (EU) 2024/2847), manufacturers of products with digital elements must submit an early warning to ENISA and the relevant CSIRT within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident – an obligation that applies from 11 September 2026. Meeting this deadline requires a pre-built internal process, clear ownership of the notification function, and an accurate understanding of what information the regulator expects at each stage. This guide walks through the procedure step by step so that manufacturers, importers and authorised representatives operating in the EU can plan ahead with confidence.
Legal Basis and Scope
The Cyber Resilience Act – formally Regulation (EU) 2024/2847 – establishes horizontal cybersecurity requirements for hardware and software placed on the EU market. Its reporting regime sits within a broader architecture that also includes the NIS2 Directive and, for certain sectors, the Digital Operational Resilience Act (DORA). Where those instruments overlap, manufacturers must identify which obligation is more specific and comply with both sets of requirements where they run in parallel.
The Act distinguishes between actively exploited vulnerabilities – security weaknesses that threat actors are already using – and severe incidents that have a significant impact on the security of a product with digital elements. Both trigger the 24-hour early-warning clock. A notification to ENISA (the EU Agency for Cybersecurity) and the competent national CSIRT (Computer Security Incident Response Team) must be submitted within that window, regardless of whether a fix is yet available.
Full product-safety and conformity-assessment requirements under the Act apply from 11 December 2027. However, the reporting obligations come into force earlier – on 11 September 2026 – meaning manufacturers have a compressed window to prepare incident-response procedures without necessarily having completed the full conformity pathway.
Foreign manufacturers who place products on the EU market through an authorised representative should clarify, in their contractual arrangements, which entity bears primary responsibility for submitting notifications. Leaving this undefined is one of the most common errors seen in cross-border engagements.
What Triggers the 24-Hour Clock
The clock starts when the manufacturer becomes aware of either an actively exploited vulnerability or a severe incident. "Awareness" is not defined by reference to a formal internal escalation; regulators and national authorities are likely to interpret it as the moment any part of the organisation has credible information that a triggering event has occurred. Manufacturers should therefore establish a clear internal definition of awareness and document when and how that threshold was reached in each case.
Key questions to assess at the moment of potential awareness include:
- Is the affected product a "product with digital elements" within the scope of the Act?
- Is the vulnerability currently being exploited in the wild, or is it merely disclosed?
- Does the incident meet the threshold of "severe" as understood under the Act?
- Has the product already been placed on the EU market, or is it still in the development phase?
- Is there a parallel NIS2 or sector-specific obligation that also requires notification?
If the answer to the first three questions is yes, the 24-hour window is open. Internal legal review should not be used as a reason to delay notification; the early warning can be preliminary and updated in subsequent reports.
Step-by-Step Procedure
Step 1 – Detect and Confirm the Triggering Event (Hour 0)
The process begins the moment a credible signal of an actively exploited vulnerability or severe incident reaches the organisation. This may come from a threat-intelligence feed, a customer report, a security researcher, an automated monitoring system, or an internal quality alert. The person or team receiving the signal should immediately escalate to the designated Incident Response Owner, whose contact details and authority should be documented in advance in the manufacturer's security policy.
Step 2 – Activate the Incident Response Protocol (Hours 0–2)
The Incident Response Owner convenes the core team, which should include representatives from information security, legal/compliance, product management, and – where the product is regulated under additional frameworks such as the AI Act – any appointed AI compliance officer. The team's first task is to confirm that the event meets the triggering criteria under the Act. This confirmation should be recorded in writing, with a timestamp, for regulatory documentation purposes.
Manufacturers developing or deploying systems that may also qualify as high-risk AI systems under the AI Act should cross-check whether the incident triggers parallel reporting obligations to the AI Office or relevant market surveillance authorities. Convergence of obligations is becoming more common as AI-enabled products with digital elements proliferate.
Step 3 – Prepare the Early Warning Notification (Hours 2–20)
ENISA operates a dedicated reporting channel for Cyber Resilience Act notifications. At the early-warning stage, the submission need not be complete, but it must include sufficient information for the authority to assess severity and consider whether coordinated action is warranted. Typical content at this stage includes:
- Identification of the manufacturer and the product (name, version, category).
- A factual description of the vulnerability or incident without speculation about cause.
- An indication of whether exploitation is confirmed or suspected.
- The geographic scope of affected users or deployments, to the extent known.
- Any immediate containment measures already taken.
- The name and contact details of the person responsible for follow-up.
The submission should be reviewed by legal counsel before dispatch, but this review must not extend the timeline beyond the 24-hour window. Organisations that build pre-approved notification templates reduce the risk of delay under pressure.
Step 4 – Submit to ENISA and the Competent CSIRT (By Hour 24)
The early warning must reach both ENISA and the relevant national CSIRT before the 24-hour deadline expires. Where a product is distributed across multiple Member States, manufacturers should identify which national CSIRT is the primary recipient – this is typically determined by the location of the manufacturer's EU establishment or, for third-country manufacturers, the location of the authorised representative. The Act provides that the notification submission system will be coordinated, but until technical implementation details are confirmed by ENISA, manufacturers should establish direct communication channels with national CSIRTs in their principal markets as a precautionary measure.
Retain timestamped evidence of submission, including delivery confirmations, in a secure record-keeping system. These records will be essential in any supervisory review or enforcement proceeding.
Step 5 – Submit the Detailed Notification (Within the Regulated Follow-Up Period)
Following the early warning, the Act requires a more detailed notification. The timeframe for this follow-up report is set by the Act and by any implementing technical standards that ENISA and the European Commission may issue before the September 2026 application date. Manufacturers should monitor EUR-Lex and ENISA guidance closely, as these standards will define the precise content requirements and may impose sector-specific variations. Allocate dedicated resources to prepare the detailed report in parallel with incident remediation, rather than sequentially.
Step 6 – Issue a Final Report After Remediation
Once the vulnerability is remediated or the incident is resolved, a final report must be submitted. This document should describe the root cause analysis, the remediation steps taken, any updates or patches provided to users, and the measures implemented to prevent recurrence. Where the incident involved a supply-chain component, the report should address the manufacturer's assessment of third-party risk and any contractual or technical controls strengthened as a result.
Documents to Prepare Before September 2026
Building the notification infrastructure before the obligation applies is far less costly than constructing it under time pressure after an incident occurs. The following documents form the minimum preparatory set:
- Incident Response Policy – defines triggering thresholds, internal escalation paths and the Incident Response Owner role.
- Notification Templates – pre-approved early-warning and detailed-report templates, reviewed by legal counsel.
- CSIRT Contact Register – a live list of relevant national CSIRT contact details and submission portals for each EU market in which the product is active.
- Authorised Representative Agreement – for third-country manufacturers, a written agreement that clearly assigns notification responsibility and obliges the representative to act within the 24-hour window.
- Training Records – documentation that staff with triggering-detection roles have received training on the Act's requirements.
- Cross-Framework Checklist – a matrix identifying products that also fall under NIS2, DORA, the AI Act, or sector-specific rules, so that parallel obligations are identified at the moment of awareness.
Realistic Timelines for Preparation
Organisations that have not yet begun preparation face a narrowing window. As of mid-2025, a well-resourced manufacturer with an existing information-security function can typically complete the core preparatory work within three to six months. Organisations starting from a low baseline, or those with complex product portfolios spanning multiple regulatory categories, should allow longer. Waiting until late 2026 to begin creates material enforcement risk, because the obligation applies from 11 September 2026 regardless of readiness.
Implementers should also factor in the time required to engage with authorised representatives, update commercial agreements, and brief board-level governance structures. Where products also qualify as high-risk AI systems, the AI Office and the European Commission's implementing acts under the AI Act will generate additional procedural requirements that intersect with the Cyber Resilience Act timeline.
Cost Drivers
The primary cost drivers in Cyber Resilience Act 24-hour reporting compliance are organisational rather than technical. Legal review of notification templates, gap analysis of existing incident-response procedures, and the drafting or updating of authorised representative agreements account for a significant share of the work. Technology costs – typically centred on logging infrastructure, monitoring tools, and secure document management – vary considerably by organisation size and existing capability. Manufacturers should budget separately for ongoing costs: the obligation applies each time a triggering event occurs, so the per-incident legal and operational cost is a recurring variable rather than a one-time investment.
Common Errors by Foreign Manufacturers
International manufacturers entering the EU market frequently encounter the same set of avoidable pitfalls:
- Treating the 24-hour deadline as a target rather than a hard limit. Internal approval chains designed for commercial contracts are ill-suited to regulatory notifications under time pressure.
- Conflating the early warning with the detailed notification. The early warning does not need to be complete; waiting for a complete picture before submitting will breach the deadline.
- Assuming that NIS2 compliance covers the obligation. The Cyber Resilience Act reporting obligation is separate and applies to manufacturers of products, not only to operators of essential services.
- Leaving notification responsibility undefined in authorised representative contracts. In an enforcement scenario, ambiguity about who was responsible for submission is unlikely to be treated as a mitigating factor.
- Failing to account for algorithmic transparency requirements where AI-enabled products also engage obligations under the AI Act, creating parallel disclosure duties that must be managed simultaneously.
- Overlooking the interaction with employment law – particularly where incident-response roles involve monitoring of employee activity or processing of employee personal data. Manufacturers should review employment law implications as part of their incident-response design.
Decision Checklist
Use the following checklist when assessing whether a potential event requires immediate action under the Act:
- Does the affected product have digital elements and fall within the scope of Regulation (EU) 2024/2847?
- Has the manufacturer, importer, or authorised representative placed or is it about to place the product on the EU market?
- Is the date on or after 11 September 2026?
- Is there credible evidence of active exploitation of a vulnerability, or of a severe incident?
- Has the 24-hour clock been confirmed as running, and is the submission deadline logged?
- Has a designated individual been assigned to prepare and submit the early warning?
- Have parallel obligations under NIS2, DORA, the AI Act, or sector-specific rules been assessed?
- Has legal counsel been briefed and given adequate – but not excessive – time to review the draft notification?
- Has submission been made to both ENISA and the competent national CSIRT, with timestamped evidence retained?
If your organisation is working through this checklist for the first time, or if you have identified gaps in your current incident-response framework, we would be glad to discuss the specifics of your situation. Please reach out to our team at info@ferrazwhitmore.com or visit our contacts page.
Interaction with the AI Act and Broader Digital Regulation
Products that incorporate AI components and qualify as products with digital elements may simultaneously engage obligations under both the Cyber Resilience Act and the AI Act. Where a product is classified as a high-risk AI system, the manufacturer must also comply with the AI Act's requirements on post-market monitoring and serious-incident reporting to national market surveillance authorities. ESMA and EBA have issued guidance indicating that financial-sector operators should expect these obligations to layer with existing sectoral requirements under DORA.
The AI Office, established under the AI Act, is expected to play a coordinating role in incidents involving general-purpose AI models where those models are embedded in products subject to the Cyber Resilience Act. Manufacturers of such products should monitor guidance from the AI Office and the European Commission as implementing measures are adopted. EUR-Lex remains the authoritative source for the text of both regulations and any delegated or implementing acts issued under them.
Our firm's digital law practice covers both the Cyber Resilience Act and the AI Act as integrated compliance matters. If your product portfolio raises questions about where one obligation ends and another begins, you are welcome to contact us at info@ferrazwhitmore.com for an initial discussion. Further information on our approach to AI regulation is available at our AI law services page.
Staying Current as Implementing Measures Develop
The Cyber Resilience Act is a framework regulation: many of the technical and procedural details that manufacturers will need in practice – including the precise format and content requirements for ENISA notifications, the technical standards for vulnerability handling, and the criteria for assessing incident severity – will be set out in implementing acts, delegated acts, and ENISA guidance that have not yet been finalised. Organisations should assign a dedicated regulatory monitoring function to track developments on EUR-Lex, the ENISA website, and the European Commission's digital policy pages between now and September 2026.
We publish updates on significant regulatory developments, including proposed changes to the EU digital compliance framework, through our digital regulatory alerts. Subscribing to these alerts is a straightforward way to ensure that your compliance calendar remains aligned with the actual legislative timetable.
If you would like to discuss how the Cyber Resilience Act reporting obligations apply to your specific products or market position, please contact our team at info@ferrazwhitmore.com or visit our contacts page to arrange a conversation.
Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. Ferraz & Whitmore assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@ferrazwhitmore.com.