From December 2026, Your Shopware Plugin Is a Product: The New EU Product Liability Directive

• by Tobias Schäfer • 14 min read
#Shopware #Plugin Development #Recht #E-Commerce

On 9 December 2026, software becomes a product in the sense of EU product liability law. That includes the plugin you sell in the Shopware Store and the custom module your agency wrote for one client. Directive (EU) 2024/2853 replaces the directive from 1985, which was written for toasters and ladders and never said clearly whether software counted.

Most articles I’ve read about it since the summer stop there, and the tone is somewhere between “new risk for every developer” and “get insurance now”. I read the directive itself, and the German law that implements it, and I think the direct risk for a typical Shopware plugin is smaller than that. The people who can sue you under it are rarely your customers. The pieces that will actually change how you work are the update rules and the Cyber Resilience Act, which hooks into product liability through a presumption.

This post is for Store vendors, agencies and freelancers who write Shopware code. Status: 9 October 2026.

I’m a developer, not a lawyer, and this post is not legal advice. It’s my reading of the directive, the German implementing law and a handful of law firm publications. National courts haven’t decided a single case under the new rules yet, so several points below are interpretation. Have your contracts and your insurance checked by someone who is qualified and liable for it.

What changes on 9 December

The directive applies to “products placed on the market or put into service after 9 December 2026” (Art. 2(1)). Everything placed on the market before that stays under the old directive (Art. 21). The German law spells it out: the old ProdHaftG keeps applying to products placed on the market up to and including 8 December.

Software is a product. Recital 13 says this applies “irrespective of the mode of its supply or usage”, so it covers software on a device, software accessed through a network, and software “supplied through a software-as-a-service model”. A Shopware plugin is in, and so is a Shopware app whose logic runs on your own server.

The liability is strict. The injured person has to prove the defect, the damage and the causal link, but not fault. Four things make that easier for them than it used to be:

  • Courts can order the manufacturer to disclose evidence once the claimant has made the claim plausible (Art. 9). If you don’t disclose, the defect is presumed (Art. 10(2)(a)).
  • Defectiveness is presumed if the product doesn’t comply with mandatory safety requirements under EU or national law that protect against the kind of damage that occurred (Art. 10(2)(b)). This is where the Cyber Resilience Act comes in.
  • Where technical complexity makes proof “excessively difficult”, the court presumes defect and causation as soon as the claimant shows they are likely (Art. 10(4)). Software is the textbook case for that.
  • The old €500 deductible for property damage and the optional cap (Germany had set it at €85 million) are gone. Recital 56 explicitly rules out “financial ceilings”.

And you can’t contract out of it. Art. 15: liability towards the injured person may not be “limited or excluded by a contractual provision”. Whatever your terms say about liability, they don’t touch this.

Who can actually sue a plugin vendor

This is the part most summaries skip, and for B2B software it’s the most important one.

Only natural persons can claim (Art. 5). And only for three kinds of damage (Art. 6):

  1. death or personal injury, including medically recognised damage to psychological health,
  2. damage to property, except the defective product itself and property “used exclusively for professional purposes”,
  3. destruction or corruption of data “that are not used for professional purposes”.

A merchant whose checkout plugin double-charged customers for three days has no claim under the directive. The shop is run by a company, the shop data is used for professional purposes, and lost revenue is pure economic loss, which recital 24 excludes along with “privacy infringements”. That case stays where it always was: in your contract with the merchant, or for Store plugins in Shopware’s terms, plus tort law.

A data leak isn’t covered either. Recital 20 separates “destruction or corruption of data” from “data leaks or breaches of data protection rules” and leaves the latter to the GDPR. So a vulnerability in your plugin that lets someone skim card data or dump the customer table is a GDPR and contract problem, but not a product liability one. (The fact that the skimming happened through your code doesn’t change the type of damage.)

What’s left are the shop’s customers, the consumers. They can claim if your plugin destroys or corrupts their private data and they can’t restore it for free (recital 20 says a backup means no loss). Think of a personalisation plugin that stores the photos a customer uploads for a printed mug, or a plugin that manages a customer’s saved configurations, and then deletes or mangles them. Personal injury is rarer still in e-commerce. The scenario I keep coming back to is a plugin that displays allergen or dosage information and shows the wrong values because of a bug. Whether a court treats that as defective software or as faulty information (which recital 13 says is “not a product”) is something I don’t know, and I haven’t found a commentator who answers it.

