The product. The evidence. The responsibility.Independent product liability resource
ProductLiability.helpProducts · Defects · Evidence
Home / Topic library / Manufacturer Control After a Product Is Sold

Updates, cybersecurity and control

Manufacturer Control After a Product Is Sold

Manufacturer control can persist through authorised components, modifications and an ability to supply updates. The legal definition requires more than ownership or a generic support label.

What manufacturer control means after sale

A manufacturer can remain relevant to a product after the customer takes possession. Directive (EU) 2024/2853 defines manufacturer control by reference to specified actions, authorisation, consent and update capability. It does not simply ask who owns the device or whose employee pressed an installation button. The definition matters because components, software and services can continue changing the safety of a product throughout its use.

The post-sale updates framework places control alongside defectiveness, covered damage and causation. Control is one part of that analysis, rather than a finding that compensation is due. The corrected Directive concerns products placed on the market or put into service after 8 December 2026. National implementing law and the facts of the particular product need separate examination.

The two parts of the statutory definition

Article 4(5)(a) addresses a manufacturer performing, authorising or consenting to integration, interconnection or supply of a component, including software updates or upgrades. It also covers product modification, including substantial modification. The inquiry can therefore concern an affirmative decision about an outside supplier's work. It does not require that the manufacturer write every line of the software or employ the person delivering the change.

Article 4(5)(b) addresses the manufacturer's ability to supply software updates or upgrades itself or through a third party. Update supply can remain possible after initial delivery and through a contracted platform. A review should document that capability rather than assume that the end of a sales warranty removed it. Warranty duration and the statutory meaning of control answer different questions.

When software is still under manufacturer control

Software may remain within the relevant control relationship when the manufacturer continues supplying releases, approves a supplier's changes or retains the ability to deliver upgrades through an established arrangement. Approval rights, release authorisations, maintenance agreements and operational records can each provide relevant evidence. A business announcing that a product is mature or in maintenance mode does not determine the legal question without those underlying facts.

The particular software and period must be identified. Control over one application does not automatically establish authorisation of an unrelated installation. A later corporate change, platform migration or termination of an update arrangement may alter the evidence. Document when any change occurred and whether the manufacturer retained a route to supply updates through another provider. A current snapshot cannot necessarily describe the position when the alleged defect arose.

Technical compatibility is not consent to everything

A device can technically accept third-party software without the manufacturer having authorised every component. Recital 18 distinguishes mere technical possibility from authorisation or consent. Otherwise, an open interface would automatically attribute every later independent change to the original manufacturer. The relevant evidence concerns the manufacturer's relationship to the integration or modification, rather than compatibility alone. Recommending certain brands or merely failing to prohibit a component is also insufficient by itself under Recital 18.

Presentations and practical arrangements can nevertheless matter. A manufacturer may direct customers to a particular outside application, approve a named service or include it in the product offering. That is different from a user independently selecting unrelated software. The discussion of third-party updates and responsibility distinguishes an authorised supplier from an independent change without treating either label as a complete legal answer.

Why control affects components and later defects

Article 8 addresses the manufacturer of a defective component where integration or interconnection occurred within the product manufacturer's control and caused the wider product to be defective. The product manufacturer's responsibility is not displaced simply because another business supplied that component. Actual roles and the causal relationship require examination before assigning liability to either participant.

Article 11(2) limits the exemption based on defectiveness arising after supply for specified matters within manufacturer control. These include software, related services, necessary safety updates and substantial modifications. This is a limitation on a particular exemption. It does not dispense with Article 10's proof framework or automatically remove every other possible exemption. Identifying the provision being considered prevents an overbroad conclusion from the word control alone.

What a control chronology should contain

Start with product identity and the relevant software component, then record the parties able to approve, prepare or supply changes. Keep the arrangement applicable during the relevant period, including amendments. A contract may allocate approval rights while operational records show how those rights were exercised. Neither should silently replace the other when their accounts differ.

Record the original integration and later changes separately. A manufacturer might approve a component initially but have no involvement in an unauthorised replacement. Conversely, an outside service might remain part of an approved update channel even when the manufacturer does not distribute the files directly. A dated chronology should distinguish confirmed authority, actual activity and unresolved questions about capability.

Does ending support end control automatically?

No single support label supplies that answer. Ending customer assistance, publishing a support deadline and losing the ability to supply updates are different events. The Directive does not impose a freestanding obligation to provide updates, and its necessary-safety-update provision should not become a promise of perpetual support. Other product-safety rules or contracts can establish separate obligations whose scope must be checked.

A control review therefore asks what changed in practice and what legal consequence follows under the provision in question. Article 7 also considers the time when a product left manufacturer control in the defectiveness assessment. Retain evidence about the alleged safety condition and covered harm alongside the control chronology. A carefully established control relationship can answer an important attribution question while leaving defect, causation and damage genuinely unresolved.

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.

  • Component and modification authorisations
  • Dated update-supply capabilities and provider agreements
  • Control changes and release-approval records

Control is a defined legal relationship. It does not automatically establish defect, damage or causation.

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