The motor still turns. The battery still holds charge. The buttons still register a press. Yet the app now says the device is unsupported, or the latest phone operating system will no longer run the app at all. Nothing important has broken inside the object; the route used to control it has disappeared.
This is how a software update can make working hardware obsolete. A connected product is not one thing but a stack of dependencies, and usefulness survives only while the layers can still communicate. Some breaks are unavoidable consequences of security and technical limits. Others are choices about support, interfaces and business models. The human-centred question is whether the product was designed so that one ageing layer can be repaired or replaced without discarding everything below it.
The object is only the bottom of the stack
At the base is the physical device: sensors, motors, battery, processor, memory and radio. Firmware turns those components into a controllable machine. It reads a button, drives a motor, measures temperature or accepts a command over a local connection. Above the firmware may sit an operating system, either inside the product or on the phone used to control it.
The phone app is another layer. It translates a person’s intention into commands and displays the device’s state. The app may speak directly to the device over a local protocol, but often it calls a vendor’s application programming interface, or API. That remote interface authenticates the account, stores settings and passes commands through a cloud service. The cloud may then relay the instruction back to the product.
A command as simple as “start” can therefore cross hardware, firmware, operating system, app, API and cloud before returning to the machine on the table. An update at any boundary can break the contract between two layers. The new phone system may remove an old permission. The updated app may require a newer encryption library. The cloud API may reject the firmware’s authentication method. The vendor may close the server that knows how to reach the device.
The message “not compatible” compresses several causes. Diagnosing the broken layer determines whether the device needs replacing, the software needs repair, or only the control path needs an alternative.
Why updates are necessary
It would be a mistake to conclude that products should simply stop changing. Connected devices expose interfaces, store credentials and communicate with other systems. Vulnerabilities are discovered after sale, certificates expire and cryptographic practice advances. Leaving every old protocol available forever can turn compatibility into an attack path.
The US National Institute of Standards and Technology’s IoT cybersecurity baseline treats secure software updating as a core capability. It includes authenticating updates, restricting who can install them, controlling whether installation is automatic or manual and, where appropriate, providing rollback. NIST also notes the tension: rollback can restore a critical integration after a bad release, but returning to a vulnerable version can itself be dangerous.
Some incompatibility is therefore a real engineering limit. A processor may lack the hardware needed for an accepted cryptographic algorithm. Memory may be too small for a secure new software image. A radio generation may be retired because the network spectrum is being reused. Continuing support can eventually require more energy, testing and specialist work than the product can justify.
But “eventually” is not a service-life plan. The limit should be identified, communicated and reached after a credible support period, not discovered by the owner in an app-store error.
Where commercial choices enter
Many failures are not imposed by physics. Supporting old operating-system versions increases testing effort, so an app developer may narrow the supported range. Maintaining two API versions costs money, so a provider may close the older one. A proprietary local protocol may remain undocumented, preventing another controller from taking over after the original app disappears. A cheap product may have enough memory for launch software but no margin for later security features.
Each decision can be defensible in isolation. Together they shift the product’s lifetime from the durability of its hardware to the shortest commitment anywhere in its stack. A long-lived appliance may depend on a much shorter-lived phone app. Longevity therefore has to be designed into interfaces, documentation and update infrastructure while the product is still being developed.
Support is becoming a product property
Regulation is beginning to make digital maintenance more visible. The United Kingdom’s consumer connectable product security regime has applied since 29 April 2024. Among its requirements, manufacturers must publish a defined support period for security updates. That does not force a long period, but it makes “how long?” a question that must receive an answer.
In the European Union, ecodesign requirements for smartphones and slate tablets have applied to products placed on the market since 20 June 2025. The European Commission’s official product guidance describes operating-system upgrades for at least five years from the end of placement on the market of the last unit of a model, critical spare-parts availability for seven years after sales end, and access for professional repairers to software or firmware needed for replacement work.
The EU Cyber Resilience Act goes wider across products with digital elements. Its manufacturer guidance says the support period must be indicated and vulnerabilities handled during it. The Act’s main obligations apply from 11 December 2027; vulnerability-reporting obligations begin earlier, on 11 September 2026. These rules strengthen security maintenance, but security support does not by itself guarantee that a cloud-dependent product will retain its core function when the service ends.
Designing the stack to age in pieces
A longer-lived product separates replaceable dependencies from essential operation. Its basic function can run locally. The network module is a replaceable component rather than inseparable from the main controller. The protocol between device and controller is documented and stable. Settings can be exported in a usable format. If an online service is necessary, the device can be pointed to a successor rather than recognising only one permanent server address.
Open standards help when they define real interoperability, not merely a common connector around proprietary behaviour. A local standard can allow a new hub or app to control older hardware, while replaceable radio modules can let a durable machine adopt a new network generation. Both add costs and compatibility work, but they make it possible to renew one layer rather than the entire object.
Update design also needs a recovery path. A verified update should be installed atomically so a power loss does not leave half an image. A known-good version can be retained for recovery, while security policy prevents indefinite use of a compromised release. The owner needs an intelligible state: current, updating, recovered, unsupported but safe offline, or unsafe to connect. A device that merely flashes an unexplained light makes the human part of recovery guesswork.
A service-life test before purchase
A buyer cannot audit source code in a shop, but can ask for a dependency map. The useful questions are how long security updates are guaranteed, which essential functions work without an account or cloud service, which phone operating systems are supported, whether local control uses an open protocol, whether batteries or network modules can be replaced, and whether settings and user data can be exported.
The dates should be tied to something verifiable. “Five years of support” is ambiguous if it means five years from a product’s first launch and the item remains on sale for three of them. An end date or a period measured from the last sale is more useful. The description should also distinguish security fixes from feature updates and compatibility support. A product can be secure yet unable to work with a new phone, or compatible while no longer safe to expose to a network.
Price comparisons should include this digital service life. A cheaper device with a short, cloud-bound support period can cost more per useful year than a repairable product with local operation.
Obsolescence is a decision about capability
No manufacturer can promise eternal compatibility, and owners should not be encouraged to connect insecure equipment indefinitely. The reasonable demand is narrower: define the supported life, protect the update path, preserve the core function where it can be safe, and make replacement possible at the layer that has actually aged.
This is the software counterpart to Alkemata’s argument in Every Smart Device Needs a Real Manual Mode. Local control is not nostalgia for buttons. It is a way to prevent a remote dependency from deciding that intact hardware has reached the end of its useful life.
If you value explanations of how technical architecture shapes human agency, you can subscribe to Alkemata for future articles.
The remaining question is not whether a product will eventually become obsolete. Everything does. It is whether the point of failure follows a genuine physical or security limit—or a support decision hidden several layers above the device the person thought they owned.