CRA incident reporting: the 24-hour ENISA deadline explained

What triggers the 24-hour clock

Article 14 of the Cyber Resilience Act (Regulation 2024/2847) says manufacturers must notify their designated CSIRT and ENISA of any “actively exploited vulnerability” in their product. The clock starts when you become aware of the exploitation, not when the vulnerability was first disclosed or discovered.

“Actively exploited” means someone is using the vulnerability against real users in the wild. A proof-of-concept on GitHub does not count. A theoretical weakness in your code does not count. But the moment you learn that real attacks are happening against sites running your plugin, the 24-hour window opens.

There are two triggers that require reporting:

• Actively exploited vulnerabilities in your product with digital elements
• Severe incidents that affect the security of your product (for example, your update server is compromised and pushes malicious code to users)

If you get an email from a security researcher saying “I found an SQL injection in your plugin,” that is a vulnerability disclosure, not an actively exploited vulnerability. You still need a vulnerability handling process, but the 24-hour clock does not start unless exploitation is confirmed in the wild.

The three-stage reporting timeline

The CRA does not ask for one report. It asks for three, each with increasing detail. This staged approach is borrowed from the NIS2 Directive and gives you time to investigate while still notifying authorities early.

Stage 1: Early warning (within 24 hours)

Submit a brief early warning to your designated CSIRT through the ENISA Single Reporting Platform. At this stage you do not need a root cause analysis or a patch. You need to confirm that you are aware of the issue and provide an initial severity assessment.

The early warning should include:

• Confirmation that you are aware of the actively exploited vulnerability
• Your initial assessment of severity
• Whether you suspect the exploitation is malicious
• Whether other products or vendors might be affected

Stage 2: Incident notification (within 72 hours)

Follow up with a more detailed notification. By this point, you should have a better picture of what happened and who is affected.

This notification should cover:

• A description of the vulnerability and how it is being exploited
• Severity classification and estimated impact
• The scope of affected products and versions
• Initial corrective measures you have taken or plan to take
• Whether a patch or update is available

Stage 3: Final report (within 14 days)

After you have resolved the issue or at least deployed a fix, submit the final report. For severe incidents (as opposed to actively exploited vulnerabilities), you have up to one month instead of 14 days.

The final report should include:

• Root cause analysis
• Full description of corrective measures taken
• A list of affected EU Member States and users, where known
• Confirmation that the issue has been resolved

What you need to include in each report

The practical question every solo plugin developer asks: “What exactly do I write?” Here is a realistic breakdown of what each stage looks like for a typical WordPress plugin.

Early warning example

“We have become aware that CVE-2026-XXXXX in MyPlugin versions 3.1 through 3.4 is being actively exploited in the wild. Initial reports indicate attackers are using the vulnerability to inject malicious scripts into affected WordPress sites. We assess the severity as HIGH. We are investigating and will provide a detailed notification within 72 hours.”

That is a few sentences. The 24-hour deadline is not asking you for a PhD thesis. It is asking you to raise your hand and say “we know about this.”

Incident notification example

By 72 hours, expand on the early warning with technical details: what the vulnerability is (stored XSS via the settings page, SQL injection in the search endpoint, etc.), which versions are affected, how many active installations exist, and what you have done so far (released an emergency patch, notified hosting providers, etc.).

The ENISA Single Reporting Platform (SRP)

ENISA has built a central platform specifically for CRA reporting. The good news: you report once, through one platform. You do not need to individually contact the CSIRT in every EU member state where your plugin has users.

The SRP will be operational by 11 September 2026, with a testing period before that date. As a manufacturer, you submit your notification to the SRP, which routes it to the relevant CSIRT (the Computer Security Incident Response Team in the member state where your main establishment is located). ENISA receives the information simultaneously.

Key points about the SRP:

• One submission, multiple recipients. You file once. The platform handles distribution to the right national authorities.
• Electronic system. This is an online platform, not email or phone. Expect a web form with structured fields.
• Secure by design. ENISA is required to implement appropriate technical measures to protect submitted information.
• Not yet public. As of March 2026, the platform is under development. ENISA has contracted external services to build it. The testing period will open before September 2026.

If you are not based in the EU, you still report through the SRP. The CRA applies based on where your users are, not where you are. You would designate the CSIRT of the EU member state closest to your primary operations, or where the majority of your EU users are located.

Real WordPress scenarios

Let us walk through situations that WordPress plugin developers actually face, and whether each one triggers the 24-hour reporting requirement.

Scenario 1: Security researcher emails you about an XSS bug

Triggers reporting? No, not unless it is being actively exploited. This is a standard vulnerability disclosure. You should follow your vulnerability handling process and patch it, but the CRA reporting clock does not start.

Scenario 2: Patchstack or WPScan reports active exploitation of your plugin

Triggers reporting? Yes. If a security intelligence service confirms active exploitation in the wild, and you become aware of it, the 24-hour clock starts. Submit an early warning through the SRP.

