Device lifetime is decided by software support periods

What it is

The common cause of a device's retirement is not broken hardware but an expired software support window: the OS stops receiving security patches, apps demand a newer system version and will not install, cloud services refuse old clients — the device dies functionally while the hardware still runs. A device's effective lifetime is therefore set mainly by the vendor's support commitment, and whether the heavy embodied carbon of manufacturing gets amortized depends on that commitment's length and honesty. Terminating support early to stimulate replacement is one recognized form of planned obsolescence.

Why it happens

Three paths truncate lifetime. Security: without patches the device keeps working but risk climbs steeply (especially for banking and payment apps), and rational users are forced to upgrade. Ecosystem: app stores and major apps gradually raise minimum system versions, excluding old devices from new features and necessary services. Server-side: protocol upgrades, interface shutdowns, and cloud validation rejecting old clients make the device useless even when everything local is intact. The paths share one structural cause: software's ongoing cost is borne by the vendor while the replacement benefit also accrues to the vendor — shortening support shifts cost and looks financially attractive. Meanwhile each system version's growing demands (background processes, animation, framework overhead) make old devices genuinely feel slower, further compressing psychological usability. Hardware's embodied carbon concentrates in manufacturing; halving lifetime roughly doubles carbon per unit of use.

Where it stops holding

Support windows are not a one-dimensional longer-is-better question: maintaining old platforms has real engineering cost, and adapting security patches to very old architectures stops being feasible past a point — a responsible endpoint exists. The question is whether the endpoint is technical necessity or commercial choice, judged by the spread of promised versus actual support durations on comparable hardware. Cloud-dependent devices (smart speakers, IoT endpoints) are hardest to judge — vendors cite architecture upgrades while users lose whole functions; for such products the lifetime commitment should be treated as part of the specification at design time.

Applying it

• Publish support commitments at procurement and design time: years of security updates and minimum support duration from launch, written into product documentation rather than marketing blurbs.
• Cap the resource cost of new versions: key flows must not regress on older hardware tiers (enforced by benchmark gates), preventing soft retirement by slowdown.
• Prefer functional degradation over service cutoff: when cloud services change, keep a usable subset or local fallback for old clients — turn shutdowns into downgrades.
• Verify: track the retirement curve of discontinued devices — if loss clusters within three months of support expiry rather than tracking hardware-failure distribution, lifetime really is support-driven and the commitment length needs review.

Related

• Same group: P4.08.1 Data transfer and computation consume real energy · P4.08.2 Autoplay and prefetch defaults are significant costs
• Adjacent: K6 Device platforms and update maintenance · Z6.05 Device data retention and disposal
• Search terms: software support window · planned obsolescence · embodied carbon