EU Cyber Resilience Act (CRA) Explained: What WP Agencies & Developers Need to Know

You don’t need to know the full text of the EU’s Cyber Resilience Act to feel its presence. If you build or maintain WordPress software (with a commercial intent) and it’s used in the EU, this law most likely applies to you. 

The CRA expects you to know what dependencies your code includes. You’re expected to have a process in place when someone reports a vulnerability. You’re expected to separate security updates from everything else. And yes, if something gets exploited, you have a deadline for reporting it, just like every other digital product vendor in Europe.

The CRA won’t just affect plugin developers. It affects theme shops, freelancers, agencies, and people who maintain stacks of client sites using code they didn’t write. It affects marketplaces. It affects everyone who distributes software in a way that reaches EU users. The difference is that some developers will have a system for dealing with these obligations. Most won’t.

You don’t have to overhaul everything at once. But you do need to know what changes are coming, what your responsibilities are, and what minimum expectations you’ll be judged against.

That’s what this article is about.

What Is the EU Cyber Resilience Act (CRA)?

The Cyber Resilience Act (CRA) is a European regulation that introduces mandatory cybersecurity requirements for all digital products sold or distributed within the EU. That includes both hardware (like routers or smart devices) and software, and includes the manufacturer’s remote data-processing solutions only where those solutions are essential for the product to function (general SaaS is out of scope).

The CRA was formally adopted by the European Parliament in March 2024 and by the Council of the EU in October of the same year. The law applies to all products with “digital elements” that can connect to a network, including open-source software, plugins, apps, and embedded systems.

The CRA addresses two main gaps:

1. The overall lack of built-in security and reliable updates across digital products.
2. The lack of transparency: users often don’t know if a product is secure, or whether the vendor will actually fix vulnerabilities.

To address these issues, the law introduces two sets of requirements:

• Security during development and product design.
• A formal vulnerability handling process, including disclosure and patching.

These rules apply across the product’s lifecycle. Updates, incident response, and documentation are all in scope. If your product is used in the EU, regardless of where you are based, and has any commercial element, CRA compliance will be mandatory by December 2027.

Scope source: Cyber Resilience Act, Article 2

How the CRA Affects WordPress Developers & Plugin Authors

The CRA applies to any product with digital elements offered in the EU. That includes WordPress core, plugins, themes, and even SaaS tools if they process data remotely. It doesn’t matter whether the product is paid or free, open-source or proprietary. If it’s used in the EU and has a commercial element, directly or indirectly, it falls under the regulation. And that’s why this law reaches into every layer of the WordPress ecosystem.

Plugin developers are “manufacturers” under the CRA. If you ship a plugin that has a pro version, collects data, supports ads, or is maintained by a company, you’re in scope. The same goes for theme developers and service providers. Even if the plugin itself is free, the CRA still applies if there’s commercial intent behind how it’s offered.

There’s a common misunderstanding that open-source software is excluded. It’s not.

The CRA introduces a separate term, “open-source stewardship,” to describe the role played by organizations like the WordPress Foundation. But WordPress itself currently lacks that kind of structured stewardship. There’s no central coordination point for how plugin vendors manage disclosures, security reporting, or incident response. That responsibility is fragmented, often left to individual developers or small teams.

And that brings up a deeper problem. One of the CRA’s requirements is that developers must notify users and ENISA when a vulnerability is being actively exploited. But in most WordPress setups, plugin developers have no way of knowing who their users are. If your plugin is downloaded from WordPress.org or installed through a platform like WordPress.com, you might not know who your users are. However, the law expects you to notify users. But the way WordPress is structured, you can’t.

That disconnect hasn’t been solved yet, and it can’t be solved by a single plugin author. It’s the kind of problem that requires changes at the ecosystem level: coordinated security flags, structured metadata in the plugin repository, and a shared understanding of who owns what responsibility.

From mid-2026, products will be expected to follow formal vulnerability handling procedures. That includes having a clear point of contact for security reports, a documented disclosure timeline, and a patching process. By late 2027, the complete requirements kick in: lifecycle security, CE marking, update traceability, and more.

Developers need to adopt formal processes for handling vulnerabilities. The WordPress.org plugin directory will need to support security flags and update labels. The Foundation will need to provide guidance or step into a clearer stewardship role. The broader community will also need to become familiar with new terms, including SBOMs, incident reporting, audit documentation, and others.

The timeline is short, and the obligations are specific. Everyone building on WordPress, plugin teams, theme shops, agencies, and even solo maintainers, should start reviewing how they’ll meet them.

What WordPress Developers Need to Do

If you are a WordPress plugin and theme author, here’s a short checklist that you can follow:

1. Keep detailed changelogs and update records so you can trace when and how security issues were resolved.
2. Let users know when an update contains a security fix (For example, through release notes or dashboard/admin notices).
3. Use dependency monitoring tools such as WP Umbrella  to catch vulnerable packages early.
4. Aim to address and acknowledge critical vulnerability reports within 24–72 hours.
5. Set up a clear security disclosure policy (for example, by adding a SECURITY.md file to your repository).
6. Provide security updates separately from feature updates where technically feasible, and free of charge, with clear advisory messages.
7. Designate a single security contact and include it in user instructions.
   

