Since September 11, 2026, a WordPress plugin business that sells to customers in the EU has 24 hours to warn the authorities once it knows that a vulnerability in one of its products is being actively exploited. That obligation comes from the EU Cyber Resilience Act, it already applies, and it covers plugins you sold long before the law existed.
Most coverage of the Cyber Resilience Act focuses on December 2027, when the full set of requirements arrives. That date matters, but it hides the part that is live today. This guide explains who the law covers, what applies right now, what waits until 2027, and what a small plugin or theme business can set up this month.
This is a practical summary for developers, not legal advice. The Commission's guidance is not binding, and only the courts interpret the regulation authoritatively. If your business model depends on the answer, ask a lawyer who works with EU product law.
What the Cyber Resilience Act Is
The Cyber Resilience Act (Regulation (EU) 2024/2847) sets security rules for "products with digital elements", hardware and software alike. It applies in stages, and two dates matter for manufacturers:
From September 11, 2026: the reporting obligations in Article 14.
From December 11, 2027: everything else, including secure development requirements, vulnerability handling, documentation and CE marking.
In July 2026 the European Commission approved detailed guidance with 67 worked examples. Most of the answers below come from that document and the regulation itself.
Does It Apply to Your Plugin?
The law applies to manufacturers that make products available on the EU market "in the course of a commercial activity". Three questions settle most cases.
Is a plugin a product?
Very likely, yes. The guidance treats software that you download and that runs on the user's own system as a product, and it names browser extensions as an example. A WordPress plugin or theme fits that description. Websites and web apps that people only use through a browser do not.
Is selling it a commercial activity?
Charging a price is the clearest sign. The regulation's recitals list others: charging for support beyond cost recovery, using the software to monetise other products or services, and requiring personal data as a condition of use for reasons other than security or compatibility. Accepting donations is not commercial in itself, but the guidance says that giving releases, updates or security fixes only to donors amounts to charging a price.
What about freemium plugins?
This is where most WordPress businesses sit, and the guidance addresses it directly. A free community version and a paid version count as separate products. The paid version is placed on the market, so you are a manufacturer for it. The free version is not, as long as it is not itself monetised. Two caveats:
Free software "through which it monetises other products ... or services" is placed on the market. The guidance's example is a free VPN that sells access to extra servers. Whether a free plugin that exists mainly to sell its Pro version falls under this is not settled.
A GPL plugin whose source code is only available to paying customers does not count as free and open-source software under the CRA, so the lighter open-source rules do not apply to it.
You are not in the EU?
The law applies to products made available on the EU market, and EU market surveillance rules treat an online offer as made available when it targets end users in the EU. An authorised representative in the EU is optional, not required. If you sell to EU customers, plan as if the reporting duty applies to you.
What Applies Since September 11, 2026
Article 14 creates two reporting duties. Both apply to every product in scope, including products placed on the market before 2027, and there is no duty to report retroactively for exploitation you knew about before September 11.
Actively exploited vulnerabilities
A vulnerability counts as actively exploited when there is reliable evidence that an attacker has used it on a system without the owner's permission. A theoretical flaw that nobody has used is not reportable under this article. Once you are aware, which the guidance describes as having a reasonable degree of certainty after an initial assessment, three deadlines start:
24 hours: an early warning, including the EU countries where the product is available.
72 hours: a vulnerability notification with the details you have.
14 days after a fix or mitigation is available: a final report covering the vulnerability, its severity and impact, the attacker if known, and the fix.
Severe incidents
A severe incident is one that affects the security of your product, for example by leading to malicious code being introduced or run on users' systems. A compromised update server that pushes a backdoored release is the textbook case. The deadlines are 24 hours for an early warning, 72 hours for a notification, and one month for the final report.
Two more points catch people out. If the exploited flaw sits in a library you bundle, you still report when it is exploited in your product. And you must inform affected users, and all users where appropriate, about the problem and what they should do. The guidance treats that as risk-based, not as a requirement to publish everything.
Where reports go
Reports go through ENISA's Single Reporting Platform, which went live on September 11. Each report reaches the national CSIRT acting as coordinator and ENISA at the same time. Your coordinator is the CSIRT of the EU country where your main establishment is. Without an EU establishment, the regulation runs through a fixed order, ending with the EU country where most of your users are.
Access requires an EU Login account with multi-factor authentication. The platform is English-only and has no API yet. ENISA itself advises manufacturers to register and start validation only when they need to submit a notification, which makes it all the more important to know the steps in advance.
Fines, and the Relief for Small Businesses
Breaking the core obligations, including Article 14, can cost up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, with national rules deciding the details. A corrigendum published in 2025 fixed an important exception so that it covers the reporting fines: micro and small enterprises cannot be fined for missing the 24-hour early warning deadlines. The 72-hour notification, the final report and informing users can still be fined. A micro enterprise has fewer than 10 staff and up to 2 million euros in turnover or balance sheet; a small one has fewer than 50 staff and up to 10 million euros.
That relief is not a reason to ignore the 24-hour step. It means a small team that is a few hours late is not punished for that alone.
A Runbook for a Small Plugin Business
None of this needs a compliance department. It needs a written plan that works on a Saturday night.
List your products and decide which are commercial. Paid plugins, Pro versions and paid add-ons are. Note your reasoning for each free version.
Define "aware". Decide who assesses a report of exploitation and what counts as reliable evidence, so the 24-hour clock starts at a known point.
Find your coordinator CSIRT. Work it out now, from the country of your main establishment or the fallback order.
Prepare access. Create an EU Login account with multi-factor authentication and read the platform's user manual, so the first report is not also your first login.
Keep a template. Draft the fields for an early warning and a notification: product, versions, countries, what you know, what you are doing.
Have a way to reach users. An email list, an admin notice in the plugin or a security advisory page. Article 14 requires you to inform affected users.
Make it easy to report a vulnerability to you. A security page or a
security.txtfile with a contact address becomes mandatory in December 2027. Having it now is how you hear about problems before attackers act on them.
Patching fast stays the best protection. The reporting duty only adds a paper trail to work you should already be doing; the WordPress security hardening checklist covers the site side of that work.
What Waits Until December 11, 2027
From December 2027, new products and products that are substantially modified must meet the full essential requirements. For a plugin business, the list that will take the longest is:
A software bill of materials covering at least your top-level dependencies.
A coordinated vulnerability disclosure policy and a contact address for vulnerability reports.
Security updates provided free of charge, separately from feature updates where that is technically feasible, with public advisories once a fix is out.
A support period that reflects how long the product is expected to be used, at least five years unless the expected use is shorter, with its end date shown at the time of purchase.
Technical documentation, a self-assessment (module A for most products), an EU declaration of conformity and the CE marking, which for software can sit on the accompanying website.
Products already on the market before December 2027 only need to meet these requirements if they are substantially modified afterwards. The guidance is clear that security updates are generally not substantial modifications, while adding a new feature that changes the security picture can be.
Are security plugins "important" products?
Most plugins are default products and can self-assess. Some categories are classed as important and need stricter conformity assessment: identity management, which includes two-factor authentication and single sign-on software; password managers; anti-malware software; and, in the stricter Class II, web application firewalls. If your plugin's core function is one of these, check the technical descriptions in the Commission's implementing regulation early.
Open Questions to Watch
Annual licences for updates. Many plugins sell a yearly license that includes updates. How that fits with free security updates and a five-year support period is the biggest unresolved business question in the law. Get advice before 2027 if this is your model.
Free cores with paid add-ons. Whether the seller of an add-on must report an exploited flaw in a separately installed free core is not addressed directly.
Standards. The harmonised standards that will make compliance easier to demonstrate are still being finalized. For default products they are optional.
Start With the Clock
Most of the Cyber Resilience Act can be planned over the next year. The 24-hour clock cannot. It already applies, it covers what you sold years ago, and the worst time to read the platform's manual is the night someone is exploiting your code. Write the runbook now, and it will cost you an hour. Improvise it later, and it will cost you much more.
