Firmware, Software Updates and Product Longevity

Durability discussion in product regulation has historically been mechanical: how many cycles, how many drops, how much abrasion. For anything with a processor in it, that framing misses the failure mode that actually ends the product’s life.

A television that no longer receives application updates, a router without security patches, a phone stuck two operating system versions behind — none of these has broken. All are retired, and none of the mechanical durability requirements would have predicted it.

Why software ends products

Three mechanisms do the work. Security patches stop, which makes the device unsafe to connect. Application compatibility lapses, which makes it useless for its purpose. And performance degrades under updates written for newer hardware, which makes it unpleasant enough to replace.

The third is the most contested because it can be accidental or deliberate, and distinguishing the two from outside is nearly impossible. Recent EU rules address it directly by requiring that updates must not reduce performance in a way that pushes replacement.

What do the rules currently require?

The Cyber Resilience Act is the broadest of these, because it applies to products with digital elements generally rather than to a named category. It obliges manufacturers to provide security updates across the expected product lifetime and to declare a support period.

The declared support period

Declaring it is the change that matters. A commitment stated before sale can be compared between products, relied on by a buyer, and enforced afterwards, none of which is true of an unstated intention that quietly expires.

Why the clock usually starts at last placement

Several instruments measure the support period from the date the last unit of a model is placed on the market rather than from launch. That detail has a large practical effect and is frequently misread.

A model produced for three years and then supported for five carries eight years of obligation from launch. Extending a production run therefore extends the software commitment, which connects a portfolio decision to an engineering cost in a way that few organisations have modelled.

What this means for resale

A used connected device without a known support expiry is difficult to value. The buyer cannot tell whether they are purchasing four more years of safe use or four more months, and rational pricing under that uncertainty is a discount.

Publishing the expiry as a retrievable field removes the uncertainty and, on the evidence from other categories where condition history became available, raises the price rather than lowering it. Sellers frequently expect the opposite, which is why the field is often withheld.

Support duration as a passport field

It belongs in the passport for the same reason state of health belongs in a battery passport: it is the single fact that most determines remaining useful life, and it is held by a party that is not the current owner.

The useful shape is a date rather than a duration, because a duration requires knowing the start and a date does not. A record stating that security updates are committed until a specific date can be read by a buyer, a refurbisher or a corporate asset system without any further calculation.

What happens when support ends?

Ideally the product continues to function in a reduced but honest state, and the alternatives are worse. Devices that become inoperable when a service is withdrawn convert a software decision into hardware waste, which is the outcome all of this regulation is trying to prevent.

Publishing final firmware, documenting local operation where a cloud service is withdrawn, and permitting third-party maintenance are the practical mitigations. Each is a decision made at end of support and much cheaper if designed for at the start.

The connected-product waste problem

Cloud dependence is where this becomes acute. A device whose core function requires a manufacturer service stops working entirely when that service is retired, regardless of its condition, and no amount of mechanical durability compensates.

This is not yet comprehensively regulated, and it produces the starkest examples of functional hardware becoming waste by decision rather than by failure. A passport that records whether a product can operate without a remote service is stating something a buyer genuinely needs.

What should a manufacturer publish?

1. The security update commitment as a date, not a vague duration.
2. Whether feature updates continue past the security commitment, and for how long.
3. Whether the product functions without a manufacturer cloud service.
4. Where final firmware will be available after support ends.
5. Whether third-party firmware is permitted, and under what conditions.

The third and fifth items are the ones most manufacturers are reluctant to answer, and they are the two a secondary market most needs. They are also the two most likely to appear in future ecodesign measures, since they determine whether a product outlives its vendor.