CRA Compliance for WordPress Agencies & Care-Plan Providers

Agencies aren’t just bystanders in this shift. If you manage client sites, build custom themes or plugins, or offer care plans that include updates and security monitoring, the CRA has direct implications for how you work and what you’re responsible for.

The most obvious risk lies in custom development. If your team builds any plugin, module, or theme, no matter how small, that gets deployed to a client site in the EU, you’re not just a service provider.

Under the CRA, you’re now a “manufacturer.” That means you’re expected to follow secure development practices, document your work, and provide a vulnerability handling process. If one of your modules is exploited, you may have 24 hours to notify EU authorities (ENISA) and two weeks to resolve it.

But even if you don’t write code, you’re not off the hook. Most agencies act as distributors or importers when they deploy third-party software. That includes installing plugins from WordPress.org or bundling themes with new builds. In those roles, you’re expected to verify that the products you use meet CRA standards. 

That doesn’t mean auditing every line of code, but it does mean knowing where the Software Bill of Materials (SBOM) lives, understanding how security updates are handled, and keeping that documentation on file. You don’t have to create SBOMs, but you do need to be able to retrieve them.

For care-plan providers, the implications are even more immediate. CRA sets expectations for how fast security incidents must be handled. That means separating feature updates from security patches is a legal necessity. If a plugin you manage has a critical vulnerability that’s being actively exploited, it’s not enough to wait for the next monthly sprint.

You’ll need to update the site and possibly coordinate with the plugin vendor, your client, and regulatory contacts within hours. That shift will also impact how you communicate with clients. Security updates will need to be prioritized, documented, and, in some cases, archived.

Care-plan reports may need to include references to when security patches were applied. You may also need to collect and retain documentation, such as risk assessments, update logs, and mitigation steps, for any software you interact with.

There’s also a broader risk: many agencies build one-off solutions using free plugins and quick integrations that no longer meet CRA standards. If you’re deploying a free plugin that hasn’t been updated in years, doesn’t disclose vulnerabilities, or lacks SBOMs, you’re introducing legal risk to your client and to yourself.

Like plugin developers, agencies need to start thinking in terms of traceability. Which software runs on which sites? When was it last updated? Is there documentation available if it breaks or gets breached? Who owns the patching process? Right now, that kind of information is scattered across spreadsheets, emails, and staging servers. Under CRA, that won’t be enough.

Agencies that provide care plans or manage websites on behalf of clients will need to adapt their stack, their workflows, and their documentation habits. They will have to treat maintenance like a compliance service, not just a support retainer.

CRA Penalties and Fines for Non-Compliance

The Cyber Resilience Act (CRA) introduces serious enforcement mechanisms for non-compliance.

Fines and Financial Penalties

• €15 million or up to 2.5% of global annual turnover (whichever is higher) for failure to meet essential security requirements (e.g., secure-by-design, vulnerability handling).
• €10 million or 2% of global turnover for breaches of other obligations (documentation, incident reporting).
• €5 million or 1% of turnover for supplying false or misleading information.

(Source: CRA Article 64)

Importantly, member states have the authority to impose additional consequences, such as recalling a non‑compliant product or ordering its withdrawal from the EU market.

How Proactive WordPress Security Can Help

At its core, the CRA demands proactive protection. It wants digital elements “secured by design”. It expects measures that reduce the attack surface before vulnerabilities are exploited.

For agencies and care-plan providers, that means going beyond malware scans and cleanup services. You need systems in place that block known threats, enforce secure defaults, and create a traceable record of how vulnerabilities are handled.

This is where tools like WP Umbrella’s Site Protect add-on can be valuable. It brings together a set of safeguards that directly map to the CRA’s expectations around vulnerability handling and lifecycle security:

• Virtual patching blocks known vulnerabilities even if a plugin or theme hasn’t yet been updated, closing the gap between disclosure and patch release.
• Continuous monitoring and threat reporting provide the kind of audit trail agencies might need when demonstrating to clients (or regulators) that vulnerabilities are being tracked and mitigated.

Because it consolidates multiple layers of defense into a single lightweight solution, Site Protect helps agencies replace a patchwork of plugins with a structured, auditable process. Combined with WP Umbrella’s performance and uptime monitoring, bulk update management of plugins, themes, and WordPress core, update logs, and GDPR-compliant backups, agencies can stop vulnerabilities before they escalate.

It’s important to be clear: no tool can deliver “compliance in a box.” The CRA is as much about processes (incident reporting, SBOMs, and disclosure timelines) as it is about technical safeguards. But by adopting proactive security measures like virtual patching and automated hardening, agencies put themselves in a stronger position to meet those requirements while protecting their clients in real time.