Hey there! Just a quick heads-up: I’m not a lawyer, policymaker, or compliance expert. This post is written from the perspective of a curious layperson piecing together information from various sources. If you think this might apply to you, chatting with a legal professional for proper advice is always a good idea.
Announced in the King’s Speech as coming in 2025, the Cyber Security and Resilience Bill is essentially the UK’s implementation of the EU Cyber Resilience Act (which was legislated in October 2024). Before you jump in, yes, the UK is no longer in the EU, and no, this isn’t some weird Brexit thing. The bill is supposedly going to pretty much mirror the EU Act, which is sort of to be expected. When it comes to information security and governance, the UK remains very much in step with our nearest neighbours. It also simplifies things for UK businesses, many of which would have had to implement these changes if they traded with the EU.
Now you might be thinking, well, this doesn’t affect me:
- I’m a developer who sells plugins/themes.
- I’m part of an agency that develops sites for clients or hosts/provides maintenance.
- I run a marketplace or have a free plugin that others provide paid add-ons.
- I offer plugins/themes for free but have a commercial interest in software.
In all these cases, you are potentially affected by both the new EU legislation and the incoming UK legislation and may have enforceable obligations going forward.
What are the changes?
The EU Cyber Resilience Act, passed in 2024, requires states to legislate statutory obligations regarding information security, with the full obligations coming into force in December 2027. To be clear, the UK version, the Cyber Security and Resilience Bill, is not even fully written yet and has no enforcement date.
These obligations are, by and large, things companies or organisations should already be doing, but now they’re being told they must do them. It’s very similar to the Product Security and Telecommunications Infrastructure Act, which came into force earlier this year in the UK. However, while that act was specific to hardware, this one covers software and services and is generally broader in scope.
If a company or organisation creates or manages products with a digital element, it likely (and here I remind you, I am not a lawyer) needs to consider whether it must comply with the EU Cyber Resilience Act and, therefore, the UK’s Cyber Security and Resilience Bill when/if it passes.
So, what is a product with a digital element?
Good question! It’s not well defined in the European Act, and as the UK Bill hasn’t been published yet (as of December 2024), we don’t know if it will be more tightly defined for the UK.
The EU’s Cyber Resilience Act says:
“intended and foreseeable use includes direct or indirect data connection to a device or network.”
For now, the loosest interpretation is: any software or hardware that has some form of data storage and/or remotely transmits or stores data.
So… basically everything, then.
Even in the more tightly defined interpretations, software like CMSs (e.g. WordPress) and anything web-based appear to be covered by the act.
This means that if you create plugins, themes, custom development work for clients, or resell WordPress maintenance packages, you are probably subject to the EU Act and, most likely, its UK equivalent.
One thing that is important is that if you are an individual developer or group of developers and you have no commercial interests, then you are not obligated to do anything under the act. Except when you are, because laws are never so simple.
(Again, I am not a lawyer. Seek legal advice if you’re unsure whether you might be affected.)
What are the obligations?
1. Demonstrate risk assessment:
Show that you’ve assessed cyber security risks and completed a formal risk assessment. This might align with existing frameworks like Cyber Essentials or an independent approach. You’ll need to document risks not just in your own components but also in subcomponents (e.g. underlying libraries). This includes being able to report vulnerabilities in both your components and their dependencies.
The act emphasises due diligence across the entire supply chain, including libraries used by other libraries. You should be prepared to produce this documentation on demand.
2. Vulnerability reporting:
You may need to share vulnerability reports with centralised bodies like ENISA in the EU (similar to how Common Vulnerabilities and Exposures, CVEs, are created now) – the responsibility for reporting lies with the manufacturer.
3. Ensure vulnerabilities are handled effectively:
- Address vulnerabilities quickly.
- Notify relevant parties of issues within a short timeframe.
- Provide timely updates.
- Maintain a distinct and accessible security support process.
For distributors (potentially agencies or even end-clients hosting software), there’s an obligation to ensure the software they distribute meets these requirements.
Practically, what does this mean?
The first part, risk assessment and documentation, is about formalising informal processes. At a minimum, you should:
- Maintain a list of libraries and third-party software used within your software.
- Ensure these have a security policy and contact methods for reporting issues.
- Conduct regular internal security assessments (or hire a third party, like myself).
- Make as much of this documentation publicly available as possible to demonstrate compliance if you’re a vendor.
Know your vendors.
You’ll need to confirm that your vendors themselves, who would be other manufacturers or distributors, comply with the act. This can get tricky in open-source contexts, where “vendors” might just be individuals. For example, some companies currently rely on libraries maintained by, well, a 12-year-old kid. The European Act does sort of recognise that open source, in particular, is a unique concept and doesn’t match a traditional vendor model, but has limited mitigations in place.
The act has the concept of “open-source software steward”, which refers to legal entities responsible for developing or maintaining open-source software in a business context, such as certain foundations or not-for-profit organisations. Sounds great, though in reality these “stewards” are still expected to act a lot like manufacturers in most instances.
Except of course open-source software doesn’t always have legal entities, indeed such governance is the exception, not the rule.
This complexity extends to pseudo-organisations like WordPress. While Automattic holds the commercial rights on behalf of the WordPress Foundation, neither is legally responsible for compliance.
On paper, WordPress’s “vendor” might be Matt Mullenweg as the sole distributor via wordpress.org, but Matt is an individual and as long as he isn’t making money in any way from WordPress he shouldn’t be subject to obligations.
I sure wouldn’t want that role.
Patching and user support
As part of the European Cyber Resilience Act there is an expectation on how software will be maintained and supported. It puts an emphasis on long-term stability, specifically:
- Manufacturers should support software over long-term cycles. A lot of articles have headlines saying that software must be supported for at least 5 years. The act, while saying software cycles are usually 5 years (based on presumably sticking a thumb in the air and guessing), software that thinks it will have a shorter cycle (like, say, web technologies such as CMS or a plugin) are permitted to have shorter cycles. But you have to say how long you will be supporting the software.
- You do not need to maintain that software to a specific version, so you can still support only the latest version or specified long term support (LTS).
- Security patches must be separated from normal releases (this is something not currently possible if you use WordPress.org infrastructure).
- Security patches should be issued for free, regardless of any existing license agreement.
So, if you sell a plugin or theme, you are expected to support it and be clear about what period of time you are willing to support it. If you sell a plugin that needs a license, you are still expected to provide security updates for free.
I can see tools like Freemius really becoming super useful if they can help manage this requirement.
Vulnerability management
The European Cyber Resilience Act expects you to be proactive with vulnerability disclosures. This includes:
- Providing a clear route for contact (e.g. a “security@” email).
- Publishing a transparent security policy on your project page, website, or via a security.txt file.
- Responding promptly to reports and publishing updates once issues are resolved.
If you’re a WordPress plugin or theme developer, this might sound painful, but tools like Patchstack’s free managed VDP can help. Patchstack is particularly geared toward aligning with the Cyber Resilience Act’s reporting requirements.
So, just to be clear, do you need to have a vulnerability disclosure policy? YES!
Do you need to use a 3rd party tool to manage this? No.
Should you think about using one? Probably, unless you have a process already in place.
So, should you panic?
The Cyber Security and Resilience Bill (not yet law) is designed to align with the EU Cyber Resilience Act, which will be adopted into member states’ laws throughout 2025 and come into force over the following months until full implementation in 2027.
Software developers (including WordPress plugin/theme creators) might find themselves classified as “vendors” or “manufacturers” under the law.
Distributors, including agencies and hosting providers, might also be responsible for compliance.
To comply, you’ll need to:
- Identify risks and vulnerabilities in your software and supply chain.
- Enable and act on vulnerability reporting.
- Consider how you patch and deploy patches.
- Respond and update promptly when vulnerabilities are disclosed.
What might change?
For many, not much, but there will always be exceptions, and it will always be the little folk.
- Individual contributors might face extra paperwork and feel pressure to meet corporate expectations.
- There may be more focus on security and risk management during vendor tendering and sales pitches.
Which is where I come in.
If you have made it this far and don’t know who I am:
My name is Tim Nash. I’m a UK-based cyber security consultant who specialises in WordPress. I also provide vulnerability assessments for organisations like yours.
For organisations in the WordPress space, I can help with two different types of reviews.
A plugin or theme code review that will help fulfil your requirements for doing vulnerability assessments and risk management of your code if you are classed as a manufacturer or distributor. With the added benefit that you get a genuinely useful document to help improve your codebase security, reliability and performance.
A full site review looking at a whole site and how individual components interact with each other as well as user management and processes on the site. These reviews are designed to give you peace of mind that your sites are robust.