Every Firmware Update Creates a New Product

Ship date is no longer the last date the product exists in its designed form. A firmware push at 3 a.m. can add a feature, remove one, change how a control responds, or introduce a defect that wasn’t there when the unit left the line. The legal machinery built around design, warning, and manufacturing defects is still catching up. For designers, engineers, and product leads who assumed liability freezes when the last screw goes in, the update pipeline has reopened questions everyone thought were settled.

The shift isn’t hypothetical. Regulators are treating OTA pushes as evidence, plaintiffs are treating them as admissions, and standards bodies are rewriting what “the product” even means once code can change after purchase.

The Update Is Now Part of the Product Record

Every OTA push leaves a trail. Version numbers, release notes, staged rollout logs, telemetry from before and after the change, and the internal ticket that triggered the push all sit somewhere on a server, and all of them are discoverable. When a user is hurt after a feature behaves in a way it didn’t a month earlier, the update itself becomes an exhibit. Experienced product liability attorneys handling auto defect and connected-device cases increasingly ask for the firmware version at the time of the incident before they ask almost anything else.

A Bloomberg Law analysis of OTA recalls in the auto sector lays out how easily a routine software patch can meet the legal definition of a recall, and how misclassifying one as a non-recall update creates its own exposure, from notification duties to civil penalties.

The same logic reaches beyond cars, to any connected product a manufacturer can reach into after the sale.

Why the Old Ship-Date Defense Falls Apart

The intuitive fix is the one designers have leaned on for decades: freeze the design, document it, and argue the product was reasonably safe as shipped. That defense doesn’t survive contact with a product that keeps changing. Three problems show up fast:

• The as-shipped configuration is fiction. If the unit in the plaintiff’s hands has been running on code you pushed eighteen months after manufacturing, the shipped state is a historical artifact, not the thing that hurt anyone. Juries follow the version that was live at the moment of injury.
• The update itself implies you knew. Pushing a fix reads as an acknowledgment that something needed fixing. Regulators have already treated post-sale software changes as evidence a defect existed earlier, and plaintiffs’ experts read release notes the same way.
• Not updating is now its own theory. If your team could have pushed a patch and didn’t, opposing counsel will ask why. A duty to monitor and act on post-sale safety information is exactly what the current wave of product-liability rulemaking is codifying.

Freezing the design record used to be defensive. When the product keeps changing, a frozen record no longer matches the product.

Design the Update Pipeline Like It Will Be Subpoenaed

The workable approach: every push is a design decision that will eventually be read back to you under oath. That reframes a lot of small choices engineering teams make casually.

• Version the safety case, not just the code. Each release should carry an updated hazard analysis showing what changed, what was tested, and what risks the team considered and rejected. If the safety file only reflects the shipped build, you have nothing to point to when the version that mattered was pushed two years later.
• Keep the rollback path real. A patch you can’t reverse is a patch you can’t recall. Staged rollouts, signed builds, and a documented ability to revert are the operational equivalent of a product hold, and they read that way to a regulator.
• Write release notes for a stranger. Internal shorthand (“tuned the pedal map,” “tweaked latch logic”) reads badly years later. Notes that clearly state what user-facing behavior changed and why are the difference between a clean paper trail and a discovery problem.
• Decide the recall question at the push. If a fix addresses a safety-relevant behavior, the classification call, routine update or reportable recall, needs to happen before the button gets pressed, with regulatory counsel in the room. Deciding later, with an incident on the table, is where companies get in real trouble.
• Preserve pre-update telemetry. The strongest evidence that a change improved or degraded safety is what the fleet looked like before and after. If your data retention policy silently deletes the “before,” you’ve handed the argument to the other side.

The Definition of “Product” Is Being Rewritten

The regulatory ground is moving under this whole conversation. The revised EU product liability framework pulls embedded software, firmware, and even SaaS inside the definition of a product subject to strict liability, and treats the failure to supply necessary updates as a form of defect in its own right. Domestic courts and agencies haven’t gone that far yet, but the direction of travel is unmistakable.

For designers, the practical takeaway is simple to say and harder to live by. The product you ship is a snapshot, not a finished object. The update pipeline is part of the design.

Build it, log it, and staff it as if the next injury case will turn on a single line in a changelog. At some point, one of them will.

Read more about CAD, product design and related technology at SolidSmack.com