EU Cyber Resilience Act: The WordPress Sept 11 Deadline
On 11 September 2026, a piece of EU product-safety law starts applying to software, and a large share of the WordPress plugin economy is inside its scope without knowing it. The obligation is narrow, the deadline is real, and the people it lands on hardest are the ones least set up to notice: small commercial plugin and theme vendors who sell a Pro tier to customers in Europe.
This is the Cyber Resilience Act — Regulation (EU) 2024/2847. It is not a privacy law and it is not the AI Act. It is a product regulation, and under it a plugin is a “product with digital elements” the same way a router or a smart doorbell is. I went through the regulation, then audited this site’s own 48 active plugins against it. The audit found something on our side, which is in this post rather than quietly patched.
What actually happens on 11 September 2026
The CRA phases in. Most of it — the essential cybersecurity requirements, conformity assessment, CE marking, technical documentation — does not bite until December 2027. Exactly one article arrives next month, and it is Article 14, the reporting duty.
| Date | What applies | Who it touches |
|---|---|---|
| 10 December 2024 | Regulation enters into force | Nobody yet — clock starts |
| 11 June 2026 | Chapter IV (Articles 35–51) | Notified bodies — conformity assessment infrastructure, not software vendors |
| 11 September 2026 | Article 14 — reporting obligations | Manufacturers and open-source stewards |
| 11 December 2027 | The rest of the Regulation | Everyone in scope |
One correction worth making early, because it is circulating in WordPress security content: there is no CRA deadline in June 2026 for having a vulnerability disclosure policy in place. The June 2026 date is real, but Article 71 assigns it to Chapter IV, which sets up notified bodies — the organisations that will later perform conformity assessments. It imposes nothing on a plugin author. If you have seen “VDP required by June 2026,” it is a garbled version of that. The date that matters to you is 11 September 2026.
Which one are you?
The CRA sorts everyone into categories, and the category decides the obligation. For WordPress this produces three practical buckets.
| Category | Who this is, in WordPress terms | Obligation from 11 Sept 2026 |
|---|---|---|
| Manufacturer | A company or individual placing commercial software on the EU market — a paid plugin, a paid theme, a freemium plugin with an upsell | Full Article 14 reporting: actively exploited vulnerabilities and severe incidents |
| Open-source software steward | A legal person sustaining FOSS intended for commercial activity without monetising it themselves — the WordPress Foundation is generally treated as the steward for core | Lighter scheme under Article 24: a cybersecurity policy, cooperation with authorities, and reporting |
| Out of scope | A genuinely unmonetised free plugin — hobby code, no Pro tier, no paid support, no sponsorship attached to it | None |
Note who is not in this table: the site owner running the plugins. If you operate a WordPress site, the CRA does not make you a manufacturer of the plugins you install. Your exposure is indirect — you depend on vendors who now have a legal duty to tell authorities when their product is being exploited, and on vendors who might quietly stop shipping to the EU rather than deal with it.
The freemium question is the one that matters here
This is where the WordPress ecosystem’s business model collides with the text. Recital 18 draws the line at monetisation:
“the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity.”
Read the negative. Software that is monetised by its manufacturer is a commercial activity. The WordPress.org directory is full of plugins that are free downloads and commercial products at the same time — the free version is the funnel, the Pro licence is the business. That is monetisation by the manufacturer, and it puts the vendor in the manufacturer bucket even though the artefact on WordPress.org costs nothing.
The distinction is not “did you charge for this download.” It is “are you monetising this product.” A free plugin with an in-plugin upgrade prompt is being monetised. A free plugin whose author takes paid support contracts for it is being monetised. A weekend project with a donate link is a harder call, and the honest answer is that the boundary has not been tested yet.
What a steward actually is
Recital 19 describes stewards as legal persons who “provide support on a sustained basis for the development of [free and open-source software products] intended for commercial activities, and who play a main role in ensuring the viability of those products.” Foundations, in other words. The WordPress Foundation fits, and Article 24 gives stewards a lighter regime than manufacturers — a cybersecurity policy and cooperation duties rather than the full conformity apparatus. Stewards still report under Article 14 from 11 September 2026.
The three reports, and the clock most summaries get wrong
Article 14 does not ask for one report. It asks for three, on a staged timeline, through a single reporting platform to both the CSIRT designated as coordinator and ENISA.
| Report | Deadline | Clock starts | Must contain |
|---|---|---|---|
| Early warning | 24 hours | Becoming aware of the actively exploited vulnerability | That it exists; member states where the product is available |
| Vulnerability notification | 72 hours | Becoming aware | Description, severity, impact, and any corrective or mitigating measures taken or available |
| Final report | 14 days | After a corrective or mitigating measure is available | The vulnerability, its severity and impact, malicious actors if known, and the security update |
That third row is the detail nearly every summary flattens into “a final report within 14 days,” which reads as fourteen days from discovery. The operative text is “no later than 14 days after a corrective or mitigating measure is available.” The clock starts when a fix exists, not when you found the problem. That is a materially easier obligation than the flattened version, and it changes what a small vendor needs to build: you are not racing a 14-day fix deadline, you are on a 14-day documentation deadline that begins once you have shipped something.
Severe incidents run on a parallel track — 24 hours for the early warning, 72 hours for the incident notification, and a final report one month after the notification.
Note also the trigger for the whole regime: actively exploited. A researcher reporting a theoretical vulnerability in your plugin does not start the Article 14 clock. Evidence that someone is exploiting it in the wild does.
The penalty tiers, and the inversion nobody quotes
Article 14 sits in the highest penalty tier — the same band as breaching the essential cybersecurity requirements themselves.
| Tier | Maximum fine | Covers |
|---|---|---|
| 1 | €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher | Essential requirements (Annex I), Articles 13 and 14 |
| 2 | €10,000,000 or 2% of turnover | Most other obligations (Articles 18–23, 28, 30–33, and others) |
| 3 | €5,000,000 or 1% of turnover | Supplying incorrect or misleading information to notified bodies |
Now the part that gets left out. Article 64 carves out precisely the people most of this ecosystem consists of:
- Microenterprises and small enterprises are exempt from fines for missing the Article 14(2) and 14(4) deadlines. The duty to report still applies. The fine for being late does not.
- Open-source software stewards are not subject to administrative fines at all.
So the honest summary for a two-person plugin company selling a Pro tier in Europe is: you are inside the highest penalty tier on paper, and you are also inside the exemption that removes the deadline fine. What remains is a genuine legal obligation, enforceable by market surveillance authorities through means other than fines, that you should meet because the reporting regime exists to stop your customers being exploited — not because a €15 million number is realistically pointed at you. Anyone selling you CRA compliance services with that number on the slide is selling to the wrong half of the article.
What I found auditing this install
Theory is cheap. I ran the categorisation against this site’s own plugins, and the first number I got was wrong in an instructive way.
There are 48 active plugins. Fifteen resolve against the WordPress.org plugin API. Thirty-three do not — and “33 commercially distributed plugins” was the headline I nearly wrote. It is badly wrong. Broken down by who actually made them:
| Group | Count | What it means under the CRA |
|---|---|---|
| WordPress.org repository plugins | 15 | Vendor’s status depends on whether they monetise it |
| Our own MxChat plugins | 23 | We are the manufacturer |
| Bespoke site code, no real author set | 4 | Not placed on the market — out of scope |
| Genuine third-party commercial | 3 | Those vendors are manufacturers |
Only three plugins on this site come from a third-party commercial vendor: Rank Math SEO PRO, WooCommerce.com Update Manager, and Software Add-On for WooCommerce. The other thirty are ours or bespoke. An off-repo plugin count is a measure of how much custom code you run, not how much commercial software you depend on, and reading it the other way inflates the number by an order of magnitude.
Three other things the audit turned up:
- Four plugins have placeholder author metadata — literally “Your Name” and “Developer.” These are internal, so nothing is on the market and nothing is owed. But manufacturer identification is a real CRA requirement, and a plugin header is where that identification lives. If any of those had ever been distributed, the header would be the defect.
- One repository plugin has had no release in over twelve months — bbPress, last shipped 2 July 2025, on roughly 100,000 sites. The CRA’s support-period obligations are a 2027 problem, not a September one, but a dependency that has not shipped in a year is the shape of the problem the support-period rules exist to address.
- Three plugin updates were pending at audit time, including a WooCommerce extension two minor versions behind.
And the finding that is about us
I checked whether this site publishes a security contact. It does not:
/.well-known/security.txt => 404
/security.txt => 404
/robots.txt => 200 (control)The control matters. A probe that returns 404 for everything is a broken probe, not a finding; /robots.txt returning 200 in the same run is what makes the two 404s real.
MxChat sells commercial plugins to customers in the EU. That makes us a manufacturer under the CRA, with an Article 14 duty from 11 September 2026 — and as of this morning we had no published security contact, no security.txt, and no documented coordinated vulnerability disclosure process. That is the same gap this post is telling other vendors to close. It has been filed as a work item rather than quietly patched behind the publication of this article, because a post that describes a defect and then hides the fix is worth less than one that shows the state it found.
The tooling does not exist yet
If you go looking for a WordPress plugin to handle this for you, here is the entire market. Querying the WordPress.org plugin directory for Cyber Resilience Act tooling returns five plugins genuinely built for it:
| Plugin | Published / updated | Active installs |
|---|---|---|
| Erdo CRA Compliance | 17 June 2026 | Below 10 |
| Vulnerability Monitor for the EU CRA | 30 June 2026 | Below 10 |
| CRAGuard Compliance Portal | 26 May 2026 | Below 10 |
| Resilience Compliance Manager | 11 March 2026 | Below 10 |
| MMCRA Toolkit | 5 July 2026 | Below 10 |
Every one reports zero active installs. WordPress.org does not publish install counts below ten, so zero means “fewer than ten sites,” not literally none — but the conclusion holds either way. Five plugins, all published in the five months before the deadline, none with meaningful adoption, one rating between them.
That is not a market. It is the same pattern the AI Act disclosure category showed a few weeks ago: a regulatory deadline arrives, a handful of speculative plugins appear just ahead of it, and nobody installs any of them. The practical read is that there is no tool to buy, and the compliance work is process, not software. Which is fortunate, because the process is small.
What to actually do
If you run a WordPress site and do not sell software: nothing is required of you. The useful move is to prefer vendors who publish a security contact and a disclosure policy, because from September those vendors have a legal duty to act on what gets reported to them. Ask before you buy, not after.
If you sell a plugin or theme with EU customers — including a free plugin with a Pro tier — four things, none of which need a lawyer:
- Publish a security contact. A
security.txtat/.well-known/security.txttakes five minutes and is the standard machine-readable way for a researcher to find you:Contact: mailto:[email protected] Expires: 2027-01-01T00:00:00.000Z Preferred-Languages: en Policy: https://example.com/security-policy/ - Write down what you do when a report arrives. Who triages it, how you decide “actively exploited,” who files the report. One page. The obligation is procedural, and the failure mode is having nobody know whose job it is at 2am.
- Know where you would file. Reports go to the CSIRT designated as coordinator and to ENISA through a single reporting platform. Find the entry point before you need it.
- Decide your position on the freemium question now. If your free plugin funnels to a paid tier, plan on being a manufacturer. Deciding that in September, mid-incident, is the expensive version.
For the security side of your own install, our audit of 966 REST API routes and our review of how WordPress stores API credentials cover the two places plugin vulnerabilities most often surface. If EU compliance is on your list generally, the AI Act’s chatbot disclosure requirement and its separate rule for AI-generated content are two more 2026 deadlines that hit the same sites. Setup details for MxChat itself live in the documentation.
FAQ
Does the Cyber Resilience Act apply to my WordPress site?
Not as a site owner. The CRA regulates products placed on the market, so it applies to the people who make the plugins, themes and software you install — not to you for installing them. You become a manufacturer only if you sell or otherwise monetise software yourself.
Is a free WordPress plugin exempt from the CRA?
Only if it is genuinely not monetised by its author. Recital 18 ties the exemption to commercial activity, and a free plugin that exists to sell a Pro version is being monetised by its manufacturer. Price of the download is not the test.
What has to be reported, and when?
Actively exploited vulnerabilities and severe incidents, from 11 September 2026. Early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. Severe incidents get one month for the final report instead of 14 days.
Can a small plugin business really be fined €15 million?
Realistically, no. Article 14 sits in the top penalty tier, but Article 64 exempts microenterprises and small enterprises from fines for missing the Article 14(2) and 14(4) deadlines, and exempts open-source stewards from administrative fines entirely. The obligation is real; the headline number is not aimed at a two-person plugin shop.
Do I need a CRA compliance plugin?
There is nothing established to install. All five CRA-specific plugins in the WordPress.org directory report fewer than ten active installs. The September obligation is a process — a security contact, a triage procedure, and knowing where to file — rather than something a plugin can do for you.
The short version
One article of the CRA arrives on 11 September 2026, and it asks commercial software vendors to tell the authorities when their product is actively being exploited. In WordPress terms that lands on plugin and theme businesses, including free-with-Pro ones, and on the WordPress Foundation in a lighter form. The fines that dominate the coverage are largely carved out for the small vendors the ecosystem is made of. What is left is worth doing anyway: publish a way to be told you have a problem, and know what you will do when someone uses it.
Thirty-three days. The security.txt takes five minutes.
Disclosure: this article was researched and written by MxChat’s automated SEO agent. Regulatory text was read from the Regulation and the European Commission’s published materials rather than from secondary summaries; the plugin audit figures are first-party measurements taken from this site on 9 August 2026. Maxwell Runion holds editorial responsibility for what is published here. This is not legal advice — if the CRA applies to your business, the compliance position is worth confirming with someone qualified to give it.
