The cloud service stops, but the object is still fixed to the wall. That is the peculiar failure mode of the smart home: the hardware remains physically present while part of its purpose disappears somewhere else.
Google’s support page for the discontinued Nest Secure alarm system makes the problem unusually visible. The system no longer connects to cloud services, no longer works in the Nest app and no longer receives software or security updates. Google warns that attempting to continue in offline mode may lead to “unpredictable degradation in performance”. Yet the same page explains that a Nest × Yale lock taken offline can still be operated from its keypad. The alarm system and the lock therefore illustrate two different ideas of ownership. One becomes uncertain when the service behind it ends; the other loses convenience but preserves its essential local function.
That distinction should become a normal design test. A smart device does not need to reproduce every connected feature when the internet, an account or a vendor disappears. It does need a deliberate degraded mode that preserves the core action a person reasonably bought the object to perform. Convenience stops being human-centred when the convenient route becomes compulsory.
Automation is not the same as dependency
A device is genuinely automated when it performs a task with less effort from its owner: a thermostat follows a schedule, a light responds to occupancy, or a lock reports its status remotely. None of those benefits logically requires the removal of local control. The dependency appears when the control path is moved into an app, the app requires an account, the account depends on a cloud service, and the device cannot perform its essential function when any link in that chain fails.
This architecture is attractive to manufacturers. A cloud connection enables remote access, diagnostics, new features and subscriptions. It can also simplify a product physically by replacing buttons, displays and local storage with software. Someone with limited mobility may gain independence from voice control and automation. A carer may need a remote alert. A household managing variable electricity prices may benefit from networked optimisation.
The mistake is to interpret the preferred route as the only route. The app can be the easiest control without becoming the exclusive control. Automation can be the default without becoming a gatekeeper.
A manual mode must preserve the right function
The phrase “manual override” can conceal more than it reveals. A pinhole reset that erases the device is not a usable manual mode. Nor is a hidden sequence documented only in a support forum, or a local button that works only after the user has authenticated through a remote account. These mechanisms may help a technician recover a product, but they do not preserve ordinary human agency.
A meaningful manual mode is proportionate to the device. For a smart bulb, it may mean that a wall switch still turns on a useful light. For a thermostat, it may mean that temperature can be set locally even if remote schedules and energy optimisation are unavailable. For a door lock, a keypad or physical key can preserve entry when the network path fails. For an appliance, the basic cycle should not depend on a smartphone whose operating system may outlive the app, or vice versa.
Not every feature can survive disconnection. Remote camera viewing is remote by definition. Weather-dependent optimisation needs external data. Collaborative services may need identity and synchronisation. The design question is therefore not whether everything can work offline, but whether failure removes an enhancement or removes the object’s reason for being.
Manual control is also a security design problem
Keeping a local path does not mean freezing software or ignoring security. Connected products need secure updates, access controls and a clear support period. The US National Institute of Standards and Technology’s IoT baseline treats device configuration, protected interfaces, secure software updates and awareness of cybersecurity state as core capabilities. These protections matter because an abandoned connected product can become a risk to its owner and to other systems.
The European Union’s Cyber Resilience Act pushes in the same direction. It requires manufacturers of covered products to state an end date for security support and to handle vulnerabilities during that period. Its main provisions apply from 11 December 2027, although some obligations begin earlier. This makes the duration of digital maintenance more visible, but maintenance and graceful degradation are different questions. A device can be securely supported and still be needlessly cloud-dependent; it can also retain a local button while becoming unsafe to connect.
A robust design separates these concerns. Local commands should use authenticated, constrained interfaces rather than an undocumented back door. A cloud outage should not disable physical safety controls. When support ends, owners should be able to disconnect the product from the network and understand which functions remain safe. Manual mode should be part of the threat model, not an escape hatch added after launch.
Control includes leaving
There is a second kind of manual mode: the ability to exit the vendor’s preferred system. A person may be able to press a button and still remain trapped because schedules, measurements, access records or configuration cannot be exported. A replacement product then requires rebuilding the household’s routines from nothing.
The EU Data Act, applicable since 12 September 2025, gives users of connected products rights to access, use and port data they co-generate. That is an important shift from treating device data as the manufacturer’s private exhaust. It does not by itself guarantee that another product can understand every setting, nor does it create a universal right to local operation. Still, it establishes a useful principle: purchasing a connected object should not make the person merely a temporary guest in the data produced by its use.
Technical standards can reduce the practical cost of exit. Matter, for example, defines a local smart-home fabric and allows devices to connect to multiple administrators. Its controllers can live in phones, hubs, switches or buttons, and multiple controllers can provide convenient or redundant control. Interoperability does not solve every dependency, because platforms may still differentiate through cloud services and proprietary features. It does, however, show that local communication and a choice of control systems are engineering options, not fantasies.
The strongest objection is complexity
Every alternative path costs money to design, test, document and support. Physical controls occupy space and can fail. Local processing requires hardware. Multiple modes can confuse people and widen the security surface. In safety-critical products, allowing an uninformed override may create a greater danger than refusing one. A medical infusion pump should not treat “manual” as permission to bypass dosage safeguards.
This objection is persuasive. The answer is not to demand identical switches on every connected object. It is to define the essential capability and the safe boundary of human control for each use. A manual mode may preserve operation, permit a safe shutdown, expose status, or allow export and migration. What matters is that the fallback is intentional, understandable and tested under the failures it claims to survive.
Accessibility reinforces this need for plural paths. Automation may be the only practical route for one person; tactile control may be indispensable for another. Voice control can help someone who cannot reach a switch and exclude someone whose speech is not recognised. A screen can enlarge text and still be unusable when attention must remain elsewhere. Human-centred design does not crown one interface as natural. It preserves more than one credible way to act.
A simple test before calling a device smart
Manufacturers should be able to answer three connected questions in ordinary language. What essential function remains when the internet, app or account is unavailable? How does the owner recover control after a failed update, lost phone or service shutdown? How can the owner retrieve useful data and move to another system?
The answers should be visible before purchase, not discovered during an outage. They should state which features are local, which require a vendor service, how long security updates will continue, what happens at the end of support and whether the device can operate safely when disconnected. A buyer should not need to reverse-engineer the product’s dependency graph from marketing phrases.
This is part of the wider question Alkemata explored in The Revenge of the Hands: whether technology extends human capability or quietly makes competence conditional on someone else’s system. The physical button is not sacred, and manual action is not always superior. What deserves protection is the person’s ability to understand the available paths and retain a workable one when the preferred path closes.
A truly smart device should fail in a way that leaves its owner more than an inert object and a support page. The remaining engineering challenge is to make graceful degradation as measurable and marketable as the features that depend on everything going right.
If you value writing about technology and human agency, subscribe to Alkemata for future articles.