Scenario 3: Your WordPress.org SVN credentials are compromised

Triggers reporting? Yes. This is a severe incident affecting the security of your product. If an attacker pushes a malicious update through your compromised account, every site running your plugin receives tainted code. Report immediately.

Scenario 4: A dependency in your composer.json has a published CVE

Triggers reporting? Not automatically. A published CVE in a dependency is a known vulnerability, but only triggers reporting if exploitation in the wild is confirmed against your product specifically. However, you should still patch it. Automated SBOM tracking and vulnerability scanning help you catch these before they become exploited.

Scenario 5: You wake up to 200 support tickets about hacked sites

Triggers reporting? Almost certainly yes. Mass reports of compromised sites running your plugin strongly suggest active exploitation. Start your early warning while you investigate. You can update the details in the 72-hour notification.

What happens if you miss the deadline

The CRA allows market surveillance authorities to impose fines of up to EUR 15 million, or 2.5% of total worldwide annual turnover, whichever is higher. Failure to report within the required timelines falls under non-compliance with the essential requirements.

In practice, enforcement will likely focus on patterns of negligence rather than honest delays. If you can demonstrate that you had a process in place, acted in good faith, and filed as soon as practically possible, regulators are likely to treat you differently than a manufacturer who ignored the obligation entirely.

That said, “I didn’t know I had to report” is not a defence. The regulation is published. The deadlines are public. Having a documented incident response plan is the best protection you have.

How to prepare before September 2026

You do not need to wait for the SRP to go live. Most of the preparation is about having the right process in place so you can act fast when something happens.

1. Write an incident response plan. Document who does what when a vulnerability is reported or exploitation is detected. Include contact details, escalation paths, and template text for each stage of the CRA reporting timeline. CRA Guard includes incident response plan templates in the free tier.
2. Set up vulnerability monitoring. You need to know when your dependencies have published CVEs and when active exploitation is reported. Manual checking does not scale. Automated scanning against the OSV.dev database catches known vulnerabilities before they become incidents.
3. Track the ENISA SRP testing period. When ENISA opens the SRP for testing, register and familiarise yourself with the interface. You do not want your first time using the platform to be during an active incident at 2am.
4. Keep your SBOM current. Knowing exactly which dependencies your plugin uses and which versions are installed is the foundation of a fast incident response. Generate your SBOM now and update it with every release.
5. Practice. Run a tabletop exercise. Pick a hypothetical vulnerability, walk through your incident response plan, and see where the gaps are. The first time you use your plan should not be during a real incident.

Common questions

Does the 24-hour deadline apply to all vulnerabilities?

No. Only actively exploited vulnerabilities and severe incidents require the 24-hour early warning. Standard vulnerability disclosures (someone reports a bug but it is not being exploited) follow your normal vulnerability handling process.

What if I find out on a Saturday night?

The 24-hour deadline runs from the moment you become aware, regardless of weekends, holidays, or time zones. This is why having an incident response plan matters. You need to be able to file a basic early warning at any time.

I am a solo developer. How do I handle this alone?

The early warning is deliberately simple. A few sentences confirming awareness, initial severity, and whether others might be affected. You can write that in ten minutes. The harder part is having the monitoring in place to find out about exploitation quickly. Automated vulnerability scanning and email alerts are the solo developer’s best tools here.

What if I am not sure the vulnerability is being actively exploited?

When in doubt, file the early warning. There is no penalty for reporting something that turns out to be less serious than you initially thought. There are penalties for not reporting something that turns out to be serious.

Do I need to notify my users as well?

The CRA requires you to inform affected users “without undue delay” and, where available, provide guidance on corrective measures. This is separate from the ENISA notification. WordPress developers typically do this through the plugin update mechanism, a security advisory on their website, and direct email to affected customers.

How does this relate to Patchstack’s vulnerability disclosure?

Patchstack handles coordinated vulnerability disclosure and manages a VDP programme for WordPress plugins. The CRA reporting obligation is separate. Patchstack covers one part of the CRA (vulnerability disclosure), but incident reporting to ENISA is a different obligation that you, as the manufacturer, are responsible for. The two complement each other. Read more about the full set of CRA obligations.

Get your incident response plan in place

CRA Guard includes incident response plan templates, vulnerability monitoring, and deadline tracking for the 24-hour, 72-hour, and 14-day windows. The free tier covers the plan templates. The pro tier adds automated scanning, email alerts, and a live incident centre with countdown timers so you never miss a filing deadline.

Get Early AccessView Pricing Plans

Sources

• CRA Article 14 full text
• EU Commission: CRA reporting obligations
• ENISA Single Reporting Platform (SRP)
• EU Commission: CRA legislative summary

Disclaimer: This article is for informational purposes and does not constitute legal advice. The CRA reporting obligations described here are based on Regulation (EU) 2024/2847 as published. Consult qualified legal counsel for advice specific to your situation.