Will your smart home outlive
the company that sold it?
Cloud services can close long before a house needs rewiring. The century test is not whether today’s electronics last forever—it is whether essential controls remain useful and every digital layer can be replaced.
A durable smart home is a replaceable system, not an immortal product.
A company closing should remove support and optional internet conveniences—not your ability to turn on a light, unlock the door locally, close a shade or set a safe temperature. Those essential actions need physical controls and logic that live in the home.
Remote access can also survive, but it needs a new route: open or documented devices, a controller you own, and a secure connection back home. A protocol badge helps only for the functions that the product actually exposes.
One shutdown removes
different layers.
“Still works” is too vague. Test each capability independently and distinguish a local fallback from a complete replacement experience.
| Capability | What can remain | What is at risk |
|---|---|---|
| Physical switches and manual operation | Should continue if controls act locally and essential loads have a mechanical, wired or direct-radio fallback. | Cloud-only buttons, app-only controls and inaccessible proprietary actuators may become unusable. |
| Local app control and automations | Can continue when the controller, rules and device communication all run inside the home. | Automations evaluated on vendor servers, account-dependent apps and cloud APIs stop. |
| Voice and web integrations | A locally processed voice system or a new integration may be substituted. | Most mainstream voice assistants and web-service links need internet services and fresh account authorisation. |
| Remote control and notifications | Can be rebuilt through a securely exposed local controller, managed encrypted tunnel or private VPN. | The vendor app, push gateway, remote video relay and its notifications disappear with the service. |
| Locks, users and temporary codes | Keypad, key, thumb-turn and locally stored credentials can remain; an independent controller may manage standardised credentials. | Cloud-created guests, histories and proprietary remote-unlock flows may not transfer. |
| Doorbell, camera and intercom | Local streams, recording and two-way audio may move when the exact ONVIF, RTSP or SIP functions are exposed. | Vendor-relayed live view, cloud recordings, rich alerts and talk-back often stop or port only partially. |
| History, recordings and energy data | Locally stored data and documented exports remain under the owner’s control. | Cloud history can become inaccessible, and a replacement platform normally starts with an empty database. |
| Firmware and security fixes | Devices with standards-based update delivery or released firmware may remain maintainable. | Unsupported products accumulate unpatched risk even if their basic local function survives. |
Design the house to stay.
Let electronics change.
Twenty-five years: expect replacements
Power supplies dry out, radios change, batteries fail and security requirements move on. A switch module surviving for decades is welcome, but it is not a sound system plan. Put actuators, gateways and power supplies in labelled, ventilated and accessible locations. Use standard electrical loads and retain a documented way to operate them when a smart module is removed.
Fifty years: preserve the infrastructure
Conduit, cable routes, back boxes, distribution space, manual controls and project records can serve several generations of electronics. A future electrician should be able to identify the protected circuit, bypass or replace an actuator, and understand which low-voltage cable goes where without reverse-engineering a sealed ceiling.
One hundred years: keep the home understandable
No responsible buyer should assume a connected switch, phone app or certificate will operate unchanged for a century. The useful ambition is architectural: finished walls do not trap irreplaceable hardware; basic services do not depend on a login; interfaces are documented; and a future controller can take over without discarding every endpoint. “Forever” is a property of replaceability.
Keep the intelligence at home.
Add the internet deliberately.
A resilient installation separates four layers so any one can be changed without replacing the others.
Devices and physical controls
Switches, relays, locks, sensors and motors must perform essential local actions without an account.
Local controller and automation
A replaceable computer or hub owns schedules, scenes, device relationships and local history.
Secure remote gateway
An authenticated encrypted tunnel or private VPN reaches the local controller without exposing devices directly.
Optional outside services
Voice assistants, weather feeds and cloud analytics add convenience without becoming the only path to control.
What “personal cloud” actually means
You usually cannot download a manufacturer’s proprietary cloud and run it yourself. You replace its role. Home Assistant, openHAB or another locally hosted controller communicates with supported devices inside the house; a managed encrypted tunnel or private VPN then gives authorised phones a route to that controller. Optional voice and web services sit above it. If one outside service closes, the local home continues.
Ask what can move—
and how much moves.
Interoperability is a feature-by-feature claim. Test the actual model with the intended replacement controller before treating a logo as an exit plan.
Good route for standard functions
Multi-admin lets a device join more than one controller, including a locally run controller. Add the alternate controller while the original ecosystem still works. Routines, history and manufacturer-only features do not migrate automatically, and some bridges require the vendor app to enable Matter.
Portable radios, not universal feature promises
Many devices can join an independent coordinator used by Home Assistant or openHAB. Expect re-pairing unless a supported coordinator backup can move the network; preserve Z-Wave security keys. Confirm the exact model because vendor-specific clusters and features vary.
Strong building-level continuity
A standardised field bus can outlast a particular interface or visualisation server when the project file, group-address schedule, passwords and programming access are handed over. Proprietary extensions remain separate risks.
Useful when the interface is genuinely local
A documented, authenticated API can let another controller operate the product without its cloud. Ask whether initial activation, tokens, certificates or periodic re-authorisation still depend on the manufacturer.
Specify the functions, not only the logo
ONVIF Profile T can cover video, events and bidirectional audio; RTSP may provide only a stream; SIP can make an intercom callable. Verify the model in the conformance database and test talk-back, door relay, events and recording separately.
Replacement is often the only migration
If every command passes through a vendor account and there is no supported local interface, open-source software cannot manufacture one after the servers close. Community reverse engineering may help, but it is not a purchase-time resilience plan.
Open the door from work—
without opening the network.
Remote convenience can be independently operated, but an internet-facing lock or controller must never be the shortcut.
For a maid or regular visitor
Prefer a separate identity or time-limited code over sharing the owner’s account. Restrict it to the right door and schedule, record its use, make revocation immediate, and confirm that codes are stored in the lock or local controller—not only in a vendor database. Keep a non-cloud entry method for an internet outage.
For a delivery person at the door
Remote live view, ringing, notifications, two-way audio and door release are five distinct functions. A camera may expose a local video stream while keeping talk-back and push alerts proprietary. Specify and test each one. Where remote release is allowed, authenticate the operator, verify the visitor, log the action and avoid exposing the camera, intercom or lock directly to the public internet.
Questions for the vendor
and installer.
Require written, model-specific answers. “Open,” “local,” “Matter-ready” and “works with” are not substitutes for a demonstrated recovery path.
- 01
With broadband disconnected—not merely with the app closed—which switches, locks, shades, climate controls, scenes and schedules still work?
- 02
If the company’s accounts and servers disappear permanently, can a new owner commission the product and perform a factory reset without contacting them?
- 03
What exact protocol, version, device type and certified profile does each product expose? Is the model listed in the relevant conformance database?
- 04
Can the device be added directly to a third-party controller such as Home Assistant or openHAB, or is it visible only through the manufacturer’s bridge?
- 05
Which features cross that interface: basic on/off, dimming, energy data, lock credentials, events, recordings, talk-back and relay release? Which remain proprietary?
- 06
Can automations, room names, users, access codes, history and recordings be exported in a documented format, and what will not transfer?
- 07
Who receives the Matter setup codes, Thread credentials, Z-Wave keys, Zigbee coordinator backup, API credentials, KNX project and as-built drawings?
- 08
Can ownership be transferred with the house without using the installer’s or previous owner’s personal account?
- 09
What is the promised security-update period, how are updates delivered, and what written end-of-life or service-shutdown policy applies?
- 10
Can relays, power supplies, gateways and controllers be reached and replaced without breaking plaster, joinery or finished switch plates?
- 11
For remote entry, are there MFA, individual roles, expiring visitor codes, audit records and immediate revocation—and does a key or local keypad always remain?
- 12
Can remote access use an encrypted tunnel or private VPN without forwarding a device or controller port directly from the router?
Buy a home you can inherit—
not an app you can rent.
A cloud service is valuable for remote access, voice processing and effortless updates. It becomes a structural weakness only when it is the sole path between the owner and the hardware. Put essential control, automation and records inside the home; make outside services optional and replaceable.
The old switch lasted because its interface, wiring and failure mode were obvious. A modern smart home can earn similar longevity without pretending its chips are immortal. Preserve manual operation, accessible infrastructure, open or documented interfaces, credentials and a tested migration route. Then the technology can change while the home remains useful.
This guide describes standards and common platform behaviour as verified in September 2026. A protocol can preserve standard functions without reproducing a manufacturer’s complete app, automations, data history, security maintenance or remote service. Confirm exact model, firmware, controller and regional behavior before purchase.
- Belkin · Wemo support ending notice ↗
- Connectivity Standards Alliance · Matter FAQ and multi-admin ↗
- Home Assistant · Matter local control, multi-fabric and feature limits ↗
- Home Assistant · Operation without an internet connection ↗
- Home Assistant · Secure remote-access options ↗
- Home Assistant · Independent Zigbee coordination and binding ↗
- Home Assistant · Z-Wave network and security-key backups ↗
- ONVIF · Profile T video, events and bidirectional audio ↗
- KNX Association · Open building-control standard ↗
Find what remains when the
internet—or hub—goes down.
Permanent independence begins with ordinary local resilience. Separate failures of the broadband connection, network, controller, border router and coordinator before trusting the design.