CRA Article 14: ENISA Vulnerability Reporting Explained

The Three-Stage Reporting Chain

Article 14 of the CRA establishes a mandatory three-stage vulnerability reporting process. When a manufacturer becomes aware that a vulnerability in one of their products is being actively exploited, they must:

Where Do You Report?

Reports are submitted to ENISA (European Union Agency for Cybersecurity) through the Single Reporting Platform (SRP). The SRP must be operational by September 11, 2026.

ENISA shares relevant information with the national CSIRTs (Computer Security Incident Response Teams) of affected EU member states. The CSIRT of the country where the manufacturer is established is the primary contact point.

What Triggers a Report?

A report is required when two conditions are met simultaneously:

• -A vulnerability exists in your product with digital elements
• -That vulnerability is actively exploited — meaning attackers are using it in the real world

The clock starts when you become aware. If a CVE is published at 2 AM and your monitoring system detects it at 2:15 AM, your 24-hour deadline is 2:15 AM the next day.

What Must the Report Contain?

The early warning (24h) must include:

• -Product name and version affected
• -Nature of the vulnerability
• -Whether exploitation is believed to be occurring
• -Initial assessment of severity

The full notification (72h) must add:

• -Technical details of the vulnerability
• -Number of products and users potentially affected
• -Geographic scope across EU member states
• -Mitigation measures taken or recommended
• -Whether a patch is available or expected

The final report (14d) must add:

• -Root cause analysis
• -Complete timeline of events
• -Corrective actions applied (patch, workaround, removal)
• -Whether users were notified (CRA Article 14(8))
• -Lessons learned and preventive measures

User Notification Obligation (Article 14(8))

Separate from the ENISA report, Article 14(8) requires manufacturers to notify affected users about the vulnerability and any corrective measures they should take. This notification must be made without undue delay.

This means you need a way to reach your customers — whether by email, security advisory, in-app notification, or website notice. You also need to document that you made this notification, as it becomes part of the final report evidence.

Why This Is Operationally Challenging

The 24-hour deadline is the core challenge. When a vulnerability is disclosed at any hour of any day, you need to:

• -Detect that it affects your product (requires SBOM + monitoring infrastructure)
• -Assess the severity and impact (requires understanding your product architecture)
• -Determine if it is actively exploited (requires threat intelligence)
• -Draft and submit the ENISA early warning (requires a reporting workflow)
• -Begin user notification (requires customer contact infrastructure)

All of this within 24 hours. For a company with 10+ products across hundreds of software components, doing this manually is not realistic.

How Lexoreg Automates Article 14

• -CVE monitoring every 2 hours — we check NVD, OSV, CISA KEV, and EUVD automatically
• -Automatic SBOM matching — when a new CVE is published, we check it against every component in every product
• -KEV detection — we flag actively exploited vulnerabilities immediately
• -ENISA report auto-drafting — the early warning report is pre-filled with your product data, vulnerability details, and severity assessment
• -Deadline tracking — live countdown timer shows exactly how much time you have left
• -Follow-up chain — 72h notification and 14d final report are linked to the original early warning
• -User notification records — track what you communicated, to whom, and when
• -Audit trail — every action is logged for regulatory evidence