Cyber Resilience Act: "it is open source" does not exempt you if you build commercially on WordPress, PrestaShop or Magento
by Claudiu Hulea · IT Management Consultant
“It is open source, not my problem” is exactly the mistake the Cyber Resilience Act cuts through. If your company builds commercially on WordPress, PrestaShop or Magento, meaning it sells plugins, themes and modules or builds sites and shops for EU clients, the CRA can make you the manufacturer of what you ship, with everything that entails. The open-source core is not your responsibility; what you build and ship commercially on top of it is. And in Romania, where a large part of the web and e-commerce industry lives on these platforms, the exposure is huge.
What is in scope and what is not
The CRA’s key distinction is not “open source or not”, but “commercial activity or not”.
The open-source projects themselves, WordPress, PrestaShop, Magento as software, are not your problem. Software developed outside a commercial activity is largely out of scope, and the organisations that maintain these projects have a special, lighter role of “open-source steward”.
What is in scope is what you do commercially with them, and here the price does not matter, the commercial intent does. A free plugin that has a pro version, collects data, shows ads or is company-maintained is in scope. A plugin or a theme sold on a marketplace makes you a manufacturer with full obligations.
When you become a manufacturer
There are a few situations in which the CRA treats you as the manufacturer of the product, even if the core is someone else’s.
You sell a plugin, a theme or a module. Commercially, directly or through a marketplace. You are the manufacturer of that product.
You build bespoke for an EU client. Software made to order and delivered commercially to a client is in scope. “It is only for one client” does not save you.
You integrate components into a product you place on the market. If you assemble modules, themes and your own code into a product delivered to the client, you are an integrator, and the CRA considers you the manufacturer of the assembled product.
You substantially modify an existing product. A change after the product was placed on the market that affects its security compliance or the purpose for which it was assessed makes you the manufacturer of that version, with full obligations.
The most exposed case: those who modify the core
I have seen companies that modify the core directly, for example the Magento core, not through modules and overrides, but by editing the code. It is the most exposed case under the CRA, for two reasons that add up.
First, it is substantial modification in its clearest form: you changed the product, so you are the manufacturer of your version.
The second reason is more practical and more painful. When you edit the core, you sever your upstream update path. You can no longer cleanly apply the security patches the project releases, because you have diverged from its code. Exactly when the CRA requires you to deliver security updates over the whole support period, you are the one who has to reproduce every fix by hand, alone, on your version. It is a debt you create for yourself, and the law now makes it mandatory.
What is required, and from when
Two moments matter.
From 11 September 2026, already: reporting. If a vulnerability in your product is actively exploited or you have a severe incident, you report it to the national CSIRT and ENISA within 24 and 72 hours. It applies even to what you have already delivered. Concretely, if a plugin or a core you deployed for a client has an exploited vulnerability, the reporting obligation can be yours.
From 11 December 2027: the manufacturer obligations. Security by design, vulnerability handling and coordinated disclosure, an SBOM that says what the product is made of, security updates over the support period, and conformity assessment with CE marking for new products.
For products already on the market before 2027, a substantial modification does not force you to bring the whole product into CRA compliance, but the reporting obligation remains.
Why Romania is exposed
A very large part of Romania’s web and e-commerce development runs on WordPress, PrestaShop and Magento: agencies, freelancers and product companies that sell plugins and themes or build shops for clients across the EU. The comfortable assumption is “we use open source, so it is not our responsibility”. The CRA says the opposite: the moment you make money placing a digital product on the EU market, you owe its security, whatever it is built on.
What to do now
- Map your role on each delivery: are you selling a product, integrating, or substantially modifying? Each can make you a manufacturer.
- Know your dependencies. You ship other people’s code on top of yours, and you are responsible for the security of the assembled product. An SBOM is the starting point.
- Do not edit the core. Use modules, overrides and extension points, so you can take the upstream security patches. It is both good practice and, now, a compliance defence.
- Start a vulnerability handling and coordinated disclosure process: a reporting channel, a security contact, a procedure. For the WordPress ecosystem there are dedicated platforms, some free and supported by the European Commission.
- Define each product’s support period and how you deliver security updates across it.
- Put it in contracts. Clarify with clients and subcontractors who is the manufacturer, who maintains and who reports.
What to take away
“It is open source” is not a shield, it is a foundation you build on, and a free foundation does not move the responsibility away from you. The moment you commercially ship a digital product in the EU, you are responsible for its security across its whole lifetime, however much of it comes from projects you did not write.
This is not legal advice, and the CRA’s application depends on your specific situation; the European Commission has already published guidance that clarifies scope and is worth reading. But the right reflex is clear: do not assume you are out of scope because you use open source. Verify, exactly as with any security control.
Want to know whether your deliveries on WordPress, PrestaShop or Magento fall under the CRA, in what role and what you have to prepare? Get in touch and we start from a review.
Sources
Frequently asked questions
If I use open-source software, am I outside the CRA?
Not automatically. The CRA distinction is not open source or not, but commercial activity or not. The open-source projects themselves (WordPress, PrestaShop, Magento as software) and software developed outside a commercial activity are largely out of scope, and the organisations that maintain these projects have a lighter open-source steward role. But what you build and ship commercially on top of them can make you a manufacturer, with full obligations.
When do I become a manufacturer under the CRA?
When you sell a plugin, a theme or a module, even a free one if it has a pro version, collects data or is company-maintained. When you deliver bespoke software commercially to an EU client. When you integrate components into a product you place on the market. And when you substantially modify an existing product, for example changing its security posture or purpose; then you become the manufacturer of that version, with full obligations.
What does it mean that I modify the Magento or WordPress core?
It is the most exposed case. A core change that alters the product's security posture or purpose is a substantial modification, so you become the manufacturer of that version. On top of that, you sever your upstream update path: you can no longer cleanly apply the project's security patches, exactly when the CRA requires you to deliver updates over the whole support period. You end up responsible for every fix, alone.
What must I do and from when?
From 11 September 2026, already: report actively exploited vulnerabilities and severe incidents within 24 and 72 hours, including for what you have already delivered. From 11 December 2027: the manufacturer obligations, meaning security by design, vulnerability handling and coordinated disclosure, an SBOM, updates over the support period, and CE marking for new products. Map your role on each delivery and start a vulnerability handling process now.