So for most Store plugins the realistic direct exposure under the directive is small. For plugins that handle consumer uploads, health-related product data or anything in the B2C account area, it’s real.

Updates: no obligation, but no excuse either

The directive does not force you to ship updates. Recital 51 says so in one sentence: “This Directive does not impose any obligation to provide updates or upgrades for a product.”

What it does is take away a defence. Under the old rules a manufacturer could argue that the defect didn’t exist when the product left the factory. Under Art. 11(2) you lose that argument if the defect comes from the software itself, from an update or upgrade, or from “a lack of software updates or upgrades necessary to maintain safety”, as long as the product is within your control. And a product stays within your control as long as you have “the ability to supply software updates or upgrades, themselves or via a third party” (Art. 4(5)(b)).

For a Store plugin you can update at any time, that’s always. In practice: if a security vulnerability becomes known and you don’t patch it, and it leads to damage the directive covers, the “it was fine when I released it” defence is gone. If you do ship the patch and the merchant doesn’t install it, recital 51 says the liability doesn’t apply for that part.

That has two consequences I’d act on now. First, keep a record of when you published security fixes and how you announced them. In a dispute that record is your evidence, and under Art. 9 you may have to hand it over anyway. Second, decide when a plugin version is end of life and say so publicly. As long as you sell or maintain a version, you have the ability to update it, so it stays within your control.

Updates also matter for the cut-off date. A plugin released before 9 December 2026 stays under the old law, and normal updates don’t change that. Recital 40 and the German government draft agree that only a “substantial modification” makes it a new product, placed on the market at the time of the modification. The definition in Art. 4(18) is narrow: the change has to alter the product’s original performance, purpose or type beyond what your initial risk assessment foresaw, and it has to change or increase the risk. A new feature in a checkout plugin probably doesn’t meet that. A rewrite that turns a display plugin into one that processes customer data might. Whether a new major version sold as a separate Store listing counts as a new product is, as far as I can see, open.

Agencies, freelancers and the integration question

For an agency, the uncomfortable question is who the manufacturer is.

Custom code you write and deliver to a client is software you develop and supply in the course of a commercial activity. You’re its manufacturer. If you build a complete shop and integrate third-party plugins as part of what you deliver, Art. 8(1) makes the manufacturer of a product also liable for components integrated “within the manufacturer’s control”, and all liable parties are jointly and severally liable (Art. 12(1)). I’m not sure a court would treat a delivered Shopware project as one product with components in that sense, because the merchant usually licenses the plugins themselves. But I wouldn’t build my contracts on the assumption that it won’t.

Shopware AG itself is a different case. Recital 18 says a manufacturer doesn’t consent to an integration “merely by providing for the technical possibility of integration”. A plugin system alone doesn’t make Shopware liable for your plugin. Its terms describe the Store as “an online marketplace operated by shopware”, and the Store only sells to businesses. As far as I can see, the most it could end up with is the residual liability of a distributor that can’t name the manufacturer (Art. 8(3)). For a Store vendor with an EU address, that’s unlikely to matter.

Patching someone else’s plugin is worth a thought too. If you change third-party code so much that it counts as a substantial modification and then supply it, Art. 8(2) treats you as the manufacturer of that product. A two-line fix in a vendor’s plugin won’t reach that threshold. A fork that adds new functionality might.

Freelancers get one useful clause. Art. 12(2) says a manufacturer that integrates software as a component has no right of recourse against a micro or small enterprise that made the defective component, if it “contractually agreed” to waive that right. It isn’t automatic. If you’re a freelancer building plugins for an agency, ask for that waiver in the contract. If you’re the agency, know that agreeing to it means you carry the risk alone. Towards the injured person nothing changes either way.

The Cyber Resilience Act is the bigger change

If I had to pick one regulation for Shopware plugin vendors to read this year, it would be the CRA, Regulation (EU) 2024/2847. Its reporting obligations for actively exploited vulnerabilities have applied since 11 September 2026. Its main obligations apply from 11 December 2027: secure-by-default design, vulnerability handling, security updates for a defined support period, technical documentation and CE marking.

