Ninety days from today, Directive (EU) 2024/2853 replaces a product liability regime that has stood since 1985. It applies to products placed on the market or put into service after 9 December 2026, and Article 4(1) defines a product as “all movables … it includes electricity, digital manufacturing files, raw materials and software”. Recital 44 closes the gap: software is a product “irrespective of the mode of its supply or usage”, whether stored on a device, accessed over a network, or supplied as software-as-a-service. It adds that a software developer, including an AI system provider under the AI Act, “should be treated as a manufacturer”. No-fault liability, which used to be something that happened to companies making kettles, now attaches to code.
TL;DR
- 9 December 2026 is a hard deadline. The directive reaches products placed on the market or put into service after that date. Anything already out stays under Ireland’s 1991 Act.
- Software is a product under Article 4(1), including SaaS, firmware, applications and AI systems.
- Failing to ship a security update is a defect. Article 11(2) removes the “it was fine when it left us” defence where the fault lies in software, or in the absence of an update needed for safety.
- Modify someone else’s product substantially and you become its manufacturer under Article 8(2), with a fresh ten-year clock. That is what an agency does when it forks an inherited codebase.
- Your repository becomes disclosable evidence. Article 10(2)(a) presumes defectiveness if you fail to disclose it.
- Recoverable damage is narrower than the headlines suggest, but the professional-use exclusion covers property and data only, never personal injury.
The patch you did not ship is the defect
Article 11(1)(c) preserves the familiar defence: prove it is probable the defect did not exist when the product went out, or arose afterwards, and you are not liable. Article 11(2) then removes that defence outright where the defectiveness is due to a related service, to software including updates or upgrades, to a lack of software updates or upgrades necessary to maintain safety, or to a substantial modification, provided each is within the manufacturer’s control.
Control is the part people miss. Article 4(5)(b) says a product is within the manufacturer’s control where the manufacturer “has the ability to supply software updates or upgrades, themselves or via a third party”. Not an obligation to. The ability. If you can push an update the product never fully leaves you, and the development risk defence in Article 11(1)(e) is measured across “the period in which the product was within the manufacturer’s control”, not just at market placement. Ship an auto-updater and you have extended your own liability window by design.
That unpatched dependency was already a 24-hour reporting question when the Cyber Resilience Act clock started this month. From December it returns as strict liability with a ten-year tail.
Fork a client’s codebase and you are the manufacturer
Article 8(2) states that any person who substantially modifies a product outside the manufacturer’s control, and then makes it available on the market or puts it into service, “shall be considered to be a manufacturer of that product”. There is no agency exception, no subcontractor exception, and no “we only did the front end” exception.
Article 4(18) sets the threshold. Where product safety rules specify one, that governs; otherwise a modification is substantial if it changes the product’s original performance, purpose or type in a way not foreseen in the manufacturer’s initial risk assessment, and changes the nature of the hazard, creates a new hazard or increases the level of risk. Both limbs, which is a real constraint. Restyling a dashboard is not substantial modification. Adding remote actuation to a device that previously only reported plainly can be.
Two consequences are easy to miss. Article 17(1)(b) runs the ten-year expiry period from the date the modified product was made available, so taking over a five-year-old system resets the clock rather than inheriting the remainder of it. And Article 11(1)(g) is your only relief: you escape where the defect relates to a part your modification did not affect. That is an evidential defence, worth exactly what you can demonstrate years later about which lines were yours.
Your repository becomes evidence
Article 9(1) requires a defendant to disclose relevant evidence at its disposal once a claimant has presented enough to support the plausibility of the claim, and Article 10(2)(a) presumes the product defective where the defendant fails to. Article 10(4) goes further: a court must presume defectiveness or causation where the claimant faces excessive difficulty proving it “in particular due to technical or scientific complexity” and can show it is likely. That is the provision written for machine learning, and it puts the work of rebuttal on you.
Recital 110 holds the sharpest detail for engineers: the presumption of defectiveness expressly “includes cases in which a product is not equipped with the means to log information about the operation of the product as required under Union or national law”. Absent telemetry is not neutral. It is evidence against you. Git history, CI logs, SBOMs and the issue tracker stop being internal artefacts, which is the third reason this year to retain them properly, after what a repository quietly accumulates and the R&D credit evidence standard.
Now the part that narrows it
Only natural persons can claim. Article 6(1) limits recoverable damage to death or personal injury including medically recognised psychological harm; damage to property, excluding the defective product itself and property used exclusively for professional purposes; and destruction or corruption of data not used for professional purposes. Pure economic loss between businesses stays where it has always been, in contract. Your client’s invoicing platform is, for the most part, outside this.
But read the professional exclusion precisely, because it attaches only to property and data. Article 6(1)(a) carries no such qualifier. An employee injured by a defective warehouse control system is a natural person who suffered personal injury, and the fact that it happened at work does not remove the claim. Anything that moves, heats, dispenses or diagnoses is in scope however commercial the setting.
Article 15 prohibits limiting or excluding this liability by contract, so your carefully negotiated limitation-of-liability clause does not reach these claims at all.
The lever most small suppliers do not know they have
Article 12(2) is the most useful paragraph in the directive for a small development company. Where a manufacturer integrates a defective software component into a product, it has no right of recourse against that component’s manufacturer if two conditions hold: the supplier was a microenterprise or small enterprise when the component was placed on the market, and the integrator contractually agreed to waive the right. It is not automatic: the waiver has to be negotiated and written down, and the next three months is when those contracts are being drafted.
What to do before December
- Classify your portfolio by harm, not by revenue. Ask whether a failure could plausibly injure a person, damage private property or destroy non-professional data.
- Put the patch commitment in writing and build the channel to deliver it. If you have the ability to update, you have the exposure, and a policy with no route to deployed units is not a mitigation.
- Keep a modification register on inherited codebases, recording what you changed, when, and against which baseline.
- Retain build provenance for ten years. SBOM, CI logs, risk assessments, issue history and operational logging, matched to the expiry period rather than your backup rotation.
- Reopen the insurance conversation, checking your policy responds to strict liability on software. If you are a small supplier, raise the Article 12(2) waiver.
Where Ireland actually stands
Ireland has not published a transposition bill. The Department of Enterprise, Trade and Employment has told the Dáil the deadline will be met, and the legislation was still in drafting as of August 2026. Ireland is not unusual: as of early September only Hungary and Croatia had notified complete national measures, and around ten member states had made no significant progress at all.
That is bad news rather than a reprieve. Late transposition does not move the date. It only means the text you design against is the directive itself rather than an Irish statute with worked examples, the same position Irish companies were left in when NIS2 reached them through their contracts before it reached the statute book. Note that this is broader ground than our earlier piece on the AI code liability gap: here the whole product falls under no-fault liability, whoever or whatever wrote it.
Ninety days is enough time to write a patch policy, start a modification register and fix your retention. It is not enough time to reconstruct three years of build provenance you never kept.
REPTILEHAUS builds and maintains software for clients across Ireland and Europe, and inherited codebases are a large part of what we do. If you are working out which of your products this directive reaches, or where your responsibility starts on a system you took over, get in touch.
📷 Photo by Homa Appliances on Unsplash
