ENISA Vulnerability Reporting: The 24-Hour Clock Starts 11 September 2026

11 September 2026. From this date, you have 24 hours to report actively exploited vulnerabilities to ENISA. Miss the deadline and face enforcement action.

What Triggers CRA Reporting?

The CRA defines two categories requiring mandatory notification:

1. Actively Exploited Vulnerabilities

A vulnerability in your product that:

• Is known to you (discovered internally or reported externally)
• Has been exploited by a malicious actor
• Affects or could affect users of your product

2. Severe Incidents

Security incidents that:

• Impact the security of your product
• Compromise your development environment in ways affecting product security
• Cause widespread service disruption to users
• Result in widespread compromise

Both categories trigger the same reporting timelines but have different final report windows.

What Does "Actively Exploited" Mean Under the CRA?

The CRA defines an actively exploited vulnerability as one where "a malicious actor makes use of a flaw."

This is not the same as:

• A vulnerability being publicly disclosed
• A proof-of-concept being published
• A researcher demonstrating exploitability

It means actual malicious use.

Reportable vs Non-Reportable Scenarios

The "Reasonable Belief" Standard

You don't need forensic proof of exploitation. The standard is reasonable belief based on available evidence:

• Unusual access patterns consistent with known exploit techniques
• Customer reports of compromise
• Threat intelligence indicating your product is targeted
• Detection of exploit code designed for your product

When uncertain: Err on the side of reporting. A premature early warning that proves unfounded is far better than a missed deadline for actual exploitation.

Reporting Timelines

Both vulnerabilities and incidents follow a staged reporting model:

Actively Exploited Vulnerability Timeline

DISCOVERY → 24 HOURS → 72 HOURS → PATCH AVAILABLE → 14 DAYS
    |           |           |            |              |
    |           |           |            |              \-- Final Report
    |           |           |            \-- Clock restarts
    |           |           \-- Detailed Notification
    |           \-- Early Warning
    \-- Clock starts

Severe Incident Timeline

DISCOVERY → 24 HOURS → 72 HOURS → 1 MONTH
    |           |           |         |
    |           |           |         \-- Final Report
    |           |           \-- Detailed Notification
    |           \-- Early Warning
    \-- Clock starts

What Each Report Contains

Early Warning (24 hours)

Minimum information to alert authorities:

• Your identity (manufacturer)
• Affected product(s) identification
• Brief description of vulnerability/incident
• Initial severity assessment
• Whether exploitation is confirmed or suspected
• Indication of potential impact scope

This is not a complete analysis. It's an alert that something serious is happening.

Detailed Notification (72 hours)

Expanded information for assessment:

• Technical details of the vulnerability
• Affected versions and configurations
• Exploitation method (if known)
• Current mitigation status
• Remediation timeline estimate
• Known affected users/scope
• Coordination with other parties (other vendors, CSIRTs)

Final Report (14 days for vulns / one month for incidents)

Complete analysis after remediation:

• Root cause analysis
• Full technical description
• Remediation actions taken
• Lessons learned
• Prevention measures implemented
• Impact assessment (confirmed affected users, data exposure, etc.)

Where Do You Submit the ENISA Vulnerability Report?

ENISA Single Reporting Platform (SRP)

The SRP is not operational as of April 2026. ENISA has contracted a vendor and the platform is scheduled to open by 11 September 2026, when reporting obligations begin. A testing period is planned before that date. No registration URL has been published. Monitor the ENISA SRP page for updates: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

What is confirmed:

• Web-based platform for submissions
• Standardized reporting forms
• Single submission routed to the relevant national CSIRT

What manufacturers can do now:

• Draft report templates using the structure below
• Identify your coordinator CSIRT (see below)
• Define internal escalation paths and authorized reporters

National CSIRTs

Under Article 14(7) of Regulation (EU) 2024/2847, you submit once via the SRP to the CSIRT of the Member State where your organization has its main establishment. Main establishment means where decisions about product cybersecurity are predominantly taken.

If you are established outside the EU, the relevant CSIRT is that of your EU authorized representative. If you have no authorized representative, the cascade falls to your importer, then distributor, then the country with the greatest user concentration.

