When the Manufacturer Shuts Off the Cloud
Why this matters
A connected device is two products sold as one: the hardware on the wall and a service running on someone else's servers. The hardware is built to last a decade. The service lasts as long as the manufacturer keeps paying for it, and when it stops, the customer calls the last company that touched the device, which is often you. A shop that can say in advance which parts of an install survive a shutdown, and can choose equipment that keeps working without the server, turns that call from an argument into a five-minute answer.
Three ways a device leans on a server
Every connected device sits somewhere on one axis: where does the decision get made when the device acts? The answer sorts installed equipment into three groups, and the group decides what a shutdown costs.
| Group | Where the logic runs | What a server shutdown does |
|---|---|---|
| Cloud-only | On the manufacturer's servers; the device is a remote sensor and actuator | The device stops doing its job. A camera stops recording, a plug stops switching on schedule |
| Cloud-first, local fallback | Schedules and safety logic on the device; the app, alerts and remote access through the server | The core function keeps running. Everything the customer reaches through the phone goes dark |
| Local-first | On the device or a hub in the house; the server is optional, for remote access only | Almost nothing changes inside the house. Remote access may be lost unless the hub supports another path |
The common mistake is to judge a device by whether it has an app. Nearly everything has an app. The question is what still happens when the phone, the internet connection and the manufacturer are all absent. A useful shorthand: local means the device or a hub on the customer's own network makes the decision; cloud means a server you do not control makes it.
See related: Cloud, Local and Hub-Based Devices, which owns this taxonomy in full. This card is about the day the server goes away.
What actually stops, function by function
A shutdown rarely kills a device outright. It removes functions one at a time, and the order matters because customers notice the visible ones first and miss the dangerous ones.
- Remote control and status. First to go and most noticed. The customer opens the app and it cannot reach the device.
- Alerts. The one that hurts. A leak sensor that still closes a valve but no longer texts anyone has kept its local job and lost the reason most customers bought it, which was finding out while away.
- Schedules and automations. On a cloud-first device they usually survive, because the schedule was already copied to the device. On a cloud-only device they stop at the next scheduled event.
- Recording and history. Cloud video storage, energy history and event logs vanish. Export them before the date if the customer cares.
- Setup and re-pairing. The quiet killer. A device that is working today may be impossible to commission again after a factory reset, a router change or a new Wi-Fi password, because commissioning ran through the server. Tell the customer this one plainly: the device works until the day something resets it, and then it does not.
- Firmware. Security patches stop. The device keeps running on its last version indefinitely, with every flaw found after that date left open.
CLOUD-ONLY LOCAL-FIRST
sensor -> router -> internet sensor -> hub (in house)
-> vendor server -> valve / relay
-> decision -> alert via hub
-> internet -> router
-> actuator internet only for phone
access from outside
cut the server: no action cut the server: house
still acts on its own
The left path leaves the house and comes back, so the customer's internet service and the vendor's server sit in the middle of every action. Either one failing stops it. The right path never leaves the house.
Reading the box before you install
You can usually tell which group a device belongs to before it goes on the wall, without trusting the marketing. Five checks, in rough order of reliability:
- Does first setup require creating an online account? If the device cannot be commissioned at all without one, commissioning depends on the server, and so will every future re-commissioning.
- Does it work with the internet unplugged? Set it up on a bench, then pull the router's internet connection (leave the Wi-Fi running) and see what still works from the app on the same network. This is the single best test and takes about ten minutes.
- Does it support a local standard? Devices built on Zigbee, Z-Wave, Thread or Matter can usually be controlled by a hub in the house rather than only by the maker's server. Support for a standard is necessary, not sufficient: check that the function you care about is exposed locally, not just basic on and off. See related: Wi-Fi, Zigbee, Z-Wave, Thread and Matter Explained.
- Is a support period published? Some makers state how long they will provide security updates. A stated period is a commitment you can repeat to the customer; no statement is the commonest case and tells you nothing either way.
- What does the manual say happens offline? Many manuals have a short section on behavior without connectivity. If it does not exist, assume the worst group.
Matching dependence to the life of the install
The decision rule is a ratio. Compare how long the hardware will be in service against how long you can reasonably expect the server to last, and choose local-first whenever the first is much longer than the second.
Long-life installs, where local-first matters most. Automatic water shutoffs, door locks, thermostats, garage door openers, circuit monitors in a panel, irrigation controllers, alarm communicators. These are expected to serve for ten years or more, they are behind walls or on doors where swapping them is a trip and a labor charge, and several of them protect property. A water shutoff that loses its alerts in year four has given the customer four years of what they bought ten years of.
Short-life or easy-swap devices, where cloud-only is acceptable. Plug-in smart plugs, a bulb, a battery camera on a shelf. If the server goes, the customer unplugs it and buys another; nothing was installed.
What changes the answer. A customer who wants a specific feature only a cloud product offers can have it, provided you write down that they chose it after hearing the trade-off. A rental property that turns over every year may prefer a cloud-only device because the landlord manages it remotely and replaces hardware anyway. A vacant or seasonal home inverts it hard: there the alerts and remote access are the entire value, so the device needs a remote path that does not depend on one maker, such as a local hub with its own remote service or a cellular communicator. See related: Cellular Backup and Alarm Communicators.
Worked example: the notice arrives
A customer forwards an email: the maker of three devices in their house will retire its app and servers in about 90 days. Your install record shows all three, installed four years ago. Work it device by device, because the answer is different for each.
Thermostat, cloud-first. The schedule lives on the device. After the date it will keep heating and cooling on its last schedule. Lost: remote adjustment, the vacation mode the customer sets from the airport, and the filter reminders. Risk: if the thermostat is ever reset, it can still be set up at the wall, because its manual shows a local setup menu. Verdict: keep it, tell the customer what they lose, and offer a replacement only if they rely on remote control.
Leak sensors and shutoff valve, cloud-first. The bench test you ran at install (it is in your record, which is why records matter) showed the valve closes on a sensor trip with the internet unplugged. So the valve will keep protecting the house. What it will not do after the date is tell anyone. The customer travels for about a third of the year, so for that third of the year a closed valve and a wet floor will go unseen until they return. Verdict: replace the communication layer before the date. If the sensors speak a local standard, a hub in the house can take over alerts; if not, replace the system.
Video doorbell, cloud-only. Recording, motion alerts and live view all run through the server. After the date the button will probably still ring the indoor chime through the existing transformer wiring and nothing else. Verdict: replace it, and export any clips the customer wants before the date.
So of three devices, one keeps its main job and loses conveniences, one keeps its local job and loses its reason for being there, and one keeps only the chime. The customer hears "your smart home is shutting down" from the email. What they need from you is the three different answers.
The failure mode. A tech who reads the notice and says "they all stop working" sells two unnecessary replacements and loses the customer's trust when the thermostat keeps running. A tech who says "the devices will keep working" leaves a frequent traveler with a valve that closes silently. Both are wrong in the same way: they answered for the brand instead of for each function.
Telling the customer honestly
Say it in terms of what they will notice, in order of what matters. Lead with protection, then convenience. For the shutoff above: "The valve will still close if a sensor gets wet. What stops is the text message, so if you are away you will not know until you get home. Because you travel, that is the part I would fix before the date."
Three things to avoid. Do not promise a shutdown will not happen to a device you are installing today; nobody can. Do not imply the old installer was careless for choosing it; four years ago it was a reasonable product. And do not quote a replacement before you know which group the current devices fall into. Write the conversation and the customer's decision on the job record.
What the law does and does not promise
This is not legal advice, and it is a fast-moving area. As of 2026, there is no federal rule in the United States requiring a maker to keep a server running for any set period. FTC staff published findings in 2024 that most connected-product makers did not disclose how long they would support their devices, and warned that a failure to disclose could in some cases run into the federal Magnuson-Moss Warranty Act; whether it does for a given product is a question for an attorney, not for a tech at the door. A few states have consumer-protection statutes that could reach a sudden shutdown, and they vary; a customer asking whether they are owed a refund should take the shutdown notice and the purchase record to their state attorney general's consumer office or their own attorney. Outside the United States, the United Kingdom has required makers of consumer connectable products to publish a minimum security-update period since 2024. Re-check the current position each year; this is exactly the kind of fact that changes.
What the shop can bank is operational, not legal: a written record that you explained the dependence at install and the customer chose the device anyway.
References
- U.S. Federal Trade Commission, 2024 staff findings on software support disclosure for connected consumer products
- UK Product Security and Telecommunications Infrastructure regime, minimum security-update period disclosure
- Manufacturer installation manuals, sections on offline and local operation
- See related: Cloud, Local and Hub-Based Devices
- See related: Firmware Updates: The Silent Change to Installed Equipment; Leaving a Device Record the Next Tech Can Use