If you use Joomla extensions developed and sold by EU-based vendors, wherever you are in the world, the EU Cyber Resilience Act is about to change what those vendors are required to provide you. And if you are an EU-based developer selling extensions, it changes what you are required to provide.
This post explains what the CRA is, what it requires, and what it means in practice for Joomla site owners, agencies and extension developers, inside and outside the EU.
What is the EU Cyber Resilience Act?
The Cyber Resilience Act is an EU regulation that introduces mandatory cybersecurity requirements for all software and hardware products sold in the European Union. It was signed into law on 23 October 2024 and published in the Official Journal of the EU on 20 November 2024 as Regulation (EU) 2024/2847.
The European Commission described its purpose plainly: to ensure that digital products have fewer vulnerabilities, and that manufacturers remain responsible for cybersecurity throughout a product's entire lifecycle, not just at the moment of sale.
The numbers behind the regulation are sobering. According to the European Commission, an estimated two-thirds of cyberattacks exploit known software vulnerabilities, and 60% of products placed on the market at the time the CRA was proposed contained known vulnerabilities. The CRA is designed to change that, structurally, across the entire EU market.
The EU's cybersecurity agency ENISA has noted that the CRA affects manufacturers of all sizes, including small and micro enterprises. If you develop software and sell it commercially in the EU, you are a manufacturer under this regulation.
Key dates
The CRA has a phased timeline:
- 10 December 2024: The regulation entered into force
- 11 September 2026: Vulnerability and incident reporting obligations begin. Manufacturers must report actively exploited vulnerabilities to national authorities (in the Netherlands: the NCSC) within 24 hours
- 11 December 2027: All CRA obligations fully apply. Products placed on the EU market must comply
That second date, September 2026, is closer than it looks. Less than four months away at the time of writing.
Who does the CRA actually apply to?
This is where clarity matters, because the CRA is frequently misunderstood.
The CRA's obligations fall entirely on manufacturers, the companies and individuals who develop and commercially sell software products in the EU. It is a market access regulation: it governs what can be placed on the EU market and under what conditions. It does not regulate website owners, agencies or end users.
If you are a site owner or agency, wherever you are in the world, the CRA does not place any direct obligations on you.
If you are outside the EU and use extensions from EU-based developers, you still benefit fully from the CRA. Because EU-based manufacturers must meet CRA requirements for all their products, not just those sold to EU customers, the security update guarantee, vulnerability disclosure process, and five-year support commitment apply to your purchase too. The protections are built into the product and the commercial relationship, not granted conditionally by geography.
If you are an EU-based extension developer, the CRA applies to you in full, regardless of where your individual customers are located.
What does it mean for Joomla extension developers?
The CRA applies to products with digital elements, which includes software extensions sold commercially. A Joomla extension sold via a subscription or one-time purchase is squarely in scope.
Most Joomla extensions fall into the regular products category, which carries the lightest set of requirements and allows for self-assessment, no third-party certification body required.
For regular products, the CRA requires manufacturers to:
- Conduct and document a cybersecurity risk assessment for their product
- Ship products without known exploitable vulnerabilities
- Provide a secure default configuration
- Provide free security updates for the entire support period; a minimum of five years
- Maintain and publish a Software Bill of Materials (SBOM) listing all software components and dependencies
- Publish a contact point for reporting vulnerabilities (coordinated disclosure)
- Issue an EU Declaration of Conformity and apply CE marking
- Report actively exploited vulnerabilities to the relevant national authority within 24 hours (from September 2026)
The five-year free security update requirement deserves particular attention. It means that if a customer purchased your extension and their subscription has since expired, they are still entitled to receive security fixes, free of charge, for five years from their original purchase. This is a significant shift from how most extension subscription models currently work.
What the CRA does not require of extension developers
The CRA does not require you to backport security fixes to every historical version of your extension. Security updates are released in the current version; users are expected to update. It also does not require you to support installations running on end-of-life platforms. If a site is running Joomla 3 or PHP 7, both long past end of life, the extension developer's security obligations do not extend to that platform. A secure extension cannot compensate for an insecure platform.
The indirect distribution chain, something developers often overlook
Many Joomla extensions are sold to agencies who install them on client websites. This creates an indirect chain that the CRA does not break, but that everyone in the chain needs to understand.
The agency is the license holder. When an agency purchases an extension, they hold the license, not their end client. The end client has no direct commercial relationship with the extension developer. They cannot claim updates or support directly from the developer; their rights run against the agency.
Security updates are available to the license holder. Under the CRA, the extension developer must make security updates available free of charge to license holders for five years. The agency, as license holder, can download and apply those updates, even with an expired subscription, during the support period.
The end client's position when the agency relationship ends. If a maintenance contract ends and no one holds an active license, the end client is in a gap. They are running software that may receive security updates they cannot access. The responsible solution: either the agency transfers or maintains the license, or the end client purchases their own license directly from the developer.
The GPL does not change this. Extensions built on Joomla are GPL-licensed, which means anyone who receives the software can use, modify and redistribute it. But the GPL license does not entitle any party to receive updates, support or security fixes from the original developer. Those services are tied to the commercial relationship, the license account, not to possession of the code.
What does it mean for Joomla site owners?
If you are a site owner using third-party Joomla extensions, the CRA does not place direct obligations on you. But it does give you something valuable: the right to expect that extensions sold in the EU market are secure, maintained, and supported.
From December 2027, you can legitimately ask your extension developer:
- Do you have a published vulnerability disclosure process?
- Is there a CE marking and Declaration of Conformity for this product?
- What is the security support end date for the version I am running?
- Are security updates available to me even if my subscription has lapsed?
If your website was built by an agency and you do not hold a direct license for the extensions used, it is worth asking your agency: who holds the license, and how will security updates reach my site when they are released?
For site owners in regulated industries, healthcare, finance, education, government, the stakes are higher. Your own compliance obligations (NIS2, GDPR, sector-specific regulations) increasingly depend on the security of your software supply chain.
What does it mean for Joomla agencies?
If you build and maintain Joomla sites for clients, the CRA almost certainly does not apply to you directly. Building a website is a service, and the CRA explicitly excludes services from its scope. The obligations for the extensions on that website rest with their respective developers, not with you.
There are two narrow exceptions: if you significantly modify a purchased extension and distribute it under your own agency brand, or if you sell a standardized Joomla site package to multiple clients as a repeatable product, you may be placing a software product on the market and the CRA could apply to that specific product. The test is: are you placing a distinct software product on the market under your own name?
For the vast majority of agency work, you are a specifier and deployer, not a manufacturer. Your CRA responsibility is practical: choose extensions from vendors who are meeting their obligations, and apply security updates to the sites under your management.
The template override problem; a responsibility agencies must own
There is one specific area where agencies carry real responsibility that is easy to overlook: template overrides.
Joomla allows agencies to override extension layout files by placing modified copies in the template directory. This is standard practice for customizing how extensions display, and it creates a maintenance obligation that the extension developer cannot fulfill on your behalf.
When an extension developer releases a security update that changes a layout file, Joomla's update mechanism does not touch your override. The fix is in the extension, but your customized version of the layout file, sitting in the template directory, is still running the old, potentially vulnerable code. The developer has done everything right; the fix is bypassed by your override.
This is not a hypothetical risk. It is a common source of support requests where a site appears to have the latest version of an extension installed, but is still exhibiting the security issue the update was supposed to fix.
The responsibility is yours as the agency: when a security release is published, check the changelog for which layout files changed, and update your overrides accordingly. Responsible extension developers, including OnlineCommunityHub, explicitly flag layout file changes in their security release notes to make this review straightforward.
When ending a maintenance relationship with a client, document the overrides in place and make clear in your handover that keeping those overrides current with future security releases is an ongoing maintenance responsibility.
Does the CRA apply to non-EU extension developers?
Yes, and this is one of the most important and least understood aspects of the regulation.
The CRA is triggered by placing a product on the EU market, not by where the manufacturer is based. A developer in the United States, Australia, India or anywhere else who sells a subscription to an EU customer is placing their product on the EU market. The CRA applies to them in full, including the five-year security update obligation, the vulnerability disclosure requirement, CE marking and the Declaration of Conformity.
This is consistent with how the EU handles other market access regulations. GDPR applies to non-EU companies processing EU residents' data. The same territorial logic applies here: if you want access to EU customers, you comply with EU rules regardless of where you are incorporated.
For non-EU developers with no EU establishment, the CRA includes provisions for appointing an EU authorized representative, similar to the GDPR representative requirement, through whom enforcement can run.
In practice this means that a significant portion of the Joomla extension market, developers based outside the EU who sell to EU customers, is in scope but may not yet be aware of it. As a site owner or agency, this is worth factoring into your extension vendor selection.
How is the CRA enforced, and what about developers who ignore it?
This is a fair question, and the honest answer is: enforcement is complaint-driven and imperfect, but it is more realistic for software than for many physical product categories.
The formal mechanism: enforcement runs through national market surveillance authorities. In the Netherlands that is the RDI. These authorities can investigate complaints, request technical documentation, order products withdrawn from the market, and issue fines of up to €15 million or 2.5% of global annual turnover for the most serious violations.
Why software enforcement is more realistic than, say, consumer electronics from China: a Joomla extension sold via a website leaves a trail. The developer has a domain, a payment processor, a JED listing, a customer base. They are findable. Compare that to a physical product from a factory with no EU presence, where customs enforcement is the only choke point and CE marking can be falsified. Software developers selling subscriptions to EU customers are operating in plain sight.
The JED as an ecosystem enforcement mechanism: the Joomla Extensions Directory is the primary discovery channel for most extensions. If the Joomla project were to require CRA compliance declarations for listed extensions, which is a realistic future development, non-compliant developers would lose visibility immediately. Community-level enforcement can move faster than regulatory enforcement.
The practical reality: initial enforcement will likely focus on significant breaches: an actively exploited vulnerability with no developer response, no security update, no disclosure. Paperwork non-compliance will come later. But enterprise and public sector procurement is already moving faster than regulators: clients in regulated industries are beginning to verify extension compliance as part of their own supply chain due diligence, without waiting for a regulator to act.
Being compliant now means you are already positioned correctly when enforcement tightens, and when the next enterprise client asks the question.
What about open source extensions?
Open source software that is not monetized, genuinely free, with no subscription, no paid support, no donation model beyond cost recovery, falls outside the CRA's scope. The regulation was explicitly amended to protect volunteer open source contributors.
Open source software that is commercially distributed does fall in scope. If there is a subscription, a paid support tier, or a commercial download mechanism, the manufacturer obligations apply. The license (GPL, MIT, etc.) is irrelevant to whether the CRA applies; the commercial model is what matters.
What about Joomla itself?
Joomla is developed and maintained by Open Source Matters, a non-profit. The Joomla core is not commercially sold and has no commercial revenue model. It falls outside the CRA's scope.
The Joomla ecosystem is actively engaged on this topic. The Open Website Alliance, which includes Joomla, Drupal, WordPress and TYPO3, has been working with EU institutions to ensure that the CRA implementation is workable for the FOSS community.
What OnlineCommunityHub is doing
We develop and sell Joomla extensions under a commercial subscription model. The CRA applies to us, and we have been working through compliance for some time.
Concretely, this means:
- We have conducted cybersecurity risk assessments for all our extensions
- We have published a Security & vulnerability disclosure policy including a coordinated disclosure process, vulnerability report form, license chain guidance and template override advice
- We maintain a Software Bill of Materials (SBOM) for each extension
- We have documented our support matrix, which Joomla and PHP versions we support and until when
- We are in the process of issuing EU Declarations of Conformity and CE marking for each extension
- Security updates are always free, even if your subscription has expired, for the duration of the support period
- Security releases that change layout files are explicitly flagged in our changelog so agencies and site owners can identify and update any affected template overrides
We will be the first Joomla extension developer to formally CE mark our extensions under the CRA.
What should you do now?
If you are a site owner (EU or non-EU):
- Note the September 2026 and December 2027 dates
- Ask your EU-based extension vendors whether they are working on CRA compliance
- If your site was built by an agency, ask who holds the extension licenses and how security updates reach your site
- If you are in a regulated industry, flag this to your IT or legal team now
If you are a Joomla agency:
- Review the extension stack you deploy against CRA readiness criteria
- Audit your client sites for template overrides, document them and ensure you have a process for reviewing them against security release changelogs
- Make CRA compliance part of your extension selection criteria
- Ensure license and override maintenance responsibilities are clearly documented in client handovers and contracts
If you are a Joomla extension developer:
- Read the full regulation text, Annex I is the key section for obligations
- Check whether your subscription model needs adjusting to accommodate the free security update requirement
- Start flagging layout file changes explicitly in your security release notes
Further reading
- Regulation (EU) 2024/2847, full text, EUR-Lex (official EU law database)
- Cyber Resilience Act - European Commission, European Commission digital strategy page
- ENISA CRA resources, EU Agency for Cybersecurity
- CRA factsheet, European Commission factsheet (PDF)
- OnlineCommunityHub Security page, our vulnerability disclosure policy, support matrix, license chain guidance and Declarations of Conformity