You are not required to notify every CSIRT in every country where your product is sold. Under Article 16, ENISA routes the notification onward to market-country CSIRTs after you submit. That step is not the manufacturer's responsibility.

For Products in Multiple Member States

One submission to the SRP covers your reporting obligation. You may receive follow-up from multiple national authorities, but there is a single submission path.

Internal Preparation Checklist

Don't wait until September 2026. Build your processes now.

1. Vulnerability Intake Channels

Establish clear paths for vulnerability reports:

security.txt file:

# https://yourproduct.com/.well-known/security.txt
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/policy

Web form for structured reports

Dedicated email monitored 24/7 (or with clear SLA)

2. Internal Triage Process

Define how reports are evaluated:

VULNERABILITY INTAKE TRIAGE

1. Initial Receipt (< 4 hours)
   - Acknowledge receipt
   - Assign to security team member
   - Initial validity check

2. Technical Triage (< 24 hours)
   - Confirm vulnerability exists
   - Determine affected versions
   - Assess exploitability
   - Check for active exploitation evidence

3. Severity Assessment (< 24 hours)
   - CVSS scoring (or equivalent)
   - Business impact evaluation
   - Exploitation likelihood

4. Reporting Decision (IMMEDIATE if exploitation confirmed)
   - Does this require ENISA notification?
   - If yes, initiate 24-hour clock

3. Escalation Paths

Define who can trigger external reporting:

Key principle: The person who discovers potential exploitation must be able to escalate immediately, 24/7.

4. After-Hours Coverage

The 24-hour clock doesn't pause for weekends or holidays.

Options:

• On-call rotation for security team
• Monitoring service with escalation authority
• Clear out-of-hours contact chain
• Pre-authorized reporters who can submit early warnings

5. Report Templates

Prepare templates before you need them:

Early Warning Template:

ENISA CRA EARLY WARNING

Manufacturer: [Company Name]
Report Date: [Date/Time UTC]
Report Type: [ ] Actively Exploited Vulnerability [ ] Severe Incident

AFFECTED PRODUCT(S):
- Product Name:
- Version(s):
- Product Category:

VULNERABILITY/INCIDENT SUMMARY:
[Brief description - 2-3 sentences]

EXPLOITATION STATUS:
[ ] Confirmed exploitation
[ ] Suspected exploitation
Evidence: [Brief description of evidence]

INITIAL SEVERITY ASSESSMENT:
[ ] Critical [ ] High [ ] Medium [ ] Low
Basis: [CVSS score or other rationale]

POTENTIAL IMPACT SCOPE:
- Estimated affected users:
- Geographic scope:
- Data at risk:

CURRENT STATUS:
[ ] Under investigation
[ ] Mitigation in progress
[ ] Patch in development

CONTACT FOR FOLLOW-UP:
Name:
Email:
Phone:

This is an early warning. Detailed notification to follow within 72 hours.

6. Test Your Process

Run tabletop exercises before September 2026:

Scenario 1: Friday 5pm - Security researcher reports critical vulnerability with PoC

• How quickly can you assess exploitation risk?
• Who makes the reporting decision over the weekend?

Scenario 2: Customer reports suspicious activity suggesting your product was entry point

• How do you gather evidence to confirm/deny exploitation?
• What's your threshold for "reasonable belief"?

Scenario 3: Threat intelligence indicates your product is being targeted by APT group

• Do you have visibility into actual exploitation?
• How do you coordinate with external threat intel providers?

Common Pitfalls

Waiting for Certainty

Problem: Wanting forensic proof before reporting.

Reality: The 24-hour clock starts when you have reasonable belief. If you wait for certainty, you'll miss the deadline.

Solution: Report early. You can update with "no longer believed to be exploited" in the detailed notification if evidence doesn't support it.

Confusing CVD with Reporting

Problem: Treating researcher reports as ENISA notifications.

Reality: Coordinated vulnerability disclosure and ENISA reporting are separate processes.

• CVD: How you handle researcher reports, agree on disclosure timelines
• ENISA: Mandatory notification when exploitation occurs

Solution: CVD process should include a gate: "Is there evidence of exploitation?" If yes, trigger ENISA reporting parallel to CVD.

Single Point of Failure

Problem: Only one person can authorize reports, and they're unreachable.

