The EU’s New Cybersecurity Law Affects Every WordPress Plugin.

EU Cyber Resilience Act

A new EU law is about to change how WordPress plugin security works. It doesn’t change anything for you directly. But it changes a lot for the developers whose plugins you rely on, and if they don’t comply, the consequences land on your site.

In this article
  1. What the Cyber Resilience Act Actually Is
  2. The Deadline That Matters: 11 September 2026
  3. What It Requires From Plugin and Theme Developers
  4. What This Means If You Use Plugins (Not Build Them)
  5. Could Plugins Be Pulled From WordPress.org?
  6. What About UK Websites?
  7. What Should You Do Right Now?
  8. Common Questions About the CRA and WordPress

The EU Cyber Resilience Act (CRA) entered into force in December 2024. The first major deadline arrives on 11 September 2026, now less than 80 days away. From that date, commercial plugin and theme developers must formally report security vulnerabilities and actively exploited incidents to EU authorities. By December 2027, the full set of requirements kicks in, including mandatory security disclosure policies, software inventories, and CE marking.

Most coverage of this law is written for developers or enterprise legal teams. This piece is written for the person running a WordPress site who just wants to know what’s actually going to change.

What the Cyber Resilience Act Actually Is

The CRA is an EU regulation that sets binding cybersecurity requirements for any product with digital elements available on the EU market. That includes software, connected hardware, plugins, and themes. It’s the EU’s attempt to fix the situation where products routinely reach the market with known vulnerabilities, without timely security updates, and with no obligation to tell anyone when something goes wrong.

The law is horizontal, meaning it cuts across industries and product categories rather than targeting one sector. And it applies regardless of where the developer is based. A plugin developer in the US, UK, or Australia whose plugin is available to EU users is in scope.

The Deadline That Matters: 11 September 2026

Full CRA compliance doesn’t arrive until December 2027, but one of its most significant requirements kicks in much sooner.

From 11 September 2026, commercial plugin and theme developers must:

  • Report any actively exploited vulnerability to EU authorities within 24 hours of becoming aware of it.
  • File a full notification within 72 hours.
  • Submit a final report within 14 days of a fix being available (for actively exploited vulnerabilities) or within one month for severe incidents.
  • Publish a Vulnerability Disclosure Policy (VDP) with a clear security contact point.
  • Notify affected users without undue delay when vulnerabilities are discovered.

That last point is a significant change. Under the current system, developers can patch a vulnerability quietly and push an update with no announcement. Under the CRA, they can’t. Disclosure is mandatory.

What It Requires From Plugin and Theme Developers

The September 2026 reporting obligations are just the start. By December 2027, developers must also meet the full set of CRA requirements:

  • A Software Bill of Materials (SBOM): a structured inventory of every component and dependency in the plugin.
  • An EU Declaration of Conformity: formal documentation that the product meets CRA requirements.
  • CE marking: the same compliance mark seen on electrical products, now required on software.
  • Security updates available for the product’s expected lifetime.
  • Secure by design: no known exploitable vulnerabilities at release, secure default settings.

Non-compliance isn’t a minor administrative issue. Fines run up to €15 million or 2.5% of global annual turnover, whichever is higher. Authorities can also require non-compliant products to be removed from EU-accessible platforms.

What This Means If You Use Plugins (Not Build Them)

Here’s the version nobody else is writing.

You’re not the regulated party here. Plugin developers are. But the way this plays out in practice affects every WordPress site owner in Europe, and many outside it.

The reason the CRA exists is that plugin security has been badly managed at scale. In 2025, 46% of WordPress plugin vulnerabilities did not receive a fix from the developer before the vulnerability was made public. Nearly half of all discovered security issues were left unpatched while the information was already out there. The CRA is designed to force that number down by making disclosure and patching legally required.

What changes for you specifically:

You’ll get notified when your plugins have security problems. Under the current system, developers often fix things silently. You might update a plugin and have no idea that the update patched a critical security flaw. From late 2026, developers serving EU users must notify affected users when an actively exploited vulnerability exists.

Abandoned plugins become a legal liability for developers. A plugin that stops receiving updates doesn’t just become a security risk. Under the CRA, if that plugin is still available to EU users, the developer remains responsible for maintaining it. Expect to see more developers formally declaring end-of-life timelines rather than just quietly disappearing.

