The EU Cyber Resilience Act: What It Actually Means for Your WordPress Project

The deadline nobody is talking about

If you’ve read anything about the EU Cyber Resilience Act, it was probably about December 2027, when the regulation applies in full. That is the headline date. There is an earlier one that matters more in day-to-day practice, and it is close: September 11, 2026.

From that day, anyone who makes “products with digital elements” and sells them in the EU must report actively exploited vulnerabilities and severe security incidents to ENISA and their national CSIRT. The timelines take some getting used to. You have 24 hours from the moment you learn about active exploitation to file an early warning. 72 hours for the full notification. Then a final report once the fix is out.

Everything goes through one EU-wide system, the CRA Single Reporting Platform, and lands with the CSIRT of the country where the company is based. In our case that would be the Czech one.

Does this even apply to WordPress?

More than most people in the ecosystem seem to realize. The CRA covers basically any software or hardware sold commercially in the EU.

If you sell a commercial WordPress plugin or theme to European customers, the regulation treats you as a “manufacturer”, with every duty that word carries.

Custom client software is murkier. A lot depends on how exactly the product reaches the market, and lawyers will be arguing about edge cases for years. The general direction is hard to miss though.

Open source gets an exemption while it stays non-commercial. Add monetization and the exemption starts to erode.

As for what happens if you ignore all this: fines go up to €15 million or 2.5% of total worldwide annual turnover, whichever hurts more. Nobody expects regulators to open with maximum penalties, but the ceiling is there for a reason.

The part vendors underestimate

The reporting duty only covers vulnerabilities that are actively exploited: real attacks against real installs, not a proof of concept someone posted on GitHub. That sounds like a narrow trigger. In the WordPress world it isn’t, because serious flaws now get mass-exploited within hours of disclosure. Active exploitation is the normal condition of a published WordPress vulnerability.

And there’s a trap built into Article 14 that regulators understood earlier than most vendors did. You can’t report what you never noticed. A plugin shop with no disclosure channel, no monitoring and no idea what libraries it ships can end up in breach without having concealed anything at all, simply because it had no way of knowing.

So the realistic pre-September checklist for anyone shipping software into the EU:

1. Keep a current list of components you ship (an SBOM, in compliance-speak).
2. Publish a security contact so researchers can actually reach you.
3. Track your dependencies. The CRA even includes an upstream notification duty toward component maintainers, so vulnerability news travels both ways along the supply chain.
4. Decide in advance who writes the 24-hour report and who signs off on severity. Preferably before it’s 2 a.m. on a Saturday and you’re finding out your process doesn’t exist.

And if you just run sites?

Then the CRA doesn’t hand you any reporting duties directly. What it will do is reshape the plugin market around you. Commercial vendors will get more serious about disclosure. Some smaller ones will look at the compliance overhead and quietly stop selling to the EU instead, and a plugin abandoned over paperwork is exactly as dangerous as one abandoned for any other reason. It’s worth asking your paid vendors now what they intend to do by September; the ones without an answer are the ones to replace first.