Cyber Resilience Act Reporting: The 24-Hour Playbook for September 2026

From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements must start a staged report through ENISA's Single Reporting Platform. The operational sequence is an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report after corrective measures are available.

This is an engineering playbook, not legal advice. It focuses on the reporting workflow that product teams must make executable before the first CRA obligations apply, rather than repeating a broad compliance summary.

What changes on 11 September 2026?

Checkpoint	Regulatory trigger	Engineering action
24 hours	Early warning after awareness of active exploitation	Open one report, preserve the awareness timestamp, affected markets, and initial severity
72 hours	Vulnerability notification	Add technical assessment, exploitation evidence, mitigations, and affected versions
Final report	No later than 14 days after a corrective or mitigating measure is available	Record root cause, remediation, rollout, and user communication

Who owns the reporting clock?

A single incident commander should own the clock, but the evidence must come from product, security, support, legal, and communications. Awareness is a business event, not merely the moment a CVE receives a number. Define who may declare awareness and record that decision in an append-only incident timeline.

Route researcher, customer, CSIRT, bug-bounty, monitoring, and supplier reports into one intake queue.
Store product identifiers, versions, countries, exploitation indicators, reporter contact, and first-observed time as structured fields.
Keep the same internal incident ID across the 24-hour, 72-hour, and final submissions.

What should the reporting architecture contain?

Build an evidence pipeline, not a form-filling ritual. The platform adapter should read from an incident record that remains useful when the external form or API changes. Separate verified facts from hypotheses, assign an owner to every unknown, and retain the submission receipt.

A tamper-evident timeline with UTC timestamps and actor identity.
A product and version inventory connected to SBOM, release, and support-period records.
A disclosure decision log, customer-notification draft, and redacted evidence bundle.
A rehearsal environment with a synthetic exploited-vulnerability scenario.

How do you avoid over-reporting and missed reports?

Use a two-gate triage. Gate one asks whether the issue affects a product with digital elements in scope. Gate two asks whether reliable information indicates active exploitation or a severe incident. Uncertainty does not justify silence: escalate it against the regulatory clock and document the basis for the decision.

Do not wait for perfect attribution, a public CVE, or a completed root-cause analysis before starting triage.
Do not expose unnecessary vulnerability detail in broadly visible channels.
Test absence coverage: weekends, staff leave, supplier notifications, and compromised monitoring.

A six-week CRA reporting implementation plan

Week 1: map products, manufacturers, importers, distributors, support periods, and accountable people.
Week 2: define awareness, severity, active exploitation, decision authority, and legal escalation.
Week 3: implement the incident schema, evidence store, access controls, and immutable audit trail.
Week 4: connect vulnerability intake, asset inventory, release data, and customer communication.
Week 5: rehearse the 24-hour and 72-hour handoffs with a realistic tabletop exercise.
Week 6: close gaps, approve the runbook, and schedule quarterly drills through December 2027.

Build the product, not just the backlog

If this article maps to a real product decision, Wavect can help you scope, build, harden, or lead the software work with senior founder-level judgment.

Talk through the product

Useful service paths:

Software QA

CRA reporting FAQ

When do CRA vulnerability-reporting duties start?

The Article 14 reporting obligations apply from 11 September 2026. Most other CRA obligations apply from 11 December 2027.

Does the 24-hour report require a finished root-cause analysis?

No. It is an early warning. Preserve known facts, clearly label uncertainty, and enrich the same report at the later checkpoints.

Where are reports submitted?

ENISA operates the CRA Single Reporting Platform. Manufacturers should prepare access, roles, and an internal evidence workflow before the duty starts.

Is a vulnerability scanner enough?

No. Scanners can supply signals, but scope, exploitation, awareness, market impact, remediation, and communication require an accountable cross-functional process.

Final thoughts

Treat the 24-hour deadline as an architecture constraint. A rehearsed evidence pipeline, explicit decision rights, and one durable incident record are more valuable than a last-minute reporting template.

Primary sources

European Commission CRA reporting page. Official dates and staged reporting overview
ENISA Single Reporting Platform. Official platform scope and readiness information
European Commission CRA guidance announcement. Final guidance published for the September 2026 reporting start