ENISA Vulnerability Reporting Under the CRA: Timelines, Templates, and Process

Starting September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities to ENISA within 24 hours. This is the first hard deadline under the EU Cyber Resilience Act, and many organizations are unprepared for the speed and specificity it demands.

This guide covers exactly when reporting is triggered, what each stage requires, and how to prepare your team before the deadline hits.

When Is Reporting Triggered?

CRA vulnerability reporting under Article 14 of Regulation 2024/2847 is triggered when a manufacturer becomes aware of an actively exploited vulnerability in their product. Not any vulnerability — specifically one that is being exploited in the wild.

Key distinctions:

• Known vulnerability without active exploitation: no ENISA reporting required (though you must still handle it under your vulnerability management process)
• Actively exploited vulnerability: ENISA reporting required within 24 hours of becoming aware
• Severe incident affecting product security: also triggers reporting obligations

The clock starts when the manufacturer becomes aware of the active exploitation — not when the CVE was first published, and not when the vulnerability was first discovered. Awareness is the trigger.

Practically, this means you need continuous monitoring of exploitation intelligence sources, particularly the CISA Known Exploited Vulnerabilities (KEV) catalog, security vendor advisories, and threat intelligence feeds.

The Three Reporting Stages

Stage 1: Early Warning — Within 24 Hours

The initial report must be submitted within 24 hours of becoming aware that a vulnerability in your product is actively exploited. This is an early warning, not a full analysis.

What it must include:

• Indication that you suspect or have confirmed an actively exploited vulnerability
• Preliminary information about the affected product(s)
• Preliminary assessment of whether the vulnerability potentially affects other manufacturers
• Whether you suspect the exploitation is malicious or non-malicious

What it does not need: root cause analysis, complete impact assessment, or a fix. The purpose is to alert ENISA quickly so they can coordinate if needed.

Stage 2: Vulnerability Notification — Within 72 Hours

Within 72 hours of the initial awareness, submit a more detailed notification.

What it must include:

• General description of the vulnerability and its nature
• Initial assessment of severity, including potential impact
• Corrective measures taken or planned
• Where known, information about whether the vulnerability may affect products from other manufacturers
• Any initial assessment of cross-border impact

Stage 3: Final Report — Within 14 Days

Within 14 days, submit a comprehensive final report.

What it must include:

• Detailed description of the vulnerability, including root cause where possible
• Severity and impact assessment
• Complete list of affected products and versions
• Information about the exploitation activity (scope, attribution if known)
• All corrective measures applied
• Information provided to affected users
• Where applicable, measures to prevent similar vulnerabilities

The ENISA Single Reporting Platform

ENISA is establishing a single reporting platform where manufacturers will submit their vulnerability reports. The platform will serve as the central intake point for all CRA-related vulnerability notifications across the EU.

Reports submitted to ENISA will be shared with the relevant Computer Security Incident Response Teams (CSIRTs) of the member states where the manufacturer is established and where the product is available. ENISA may also notify other CSIRTs if the vulnerability has cross-border implications.

The exact interface and submission format for the platform are still being finalized, but manufacturers should prepare their internal systems to produce reports matching the content requirements above on short notice.

Who Submits the Reports?

The manufacturer is responsible for ENISA reporting. If you are an importer or distributor and become aware of an actively exploited vulnerability, you must inform the manufacturer immediately so they can fulfill their reporting obligation.

Open source stewards also have reporting obligations for vulnerabilities discovered in the projects they support, following the same timeline.

How to Prepare Before September 2026

1. Set Up Exploitation Monitoring

You need to know within hours — not days — when a vulnerability in your dependencies is being actively exploited. Monitor:

• CISA KEV catalog (updated frequently, most reliable signal for active exploitation)
• OSV.dev and GitHub Security Advisories for vulnerability intelligence
• Vendor security bulletins for commercial components

2. Assign Responsibilities

Name the specific people responsible for each stage. The 24-hour window leaves no room for ambiguity about who drafts, reviews, and submits the early warning. Document backup coverage for weekends and holidays.

3. Prepare Report Templates

Pre-fill everything you can: company information, product portfolio, standard boilerplate. During an incident, your team should only need to fill in the vulnerability-specific details.

4. Run a Drill

Before September 2026, simulate an active exploitation scenario end-to-end:

1. Pick a real CVE from the CISA KEV list that affects one of your dependencies
2. Start the 24-hour clock
3. Draft and review the early warning
4. Draft the 72-hour notification
5. Identify every point where the process slowed down or broke

Fix the bottlenecks. Then run the drill again.

Common Mistakes to Avoid

• Waiting for a full analysis before the 24-hour report. The early warning is intentionally low-detail. Send what you know, then follow up.
• Not monitoring for active exploitation. Knowing about a CVE is not the same as knowing it is being exploited. You need exploitation intelligence, not just vulnerability feeds.
• No weekend or holiday coverage. Active exploitation does not wait for business hours. The 24-hour clock runs continuously.
• Assuming your security vendor handles it. The reporting obligation is on the manufacturer. Your tools can help detect, but the report is your responsibility.

For a full preparation plan, see our CRA compliance checklist.

Complaro automates ENISA report generation with pre-filled templates for all three reporting stages. When an actively exploited vulnerability is detected in your dependencies, Complaro drafts the early warning and notifies your team — so you can submit within hours, not scramble for days. Get started free.