ENISA Vulnerability Reporting: What Triggers the 24-Hour Clock Under CRA

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

This guide covers what triggers reporting, what "actively exploited" actually means, and how to prepare your internal process before the deadline arrives.

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 significant service disruption to users
• Result in widespread compromise

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

What "Actively Exploited" Means

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 / 30 days 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 to Report

ENISA Single Reporting Platform (SRP)

Starting September 2026, ENISA will operate a single entry point for CRA notifications.

What we know:

• Web-based platform for submissions
• API access for automated reporting (anticipated)
• Simultaneous routing to relevant national CSIRTs
• Standardized reporting forms

VERIFY WITH PRIMARY SOURCE: Exact platform specifications and URL pending ENISA publication.

National CSIRTs

Reports go simultaneously to:

• ENISA (EU-level coordination)
• National CSIRT(s) where product is available

The SRP should handle routing automatically based on your market presence declaration.

For Products in Multiple Member States

If your product is available in multiple EU countries:

• One submission to SRP
• Platform routes to all relevant CSIRTs
• You may receive follow-up from multiple national authorities

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

Small and medium enterprises have some relief:

Notification timing exemption: SMEs are exempt from fines specifically related to the 24-hour and 72-hour notification deadlines.

Still required:

• Reporting (just not penalized for timing delays)
• All other CRA obligations
• Final reports

Definition: SME as defined in EU Recommendation 2003/361/EC (fewer than 250 employees, turnover ≤ EUR 50 million or balance sheet ≤ EUR 43 million).

This exemption is for timing penalties only. SMEs must still 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/30d 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

The ENISA SRP is designed to handle routing for both regimes where applicable.

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) / 30 DAYS (incident)
[ ] Final report submitted
[ ] Lessons learned documented
[ ] Process improvements identified

How CRA Evidence Helps

CRA Evidence includes ENISA reporting workflow support:

• Deadline tracking: Automatic countdown from discovery
• Report templates: Pre-filled with your product details
• Audit trail: Document your timeline and decisions
• Integration: Connect vulnerability scanning to reporting workflow

Be ready for September 2026 with app.craevidence.com.

Timeline: See when reporting obligations begin in our CRA implementation timeline.

CVD: Set up your vulnerability intake process with our CVD policy template.

Penalties: Understand enforcement consequences in our penalties guide.

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.