Practical field guide
CRA Article 14 reporting: what the 24-hour clock actually asks you to do
The reporting duty is a staged notification process for manufacturers of in-scope products with digital elements—not a demand to finish an incident investigation in one day.
The free field compiler runs in your browser. It does not upload the incident details you enter.
The trigger and the reporting route
From 11 September 2026, the CRA requires manufacturers to notify two event types: an actively exploited vulnerability contained in a product with digital elements, or an incident having a severe impact on the security of such a product. Reports are made once through ENISA’s Single Reporting Platform and addressed to the relevant CSIRT designated as coordinator. The official overview is maintained by the European Commission .
Reportability still needs fact-specific judgment. “Actively exploited” requires reliable evidence of malicious exploitation; a severe incident is assessed against its effect on product security. A normal vulnerability without evidence of active exploitation is not automatically the same trigger. Consult the current ENISA SRP FAQ and the Commission’s implementation guidance when deciding.
The three reporting stages
| Stage | Outer deadline | Purpose |
|---|---|---|
| Early warning | Within 24 hours of awareness | Identify the product, event type and known situation quickly. |
| Notification | Within 72 hours of awareness | Add an initial assessment, known technical facts and mitigation. |
| Final report | AEV: within 14 days after a corrective measure is available. Severe incident: within one month after the 72-hour notification. | Complete severity, impact, cause and response information. |
These are outer limits. The Regulation also says notifications are due “without undue delay.” The official timing is summarised by the European Commission and ENISA.
What the SRP asks for
ENISA’s SRP Glossary v1.1 , updated 5 September 2026, is the practical field map. Some fields are required immediately; others become required at 72 hours or in the final report; some are required only when information is available.
Product identity
Manufacturer, product name, affected version, countries of availability, component and optional CRA classification.
Event facts
Awareness time, summary, vulnerability or incident detail, impact, severity, attack vector and known identifiers.
Response
Measures already taken, user actions, expected mitigation, sensitivity and final remediation information.
Operational preparation before an incident
- 1Identify the legal manufacturer for each product and the CSIRT designated as coordinator.
- 2Name a primary and backup assigned representative with out-of-hours access.
- 3Make the awareness timestamp explicit in incident intake and preserve its evidence.
- 4Pre-map product names, versions, Member States and product owners.
- 5Prepare approved language for the early warning without waiting for a complete root-cause analysis.
- 6Dry-run the handoff among product security, engineering, legal, communications and management.
ENISA says the initial SRP release does not provide an API, although organisations may automate their internal evidence and approval workflows. Portal submission therefore remains a human-authorised step at launch. The SRP FAQ also notes that registration is designed to take only a few minutes for a representative who already has an EU Login account.
Five details to include in your reporting handoff
- Individual access. Each submitter needs their own EU Login with multi-factor authentication.
- Registration timing. Prepare EU Login in advance. ENISA recommends registering the manufacturer association when a notification is needed.
- Backup access. A Primary Assigned Representative can see all manufacturer notifications; a Secondary Representative can see only their own. Rehearse the handoff without assuming the backup can reopen the primary person’s report.
- Portal reminders. The initial SRP reminder counter uses 48 hours after the early warning. The legal 72-hour outer limit runs from awareness; keep that timestamp separately and report without undue delay.
- SRP outage. Retry when the portal returns. If immediate communication is necessary, contact the designated CSIRT. Direct contact does not replace the later SRP submission.
Checked 10 September 2026 against ENISA’s FAQ, questions 9, 25 and 26. Platform behaviour may change; check the current guidance before submitting.
Build the working packet now
Select the event type and reporting stage, fill only the information you know, then export Markdown or JSON. Your entries are not sent to this site.
Open the free compilerPreparing a team review? Inspect the 24h Dry Run and a sample action report.
Primary sources
- European Union, Regulation (EU) 2024/2847.
- European Commission, Cyber Resilience Act — Reporting obligations.
- ENISA, CRA Single Reporting Platform FAQ.
- ENISA, CRA SRP Glossary v1.1.
Last reviewed against official sources: 10 September 2026. This guide is an independent preparation aid, not legal advice, certification, a conformity assessment or an official filing channel.