Cyber Resilience Act: What Applies to WordPress from Sept 2026

As of this week, the EU Cyber Resilience Act is no longer an announcement: since 11 September 2026, manufacturers of connected products must report actively exploited vulnerabilities and severe security incidents within 24 hours. That sounds like a topic for software corporations – but it hits the ecosystem your WordPress site stands on: plugins, themes, page builders, shop extensions.

The good news first: as the operator of a business website, you generally have no obligations of your own under the CRA. A website is not a “product with digital elements” that you place on the market. The less good news: the ecosystem underneath your site is changing – and you should know about it before it surprises you.

One thing up front: we are developers, not lawyers. This article explains what is coming for WordPress sites technically and practically – the legal assessment of your individual case belongs to your lawyer or data protection officer.

What the Cyber Resilience Act is

The CRA – formally Regulation (EU) 2024/2847 – is the first EU law that makes cybersecurity binding for practically all “products with digital elements”: software and connected hardware offered on the EU market. It has been in force since December 2024, and its obligations phase in:

• Since 11 September 2026: reporting obligations under Article 14. Manufacturers must report actively exploited vulnerabilities and severe security incidents – an early warning within 24 hours, a detailed notification after 72 hours, and a final report after 14 days (vulnerabilities) or one month (incidents). Reports go to the national CSIRT authority and the EU cybersecurity agency ENISA. Importantly, this also covers products that were already on the market beforehand.
• From 11 December 2027: the main obligations – security by design, conformity assessment, CE marking, and a duty to provide security updates throughout the support period.

Violations are expensive: fines of up to 15 million euros or 2.5 percent of global annual turnover, plus potential sales bans and recalls.

Who the CRA affects – and who it doesn’t

Manufacturer obligations apply to anyone who develops products with digital elements and offers them on the EU market – regardless of where the company is based. For the WordPress ecosystem, that means:

Affected: commercial plugin and theme vendors. Even a free plugin falls under the obligations if a company maintains it or earns money with it indirectly – the widespread freemium model of a free base plugin plus a paid Pro version is exactly this case.

Lighter regime: organisations that maintain open-source software long-term without commercialising it count as “open-source stewards” – with significantly reduced obligations, but not zero obligations.

Exempt: purely non-commercial open-source development, such as a solo developer’s hobby plugin with no business model behind it.

Not directly affected: you as an operator. Your website is a service, not a product placed on the market. Watch out only if your company distributes software itself – more on that below.

What actually changes for your WordPress site

Even without obligations of your own, the CRA changes the conditions your site runs under – in three ways:

1. Vulnerabilities become public faster. When manufacturers must report actively exploited gaps within 24 hours, the time between discovery and public knowledge shrinks. That is good for security overall – but it also shortens your reaction window. A known vulnerability in a popular plugin is typically exploited within hours of disclosure. If you apply updates “once a month, when there’s time”, you are playing against a clock that just got faster.

2. The plugin market will thin out. Reporting processes, documentation, and – from 2027 – conformity assessment cost vendors money. Not every two-person project will go along with that: some vendors will pull their products from the EU market, others will abandon them entirely. Orphaned plugins have always existed; the CRA will increase their number. And a plugin without a vendor gets no more security updates.

3. Well-maintained vendors become easier to recognise. The flip side is positive: vendors who take the CRA seriously will document their security processes more visibly – update policy, support period, reporting channels. That makes selection easier: “who is actually behind this plugin?” gets a verifiable answer.

What you should do now

Not a panic checklist – just what has always been good practice, now with added weight:

1. Take a plugin inventory. Which plugins and themes run on your site, who is behind them, when was the last update? Anything that has not seen an update in over a year, or whose vendor is no longer reachable, belongs on the replacement list.
2. Choose vendors built to last. For every new install: is there a company behind it, a documented update history, a channel for reporting vulnerabilities? Those were always good questions – from now on, they separate the vendors who will stay from those who will leave.
3. Take update discipline seriously. Less time between disclosure and exploitation means applying updates promptly and in a controlled way – critical updates via a staging environment, not blindly automatic. We covered how to use auto-updates sensibly separately.
4. Close the gap between disclosure and patch. The most dangerous window sits between “vulnerability is public” and “update is applied”. Virtual patching – as we use it with Patchstack in our WordPress maintenance – blocks known attack patterns automatically, often before the vendor has even released an update. The CRA makes exactly this bridge more valuable, not less.
5. Prepare for the worst case. Tested backups and a clear procedure in case your site does get compromised remain the safety net under everything else.

Special case: you sell plugins or themes yourself

If your company offers WordPress extensions commercially – including a free plugin with a paid Pro version – you are most likely a manufacturer under the CRA yourself. In that case the reporting obligations have applied to you since 11 September 2026, and the main obligations follow by the end of 2027. This is its own topic with real legal weight: have your classification reviewed by a lawyer, and start with what will be mandatory anyway – a documented process for handling vulnerability reports.

An honest conclusion

The CRA demands nothing from you as a site operator – and still changes the rules your site stands on. Vulnerabilities will surface faster, the plugin market will thin out, and the question “who actually maintains this?” moves from nice-to-know to a basic requirement. If your site is maintained regularly – by you or someone else – the CRA adds nothing to your to-do list. If it has been running untouched for years, you now have a concrete reason to change that.