The plugin ecosystem will consolidate. Small developers or hobbyists with commercial plugins who don’t have the resources to maintain a formal VDP, file reports within 24 hours, and produce SBOM documentation may pull their plugins from the EU market or from WordPress.org entirely. This could affect plugins you currently rely on.

Could Plugins Be Pulled From WordPress.org?

Yes, and this is the part most coverage glosses over.

EU market surveillance authorities have the power to require that non-compliant products be removed from any platform accessible to EU users. WordPress.org is accessible to EU users. That means a plugin that doesn’t comply with the CRA could be ordered off the repository, even if it’s free and used by hundreds of thousands of sites.

This isn’t a certainty for any specific plugin. But it’s a real risk for plugins with no active developer, no published security contact, and no VDP. If you’re running a site that depends on a plugin that hasn’t been updated in two years and shows no sign of CRA preparation, that’s worth factoring into your planning.

The practical question to ask about any plugin you rely on: does the developer have a published security contact or vulnerability disclosure policy? If you can’t find one and the plugin has EU users, that developer has work to do before September.

What About UK Websites?

The UK left the EU, so the CRA doesn’t directly apply to UK domestic law. The thing is, it still matters for most UK site owners and developers.

If you’re a UK developer and your plugin is available to EU users, the CRA applies to your product regardless of where you’re based. You’re in scope. The law is triggered by where the product is available, not where you are.

If you’re a UK site owner using plugins from developers who sell to EU customers (which is nearly all of them), the practical effects of the CRA will still reach your site. Developers who comply will change how they handle security disclosure. Developers who don’t comply may pull EU availability, which could affect plugin distribution more broadly.

The honest read: UK developers with any EU user base should treat CRA compliance as required. The extraterritorial reach of the regulation makes the Brexit distinction largely irrelevant in practice.

What Should You Do Right Now?

You can’t force plugin developers to comply. But you can reduce your exposure to the fallout if they don’t.

Audit your installed plugins. Remove anything you’re not actively using. Fewer plugins means fewer compliance risks and a smaller attack surface. If a plugin hasn’t been updated in six months or more, check whether the developer is still active and whether they have a published security contact.

Check for vulnerability disclosure policies on plugins you rely on. Larger plugins from established developers (Yoast, WPForms, Elementor, and similar) are likely to be CRA-ready or close to it. Smaller plugins from solo developers with no visible security contact are higher risk.

Consider managed hosting with automatic security updates. If your host applies security patches automatically and includes server-side malware scanning, you have a baseline of protection that doesn’t depend entirely on developer compliance. Our backup guide covers the recovery side of the equation.

Keep your own backups. If a plugin you depend on gets pulled from WordPress.org or goes abandoned ahead of a CRA deadline, having a recent clean backup gives you options. That’s true regardless of this regulation, but the CRA makes it more timely.

A web application firewall won’t protect against a vulnerable plugin that hasn’t been patched. But it does reduce the automated scanning and exploit attempts that target known vulnerabilities while you’re waiting for a fix.

Common Questions About the CRA and WordPress

Does the CRA apply to free WordPress plugins?

It depends on whether there’s any commercial element. A plugin with a pro version, advertising on its website, paid support, or donations that influence development is in scope even if the base plugin is free. Purely non-commercial open source projects with zero revenue connection are exempt, but that’s a narrower category than most people assume.

When does the CRA take effect for WordPress?

The first major deadline is 11 September 2026, when vulnerability and incident reporting obligations begin. Full compliance including CE marking, SBOM, and secure by design requirements is required from 11 December 2027.

Can plugins be removed from WordPress.org because of the CRA?

Yes. EU market surveillance authorities can require non-compliant products to be removed from any platform accessible to EU users, including WordPress.org. This is a real enforcement mechanism, not just a fine.

Does the CRA apply to UK websites and developers?

UK domestic law doesn’t include the CRA post-Brexit. But UK developers whose plugins are available to EU users are in scope regardless of where they’re based. The law applies based on where the product is available, not where the developer is located.

What is a vulnerability disclosure programme?

A vulnerability disclosure programme (VDP) is a published process that explains how security researchers can report vulnerabilities to the developer, how quickly the developer will respond, and how and when they’ll disclose the issue publicly. Under the CRA, having one is mandatory for commercial plugin developers serving EU users from September 2026.