The EU Cyber Resilience Act is coming. If you run a Joomla agency, building and maintaining sites for clients, the regulation almost certainly does not apply to you directly. But it does change what you should expect from the extension vendors you rely on, and it creates practical responsibilities that are easy to overlook until a client asks an uncomfortable question.
This checklist is designed to help you get ahead of that conversation.
Quick context: what the CRA requires, and who it applies to
The EU Cyber Resilience Act (Regulation 2024/2847) requires manufacturers of software products sold in the EU to meet mandatory cybersecurity requirements, including a minimum five-year security update commitment, a published vulnerability disclosure process, CE marking, and an EU Declaration of Conformity.
The two deadlines that matter most:
- 11 September 2026, Vulnerability reporting obligations begin. Manufacturers must report actively exploited vulnerabilities to national authorities within 24 hours
- 11 December 2027, Full compliance required for all products placed on the EU market
As an agency, the CRA almost certainly does not apply to you directly. Building a website for a client is a service, and the CRA explicitly excludes services from its scope. The CRA obligations for the extensions on that website rest with their respective developers, not with you.
There is one exception worth knowing: if you significantly modify a purchased extension and distribute it under your own agency brand, or if you sell a standardized Joomla site package as a repeatable product to multiple clients, you may cross into manufacturer territory for that specific product. The test is simple: are you placing a distinct software product on the market under your own name? If yes, the CRA likely applies to that product.
For the vast majority of agency work, building and maintaining bespoke client websites using commercially purchased extensions, 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.
Part 1: Review your extension stack
The first step is to understand what you are deploying and whether the vendors behind those products are on a compliance path.
For each commercial extension you regularly use or recommend:
- [ ] Does the vendor have a published vulnerability disclosure contact (email address or form)?
- [ ] Does the vendor publish a support end date for each product version?
- [ ] Is there a published security update policy, specifically, are security updates available to customers with expired subscriptions?
- [ ] Does the vendor maintain a support matrix showing which Joomla and PHP versions are supported, and which are end-of-life?
- [ ] Has the vendor published or announced an EU Declaration of Conformity or CE marking?
- [ ] Does the vendor have a security page or equivalent that documents their cybersecurity practices?
- [ ] Does the vendor explicitly flag layout file changes in security release notes? (See Part 3 on template overrides)
If a vendor cannot answer most of these questions, that is a signal worth noting; both for your own risk assessment and for conversations with clients.
Red flags to watch for:
- Vendors still listing Joomla 3 or 4 as supported (both are end-of-life, Joomla 3 since August 2023, Joomla 4 since October 2025)
- Security updates bundled exclusively into paid upgrades with no exception for expired subscribers
- No public changelog distinguishing security fixes from feature updates
- No response to vulnerability reports within a reasonable timeframe
A note on template engines like YOOtheme Pro: If you use a commercial template engine such as YOOtheme Pro, the same criteria apply to the template engine vendor. YOOtheme GmbH is the manufacturer of YOOtheme Pro and carries the CRA obligations for that product. Using it as a tool to build sites does not make you the manufacturer, but it does mean you are relying on YOOtheme's compliance. Check that your template engine vendors are on a CRA compliance path, just as you would for any extension.
Part 2: Assess your client sites
For active client sites under your maintenance, a quick audit from a CRA readiness perspective is good practice, and a service you can charge for.
For each client site:
- [ ] List all commercial extensions installed, with current version numbers
- [ ] Cross-reference against each vendor's published support matrix; is the installed version within the security support period?
- [ ] Identify any extensions running on end-of-life Joomla or PHP versions
- [ ] Note any extensions where the client's subscription has expired; are security updates still accessible to you as the license holder?
- [ ] Flag any extensions with no published support end date or vulnerability disclosure process
- [ ] Audit template overrides, list all overrides in place and which extension layout files they override (see Part 3)
Part 3: The template override problem, a responsibility agencies must own
This is the most practically important section in this checklist, and the one most agencies have not thought about in a CRA context.
What template overrides are: Joomla allows agencies to override extension layout files by placing modified copies in the template directory (/templates/[template]/html/). This is standard practice for customizing how extensions display. It is a legitimate Joomla feature, but it creates a maintenance obligation that the extension developer cannot fulfill on your behalf.
Why this matters for security: When an extension developer releases a security update that changes a layout file, Joomla's update mechanism does not touch your override. The updated extension is installed, but your customized layout file, sitting in the template directory, is still running the old code. The developer has done everything correctly. Your override bypasses the fix.
This is not a hypothetical scenario. It is a common and recurring issue: a site has the latest version of an extension installed, but is still vulnerable because the layout override was never updated.
Your responsibilities as the agency:
- [ ] Maintain a list of all template overrides across your client sites, including which extension layout files they override
- [ ] When a security release is published by any extension vendor you use, check the changelog for layout file changes
- [ ] If you have an override for any changed file, review and update that override to incorporate the security fix
- [ ] Subscribe to security notifications from all extension vendors whose layouts you override
When handing over a site: If you end a maintenance relationship with a client, your handover documentation should include a list of all template overrides in place and a clear note that keeping those overrides current with future security releases is an ongoing maintenance responsibility. A client who is unaware they have overrides, and therefore unaware of this responsibility, is a client who will eventually have a security problem and trace it back to you.
Choosing vendors with clear release notes: When selecting which extensions to build with, favor vendors who explicitly flag layout file changes in their security release notes. This makes the override review process straightforward. Vague changelogs ("security improvements") make it impossible to know whether your overrides are affected.
Part 4: Understand the license chain
When you install an extension on a client's website, you are the license holder, not your client. This has practical consequences that flow directly from the CRA's security update framework.
What this means:
- Security updates from the extension developer are available to you, the license holder, even with an expired subscription (for the duration of the support period under CRA)
- Your client has no independent access to those updates, their security depends on you applying them
- If your maintenance contract ends and no one holds an active license path, the client is in a gap: running software that receives security updates they cannot access
What to do about it:
- [ ] When ending a maintenance contract, either formally transfer the extension license to the client or ensure they purchase their own license directly from the vendor
- [ ] Document in your handover which extensions are installed, who holds the license, and how the client can access future updates independently
- [ ] Include license transfer or continuity provisions in your maintenance contract terms
The GPL does not help here: Joomla extensions are GPL-licensed, which means anyone who receives the code can use it. But the GPL license does not give anyone the right to receive updates, support or security fixes from the original developer. Those services are tied to the commercial license relationship. A client running a GPL extension without a license account has the code but no path to the developer's security updates.
Part 5: Update your agency processes
Extension selection:
- [ ] Add CRA compliance status to your extension evaluation criteria
- [ ] Create a preferred vendor list of extensions whose developers are actively working toward CRA compliance
- [ ] Favour vendors who publish explicit layout file change notices in security release notes
Client onboarding:
- [ ] Add a section to your client onboarding documentation covering the extensions used, their support periods, and who holds the licenses
- [ ] Make clear what ongoing maintenance responsibilities transfer to the client when a contract ends, specifically template override maintenance and license continuity
Ongoing maintenance:
- [ ] Subscribe to security notifications from all extension and template engine vendors you use
- [ ] Add a template override review step to your security update process
- [ ] Keep a log of security updates applied and overrides reviewed, useful documentation if a client faces a security incident
Custom development:
- [ ] If you develop custom extensions or significantly modified versions of existing extensions that you deploy under your own name to multiple clients, review whether the CRA applies to that work
- [ ] If a client will distribute or resell a custom extension you build, ensure your contract assigns CRA manufacturer responsibilities clearly
Part 6: Talk to your clients
The CRA is an opportunity to have a proactive, credible conversation with clients, especially those in regulated industries.
Who to prioritise: Clients in healthcare, education, finance, government, or any sector with its own compliance obligations (NIS2, GDPR, sector-specific regulations).
Talking points that resonate:
"From December 2027, EU law requires that the software extensions on your website meet minimum cybersecurity standards, including a commitment to security updates for at least five years. We have reviewed the extension stack on your site and can confirm which vendors are on a compliance path."
"We only use extensions from developers who publish their security support policy and are working toward CRA compliance. This protects you from running unsupported software."
"When we build custom features for your site, we document what was built and flag any ongoing maintenance responsibilities, so you are never left with undocumented code you do not understand."
Summary: the 10 most important actions
- Audit the extensions you deploy against the CRA readiness criteria in Part 1
- Inventory all template overrides across your client sites, document them now
- Build a template override review step into your security update process
- Subscribe to security release notifications from all vendors whose layouts you override
- Document license ownership clearly in client contracts and handovers
- Ensure clients have a path to security updates when maintenance contracts end
- Add CRA compliance to your extension selection criteria
- Review your Joomla and PHP version policy, EOL platforms undermine extension security guarantees
- Proactively discuss CRA readiness with clients in regulated industries
- Follow EU and ENISA guidance as the December 2027 deadline approaches
Resources
- Regulation (EU) 2024/2847 - full text
- European Commission CRA page
- ENISA - EU Agency for Cybersecurity
- Joomla CMS version support dates
- OnlineCommunityHub Security page, including template override guidance, license chain information and Support matrix