Reality: Exploitation can be discovered at any time. Weekends. Holidays. 3am.

Solution: Multiple authorized reporters. Clear delegation. Emergency contact chain.

No Relationship with CSIRTs

Problem: First contact with your national CSIRT is during an incident.

Reality: Building relationships beforehand makes incident response smoother.

Solution: Engage your national CSIRT now. Understand their processes. Join any manufacturer outreach programs.

SME Exemptions

Microenterprises and small enterprises have some relief under Article 64(10)(a):

Notification timing exemption: Exempt from fines for missing the 24-hour early warning deadlines in Article 14(2)(a) and Article 14(4)(a). The 72-hour detailed notification deadline (Articles 14(2)(b) and 14(4)(b)) is not covered. Missing it can result in fines regardless of company size.

Still required:

• Reporting (just not penalized for the 24-hour timing)
• All other CRA obligations
• Final reports

Definition (Article 64(10)(a)): Applies to microenterprises (fewer than 10 employees, annual turnover or balance sheet ≤ EUR 2 million) and small enterprises (fewer than 50 employees, annual turnover or balance sheet ≤ EUR 10 million). Medium enterprises (up to 250 employees) are not covered by this exemption.

This exemption covers the 24-hour early warning penalty only. All manufacturers — including microenterprises — must establish reporting capabilities.

Integration with Existing Processes

If You Already Have Incident Response

Map CRA reporting to your existing process:

EXISTING IR PROCESS          CRA INTEGRATION
---------------------------------------------
Detection
    |
Triage ------------------→  Check: Exploitation of CRA product?
    |                             |
Containment                       +- YES: Trigger 24h clock
    |                             |       Submit early warning
Investigation                     |
    |                             |
Remediation --------------→  72h detailed notification
    |
Recovery
    |
Lessons Learned ----------→  14d/1 month final report

If You Have NIS 2 Obligations

Some organizations have both NIS 2 and CRA obligations:

• NIS 2: Organization/service level incidents
• CRA: Product-level vulnerabilities and incidents

These may overlap. A single incident might require both:

• NIS 2 notification to competent authority
• CRA notification to ENISA/CSIRT

ENISA has indicated the SRP will handle routing for both regimes where applicable. This has not been confirmed in final guidance.

ENISA Reporting Readiness Checklist

ENISA REPORTING READINESS CHECKLIST

BEFORE SEPTEMBER 2026:

CHANNELS & CONTACTS
[ ] security.txt published and current
[ ] Vulnerability reporting form available
[ ] Security email monitored (define SLA: ____ hours)
[ ] National CSIRT contact identified
[ ] ENISA SRP registration (when available)

INTERNAL PROCESS
[ ] Triage criteria documented
[ ] Exploitation assessment checklist created
[ ] Escalation path defined (names, contacts)
[ ] Authorized reporters identified
[ ] After-hours coverage established

DOCUMENTATION
[ ] Early warning template prepared
[ ] Detailed notification template prepared
[ ] Final report template prepared
[ ] Internal briefing materials ready

TESTING
[ ] Tabletop exercise completed
[ ] After-hours escalation tested
[ ] Template review completed

WHEN EXPLOITATION IS DETECTED:

IMMEDIATE (within 4 hours)
[ ] Initial assessment: Is this actively exploited?
[ ] Clock start time documented: ____________
[ ] Escalation to authorized reporter

WITHIN 24 HOURS
[ ] Early warning submitted to ENISA SRP
[ ] Submission confirmation received
[ ] Internal stakeholders notified

WITHIN 72 HOURS
[ ] Detailed notification submitted
[ ] Mitigation status updated
[ ] Customer communication initiated (if appropriate)

WITHIN 14 DAYS (vulnerability) / ONE MONTH (incident)
[ ] Final report submitted
[ ] Lessons learned documented
[ ] Process improvements identified

Next Steps

Managing CRA compliance across multiple products? CRA Evidence tracks deadline countdowns and pre-filled report templates for each product's vulnerability disclosures.

Once your triage process is in place, set up your vulnerability intake with our CVD policy template. Check the penalties guide to understand what enforcement looks like if the deadline is missed.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel familiar with EU product regulations.