Independent information resource Product security · EU CRA
CRA reporting / 04

Understanding the CRA 24-Hour Early Warning

Understand the Cyber Resilience Act 24-hour early-warning requirement for actively exploited vulnerabilities and severe incidents, including timing, minimum information and manufacturer awareness.

IN BRIEF

The 24-hour requirement is an early-warning deadline, not a deadline for completing root-cause analysis. Manufacturers need rapid triage, a recorded awareness time, an authorised SRP reporting path and enough verified information to submit the applicable preliminary notification without undue delay.

01 / 08

The 24-Hour Stage Is an Early Warning

Article 14 deliberately structures reporting in stages. The first stage is an early warning submitted without undue delay and in any event within 24 hours of the manufacturer becoming aware of the qualifying event. This wording matters because 24 hours is an outer limit, not a target that automatically permits the manufacturer to wait until the final hour. At the same time, the early-warning stage does not require the organisation to complete the entire technical investigation. The purpose is rapid regulatory awareness while the manufacturer continues to validate scope, analyse root cause, prepare mitigation and gather the information required for the later notification stages.

  • Submit without undue delay.
  • Do not exceed 24 hours after awareness.
  • Continue the technical investigation after submission.
  • Do not wait for the final root-cause report before filing the early warning.
02 / 08

The Clock Runs From Manufacturer Awareness

For both actively exploited vulnerabilities and severe incidents, Article 14 measures the 24-hour period from the manufacturer becoming aware of the qualifying event. That makes awareness handling an operational compliance issue. Security information can enter an organisation through researchers, customers, suppliers, threat intelligence, monitoring systems, incident responders or public reporting. Teams need a defined route for deciding when the available information establishes the Article 14 trigger and for recording that point in time. Without that process, organisations can lose hours while information remains inside a product team or support queue before reaching the person responsible for CRA reporting.

  • Capture when potentially relevant information is received.
  • Escalate credible Article 14 signals quickly.
  • Record when the manufacturer is considered aware of the qualifying event.
  • Calculate the deadline immediately from the recorded awareness time.
03 / 08

The AEV Early Warning Identifies Relevant Member States Where Applicable

For an actively exploited vulnerability, Article 14(2)(a) requires the early warning and states that the manufacturer should indicate, where applicable, the Member States on whose territory it is aware that the affected product with digital elements has been made available. The manufacturer may not possess perfect distribution information during the first hours of an event, particularly where products move through complex channels. The requirement therefore needs to be connected to existing market, sales and distribution records. Product-security reporting teams should know how to obtain relevant availability information without creating a lengthy cross-company search that delays the early warning.

  • Identify the affected product.
  • Use available market and distribution information.
  • Indicate relevant Member States where applicable.
  • Do not delay the entire warning while attempting to create perfect distribution data.
04 / 08

The Severe-Incident Early Warning Includes a Cause Assessment

The severe-incident early warning contains an additional minimum element. Article 14(4)(a) requires it to include at least whether the incident is suspected of being caused by unlawful or malicious acts. This does not require final threat attribution within 24 hours. The organisation may still be analysing whether the event resulted from deliberate hostile activity, accidental behaviour, product failure or another cause. The early-warning record should therefore reflect the evidence available at that stage and distinguish a preliminary suspicion from a final conclusion. ENISA's SRP guidance supports an operational field for this assessment.

  • Assess whether unlawful or malicious acts are suspected.
  • Base the preliminary assessment on available evidence.
  • Do not present preliminary suspicion as confirmed attribution.
  • Update the record as the investigation develops.
05 / 08

The Early Warning Does Not Need the Whole 72-Hour Dataset

The 24-hour warning and 72-hour notification are separate stages because the Regulation expects more information to become available as the investigation progresses. The 72-hour vulnerability notification includes general information about the product, exploit and vulnerability, along with corrective or mitigating measures. The 72-hour severe-incident notification includes general information about the incident and an initial assessment. Manufacturers should therefore resist two opposite mistakes: delaying the early warning until all 72-hour information is complete, or assuming the 24-hour submission ends the regulatory task. The early warning begins a reporting sequence that must continue to the later stages.

  • Do not delay the early warning for information intended for the 72-hour stage.
  • Do not treat early-warning submission as completion of Article 14 reporting.
  • Continue investigation immediately after the early warning.
  • Prepare the 72-hour notification in parallel.
06 / 08

Submit Through the Single Reporting Platform

Article 14 notifications are submitted through the Single Reporting Platform established under Article 16. ENISA operates the SRP, and the platform became operational on 11 September 2026 when the manufacturer reporting obligations became applicable. The reporter selects the relevant CSIRT designated as coordinator as part of the submission workflow. This makes platform readiness part of 24-hour readiness. The organisation should know which assigned representative can submit, whether that account is active and how the relevant manufacturer and products are represented in the process before a real event starts the clock.

  • Maintain active SRP access.
  • Identify authorised assigned representatives.
  • Prepare manufacturer information before an emergency.
  • Know how the relevant CSIRT designated as coordinator will be selected.
  • Test the reporting path before a real 24-hour deadline.
07 / 08

A 24-Hour Workflow Needs Fast Internal Escalation

A reporting process that requires multiple sequential approvals can consume the available time before anyone reaches the SRP. A better workflow identifies a small decision group with access to product-security evidence, legal interpretation and submission authority. The technical team should provide the affected product, known versions, evidence supporting the trigger, current scope and mitigation status. The reporting owner should record the awareness time and deadline, determine which Article 14 path applies, prepare the minimum early-warning information and maintain contact with the incident team. Additional executives or specialists can be informed without turning every notification into a lengthy approval chain.

  • Define the Article 14 decision owner.
  • Define the SRP submission owner.
  • Create an urgent escalation channel.
  • Record the awareness timestamp and calculated deadline.
  • Allow technical investigation and regulatory reporting to proceed in parallel.
08 / 08

Test the 24-Hour Process Before You Need It

A tabletop exercise can reveal whether the organisation can actually perform the required steps within the reporting window. The scenario should begin with a realistic vulnerability or incident signal and require the team to identify the affected product, assess the Article 14 trigger, determine the manufacturer awareness time, select the reporting path, access the SRP and prepare the early warning. The exercise should also test handovers outside normal business hours because a qualifying event can become known at any time. The most useful outcome is a short list of operational blockers that can be fixed before the next real security event.

  • Test after-hours escalation.
  • Test SRP account access.
  • Test product and version identification.
  • Test awareness-time recording.
  • Test legal-trigger assessment.
  • Test transition from the 24-hour warning to the 72-hour notification.
REFERENCE DESK

Official sources

Read the full legal text and Commission material for precise wording, qualifications and updates.

Editorial review: 26 September 2026. Regulatory material can change; follow the official sources for current guidance.