CRA reporting deadlines

CRA reporting deadlines: 24h, 72h, 14 days, and one month

CRA reporting is a clock-driven workflow. When an actively exploited vulnerability or severe incident triggers the regulation, teams need fast triage, clear ownership, structured facts, and defensible evidence for each deadline.

Reviewed 2026-07-25Editorial owner: Cramio compliance team
24 hours
Early warning after the manufacturer becomes aware
72 hours
Full notification with available assessment information
14 days / 1 month
Final-report windows differ by notification type
Operating model

From obligation to auditable execution

1

Detect and establish awareness

Timestamp the signal, affected product, evidence, and the decision that a CRA threshold may be met.

2

Triage the legal trigger

Distinguish active exploitation from a severe security incident and involve PSIRT, product, legal, and executive owners.

3

Prepare and approve

Build the minimum accurate filing, apply maker-checker review, and retain the approved snapshot.

4

File and close the loop

An authorised person files through the SRP, records the receipt, and drives updates, remediation, and the final report.

01

24-hour early warning

The 24-hour early warning is the first high-pressure CRA reporting milestone. Teams need to identify whether the vulnerability or incident is in scope, determine exploitation status, capture affected products, and prepare the minimum required facts without waiting for perfect information.

  • Track discovery time and awareness time as evidence.
  • Link the report to affected products, SBOMs, versions, and vulnerability identifiers.
  • Keep the early warning narrow, factual, and auditable.
Control outcomeThe early warning can be reconstructed from an immutable awareness timestamp, trigger assessment, affected-product set, approver, and filed copy.
02

72-hour full notification

The 72-hour full notification expands the facts available at early warning. Teams should add technical analysis, impact assessment, remediation status, supply chain context, and any available mitigation or patch timeline.

  • Assign owner, reviewer, and approver roles before the deadline begins.
  • Use prebuilt fields so PSIRT, product, and legal teams do not invent the process during an incident.
  • Keep the notification linked to tamper-evident internal evidence.
Control outcomeThe 72-hour submission adds reliable technical and impact facts without silently overwriting what was known at 24 hours.
03

Final reports: 14 days or one month

For an actively exploited vulnerability, the final report is 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 initial notification. It should document root cause, remediation, impact, affected products, and corrective action.

  • Preserve decisions, timestamps, report drafts, and submission receipts.
  • Record whether affected components are fixed, mitigated, not affected, or still under investigation.
  • Connect final reports to product lifecycle and conformity evidence.
Control outcomeFinal reporting closes the regulatory record while remaining linked to engineering remediation and customer communication evidence.
04

Design for uncertainty and escalation

Short deadlines mean the initial picture will often be incomplete. A defensible process separates confirmed facts, working hypotheses, and unknowns, then assigns explicit follow-up owners. It also defines who can declare awareness, approve a filing, and invoke executive escalation outside business hours.

  • Use an on-call matrix with named alternates for PSIRT, legal, product, privacy, and communications.
  • Define clock warnings, overdue escalation, and a manual contingency if an internal integration is unavailable.
  • Run tabletop exercises with realistic incomplete data and preserve evidence of lessons learned.
Control outcomeReporting remains controlled during nights, weekends, staff absences, vendor outages, and fast-moving investigations.

Common questions

When do CRA reporting obligations begin?

CRA reporting obligations begin on 11 September 2026. Full CRA application follows on 11 December 2027.

What triggers the 24-hour CRA clock?

The reporting clock is triggered when an in-scope actively exploited vulnerability or severe incident becomes reportable under the CRA and the manufacturer becomes aware of it.

How does cramio help with CRA reporting deadlines?

cramio connects product inventory, SBOMs, CVEs, incidents, timers, report preparation, and evidence records so teams can manage 24-hour, 72-hour, and 14-day reporting workflows in one place.

Must the first report contain every technical detail?

No. The early warning is time-critical and uses the information available at that stage. Teams should remain factual, identify unknowns, and enrich the record through the 72-hour notification and final report.

Primary sources

This educational material supports operational readiness and is not legal advice. Customers remain responsible for determining how the CRA applies to their products and obligations.