Go back to the web Sign In

Incident Reporting

Track security incidents and meet ENISA notification deadlines required by CRA Article 14.

What must be reported

CRA requires manufacturers to report severe security incidents to ENISA. Reportable incidents include:

Incident type Examples
Active exploitation CVE being exploited in the wild
Severe impact Incidents affecting user security or product integrity
Supply chain compromise Build system breach, dependency hijacking

Note: Not every security issue requires ENISA notification. Report incidents that significantly impact product security or user safety.

Create an incident

  1. Navigate to Incidents from the main menu.
  2. Click Create Incident.
  3. Complete the form:
Field Description
Title Clear name (e.g., "CVE-2024-XXXX Active Exploitation")
Incident Type Vulnerability exploitation, malware, data breach, supply chain attack, DoS, or other
Severity Critical, High, Medium, Low, or Unknown
Cause Vulnerability exploitation, malware, config error, human error, third-party compromise, or under investigation
Detection details How and when you discovered the incident
  1. Click Save.

ENISA notification deadlines

When you create an incident, CRA Evidence calculates your mandatory ENISA deadlines per CRA Article 14(3).

Deadline Timeframe What to include
Early Warning 24 hours Basic info, affected products, suspected malicious activity, cross-border impact
Incident Notification 72 hours Updated info, severity assessment, indicators of compromise, initial remediation
Final Report 1 month Full description, root cause analysis, remediation measures, lessons learned

Record ENISA submissions

After submitting to ENISA's portal, record the submission in CRA Evidence:

  1. Open the incident.
  2. Click Send Early Warning, Send Incident Notification, or Send Final Report.
  3. The timestamp is logged for your records.

Warning: Deadlines are calculated from when you became aware of the incident. Late notification is better than none—record your submission even if overdue.

Deadline status indicators

The incident detail page shows countdown timers with status:

Colour Meaning
Green Deadline not yet reached
Yellow Within 6 hours of deadline
Red Deadline overdue

Incident lifecycle

Advance incidents through stages using the status dropdown:

Stage Description
Detected Initial creation
Confirmed Verified as real incident
Contained Immediate threat neutralised
Eradicated Root cause removed
Recovered Normal operations restored
Lessons Learned Post-incident review completed
Closed Incident fully resolved

Note: Each status change is logged with timestamp and user.

  1. Open the incident detail page.
  2. Click Add Affected Products.
  3. Select the product versions impacted.

This ensures your technical file reflects the incident history.

Dashboard alerts

If you have overdue ENISA notifications, an alert banner appears on your main dashboard. Click it to see all overdue incidents.

Export incident records

Incident data is included in technical file exports:

  • Incident timeline and status history
  • ENISA notification timestamps
  • Affected products
  • Remediation actions

This provides auditable evidence of your vulnerability handling per CRA Article 11.

Best practices

Practice Why it matters
Define clear criteria Document what constitutes a reportable incident so decisions are consistent
Prepare templates Draft ENISA notification templates before incidents occur
Practice response Run tabletop exercises; know who has authority for notifications
Document in real-time Live notes are more reliable than reconstructed timelines
Coordinate internally Involve security, legal, and communications teams early

ENISA Single Reporting Platform

ENISA's single reporting platform launches in September 2026. CRA Evidence will support direct submission when available. Until then, submit through ENISA's web portal and record the submission here.

Last updated February 27, 2026
Was this page helpful?
Thanks for your feedback!

Help us improve. What was missing or unclear?