In this piece
Cyber Resilience Act Reporting: The 24/72-Hour Operational Playbook
As of 5 October 2026, CRA manufacturer reporting duties are already in force. Actively exploited vulnerabilities and severe incidents require an early warning within 24 hours and a notification within 72 hours of awareness. Final deadlines differ: 14 days after a corrective measure is available for vulnerabilities, but one month from the 72-hour notification for severe incidents.
The manufacturer reporting duties have applied since 11 September 2026. This engineering playbook turns them into an operating process, not a future readiness project. It is not legal advice: confirm the product scope, economic-operator role and reporting trigger with qualified counsel. The implementation recommendations below are not additional statutory requirements.
Which clock applies to which report?
| Checkpoint | Trigger and deadline | Operational evidence |
|---|---|---|
| Early warning: both categories | Within 24 hours of becoming aware | Preserve the awareness timestamp, report category, initial facts and submission receipt. |
| Notification: both categories | Within 72 hours of becoming aware, not 72 hours after the early warning | Extend the incident record with affected products, assessment and available measures. |
| Final: actively exploited vulnerability | No later than 14 days after a corrective measure is available | Record when the measure became available, remediation details and the final submission. |
| Final: severe incident | Within one month from the 72-hour notification | Preserve that notification timestamp, the calendar-month deadline and the final incident assessment. |
Who owns awareness and escalation?
Assign an accountable incident lead and an available deputy. Awareness must not be artificially postponed until a manager approves a ticket or a CVE is published. Record what was known, by whom and when; escalate uncertainty about the legal trigger without waiting for perfect attribution.
- Route researcher, customer, supplier, CSIRT and monitoring reports into one intake process.
- Distinguish first observation, organisational awareness, internal escalation and each external submission. Store UTC timestamps with their evidence.
- Separate scope and trigger assessment: a scanner finding is not automatically an actively exploited vulnerability or a severe incident. Document the decision and its owner.
What belongs in the incident record?
Use one durable incident ID for the staged submissions. Keep confirmed facts separate from assumptions and assign every material unknown an owner. The following schema is a recommended engineering control, not a claim that every field is mandatory in the external form.
- Record product and affected version, manufacturer role, countries, category, exploitation or severity evidence, awareness time and the two initial deadlines.
- For vulnerabilities, record the corrective-measure availability time. For severe incidents, record the 72-hour notification time. Calculate the appropriate final deadline from that separate field.
- Retain source evidence, assessment revisions, responsible people, mitigation and rollout decisions, communication records, submitted payloads and receipts.
- Restrict sensitive exploit details and personal data. Define access, proportionate retention and a redacted collaboration view.
Where do teams submit and how should they rehearse?
ENISA’s Single Reporting Platform has been operational since 11 September 2026. Use the official access and user guidance rather than assuming a public submission API exists. Prepare authorised access and deputies now; keep the internal evidence record independent of the external form.
- Verify access, responsibilities and the applicable CSIRT route using the official platform guidance.
- Run two internal tabletop scenarios: one exploited vulnerability and one severe incident. Do not submit synthetic incidents to a live reporting channel.
- Test weekend and absence coverage, lost platform access, supplier delays and preservation of submission receipts.
Operational readiness checks to complete now
- Confirm in-scope products, manufacturer responsibilities, the incident lead and deputy.
- Verify official platform access and maintain the current reporting instructions in the incident runbook.
- Implement awareness timestamps and independent 24-hour, 72-hour and category-specific final deadline tracking.
- Connect intake to product, release and remediation records; test access controls and evidence retrieval.
- Rehearse both report categories, close the observed gaps and schedule recurring drills. A remediation project does not suspend a reporting deadline.
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.
Useful service paths:
CRA reporting FAQ
Are the manufacturer reporting duties already applicable?
Do the 24-hour and 72-hour deadlines run consecutively?
Is every final report due within 14 days?
Do open-source software stewards have the same start date?
Do we need complete root-cause analysis for the early warning?
Is this a legal compliance certification?
Final thoughts
The immediate task is reliable execution: one evidence record, an accountable deputy-backed owner and different final-deadline rules for the two report categories. Keep reporting, remediation and customer communication connected without waiting for a perfect post-mortem.
Primary sources
- European Commission: CRA reporting obligations. Manufacturer and steward dates; both report categories and their deadlines
- ENISA: Single Reporting Platform. Official access, user guidance and reporting resources
- European Commission: CRA application guidance. Scope and implementation guidance; consult the current reporting section