The product. The evidence. The responsibility.Independent product liability resource
ProductLiability.helpProducts · Defects · Evidence
Home / Topic library / Third-Party Updates and Manufacturer Responsibility

Updates, cybersecurity and control

Third-Party Updates and Manufacturer Responsibility

Third-party delivery does not automatically end manufacturer responsibility. Examine authorisation, integration and update capability for the particular change.

A different supplier does not answer the legal question

A third-party update may be developed, approved or distributed by a business other than the manufacturer of the wider product. Those roles can be separated across several participants. Under Directive (EU) 2024/2853, responsibility depends on the actual product, component and control relationship rather than a simple distinction between in-house and outsourced work. A manufacturer's use of an outside provider is not, by itself, an exemption from liability.

The post-sale updates framework explains how control connects to defectiveness, damage and causation. The corrected Directive applies to products placed on the market or put into service after 8 December 2026, with transposition due by 9 December 2026. The relevant national implementation and product scope need checking separately. A third-party release date cannot alone determine which legal regime applies.

Map development, approval and distribution separately

A component developer may prepare the code while the product manufacturer decides whether to integrate it. Another business may operate the distribution channel, and a customer may choose when installation occurs. A useful account identifies what each participant did. A download page's branding or a contract's shorthand description should not replace evidence about actual decisions.

Keep the specific release and period visible. Approval of an original component may not describe a later independently supplied replacement. Conversely, a provider delivering releases under a continuing authorised arrangement is different from an unrelated party offering an unofficial modification. An evidence review should connect the authority relied on to the particular change alleged to have affected safety, rather than assume all releases from one supplier have identical status.

Authorisation and consent matter under Article 4

Article 4(5)(a) includes a manufacturer performing, authorising or consenting to component integration, interconnection or supply, including updates and upgrades. It also includes specified modification relationships. Article 4(5)(b) addresses the ability to supply updates itself or through a third party. These routes mean that a manufacturer's role can continue even where another organisation holds the source files or operates the update service.

The manufacturer control analysis examines those statutory relationships. Relevant material can include release approval, product presentations, integration agreements and operational permissions. Each record answers a different question. Technical permission to access a system does not necessarily establish approval of every action taken through it, while an approved update arrangement need not require the manufacturer to perform every delivery step personally.

Compatibility alone is not consent

Recital 18 distinguishes mere technical possibility from manufacturer authorisation or consent. A product with an open interface is not automatically treated as consenting to every third-party component a user could install. An independent change therefore needs examination on its own facts rather than attribution to the original manufacturer solely because installation was technically possible.

A manufacturer presenting an outside service as part of the product offering or expressly approving integration supplies different evidence. Mere recommendation of certain brands, or failure to prohibit potential components, does not itself establish consent under Recital 18. The analysis should preserve what was communicated and how the arrangement worked. Neither the term independent supplier nor a general disclaimer is necessarily a complete account of the actual relationship. Statutory responsibility depends on the relevant conditions, not only the parties' preferred commercial description.

Component responsibility can coexist with product responsibility

Article 8 addresses a defective component integrated into or interconnected with a product within manufacturer control, where it caused the wider product to be defective. The component manufacturer's potential responsibility is without prejudice to the product manufacturer's liability. Identifying a component supplier therefore does not automatically remove the wider product manufacturer from the analysis.

Multiple participants can have relevant roles without every participant being liable in every case. The defective product, causal contribution and statutory conditions must still be identified. A routine delivery service should not be called the manufacturer merely because it transmitted files. Equally, supplier contracts allocating costs or support duties do not automatically determine the injured person's statutory rights. Contribution and recourse questions can require separate analysis.

Later changes and modifications require careful classification

Article 11(2) restricts the later-defect exemption for specified software and other matters within manufacturer control. A supplier's involvement after initial sale does not therefore settle the defence. Article 8(2) also addresses a person who substantially modifies a product outside manufacturer control and subsequently makes it available or puts it into service. That provision has its own conditions.

Not every outside update is automatically a substantial modification. The Article 4 definition and relevant product-safety rules need examination. A routine correction, a new feature and a change in intended purpose can have different significance. Record what changed and its safety consequence before applying a statutory label. This preserves the distinction between an authorised component update and an independently modified product.

Prove the alleged safety consequence and harm

Article 7 governs defectiveness, while Article 10 begins with proof of defectiveness, covered damage and causation, subject to conditional presumptions. A disputed supplier relationship cannot replace those elements. Establish the affected release, installation state and mechanism by which the third-party change allegedly reduced safety and caused the reported harm. A later incident alone does not prove the release caused it.

Article 6's damage categories and exclusions also remain relevant. Preserve the actual injury, property or data consequences rather than grouping all operational losses together. The resulting account should state which participant performed which action, what evidence supports manufacturer control and what remains unresolved. That structure makes the third-party relationship understandable without automatically excluding the original manufacturer or treating every outside software provider as responsible for the entire product.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

  • Developer, approval and distribution roles
  • Component integration and release authorisations
  • Particular update and alleged safety consequence

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.

Continue the research