The Commission’s guidance from 27 July 2026 (C(2026) 5252) says standalone software is in scope if it’s supplied to the user and runs on the user’s side, and it names browser extensions as an example. Plugins aren’t mentioned. A commercial plugin that runs on the merchant’s server fits that description, in my reading. A Shopware app whose logic runs entirely on your server looks closer to SaaS, which the CRA mostly doesn’t cover.

The link to product liability goes through Art. 10(2)(b): non-compliance with mandatory safety requirements leads to a presumption of defect. Art. 7(2)(f) lists “safety-relevant cybersecurity requirements” among the factors for defectiveness. Once the CRA applies, a plugin that doesn’t meet its requirements starts every product liability case with a presumption against it.

One footnote in the CRA guidance caught my eye. It says that “for the purposes of product liability law, computer code itself does not constitute a product”, with a reference to recital 13 of the PLD and its “mere source code of software”. Shopware plugins are shipped as PHP source. I wouldn’t read that as an exemption. The recital puts source code next to e-books and media files, as information. A plugin you install and run is software in use, and recital 13 calls that a product irrespective of how it’s supplied. But it’s a sentence a defence lawyer will quote one day.

Open source in your plugin

Your composer.json pulls in a dozen packages, so this matters. Art. 2(2) excludes free and open-source software “developed or supplied outside the course of a commercial activity”. Recital 15 then says: if a manufacturer integrates such software into a commercial product, the manufacturer is liable, not the open-source developer.

So the maintainers of the libraries you use are out, and you’re in for all of it. A bug in a dependency that corrupts customer data is your bug as far as the injured person is concerned. Free plugins aren’t automatically out either. Recital 14 brings software back into scope when it’s supplied “in exchange for a price, or for personal data” used for anything other than security and compatibility. A free plugin that exists to sell a paid version or a SaaS subscription is, as far as I can tell, supplied in the course of a commercial activity.

Where Germany stands

Germany is transposing the directive with a new, standalone Produkthaftungsgesetz under the “Gesetz zur Modernisierung des Produkthaftungsrechts” (Bundestag printed paper 21/4297). The cabinet adopted it on 17 December 2025, the first reading was on 4 March 2026, and the Bundestag passed it on 8 October 2026 in the version recommended by its legal affairs committee (printed paper 21/8429). The Bundesrat still has to deal with it once more before it can be promulgated, and I haven’t found a date for that yet. Entry into force stays at 9 December 2026.

The committee changed little that matters for software vendors. Its amendments are mostly about disclosure of evidence. Courts can now also order third parties, such as market surveillance authorities, to hand over evidence (§ 19(1)). And a defendant worried about trade secrets can ask for a separate procedure in which a court-appointed expert, bound to secrecy, looks at the material first, and only the parties’ lawyers get access (§ 19(4)). For a plugin vendor whose source code ends up as evidence, that second point is the useful one. The rest of the amendment package concerns electronic court files and a transitional rule of the right-to-repair law.

The law keeps the development risk defence (§ 9(1) no. 3) and drops the €500 deductible and the €85 million cap. The government’s explanatory memorandum notes that both limits were “derzeit in der Praxis kaum relevant”, because German courts mostly decide product cases under § 823 BGB anyway. That also means the tort liability you already have doesn’t go away.

Germany is on schedule compared to most of the EU. According to Faegre Drinker’s tracker from September 2026, only Hungary and Croatia had finished their transposition at that point.

What I’d do before December

  1. List your plugins and versions, and note which ones you’ll still be selling or putting into service after 9 December 2026. Those are under the new rules.
  2. Check which plugins touch consumer data or consumer uploads in the storefront or the customer account. That’s where the directive actually reaches you.
  3. Write down a support period and an end-of-life date for every plugin version, and publish them.
  4. Keep a log of security fixes: when the issue was known, when the fix was released, how merchants were told.
  5. Read your liability insurance. Many IT liability policies cover financial loss but not product liability, and the broker FMP Fuchs points out that data loss is often a grey zone between property damage and financial loss. exali, for one, points to a separate product liability policy.
  6. Agencies: decide who carries the risk for third-party plugins you integrate, and put it in the contract. Freelancers: ask for the Art. 12(2) waiver.
  7. Start on the CRA. Reporting obligations already apply, and December 2027 is fourteen months away.

Shopware AG hasn’t published anything on the PLD or the CRA for extension partners that I could find. If you’ve seen something from them, in the partner portal or elsewhere, I’d like to know.

Sources

Related Posts