Will your smart home still work when the internet is down? A local-control and outage matrix

Direct answer: some functions may keep working, others may stop, and the answer can differ inside the same product. A smart device works through an outage only when every dependency needed for that particular action is still available. That can include the device, your local network, a hub or controller, automation logic and sometimes a vendor cloud.

The useful question is therefore not “Is this device local?” It is:

For this exact action, on this exact model and software version, where does the command travel and what happens when each dependency fails?

This guide is for householders planning a smart home or checking an existing one. It is not a promise about every product carrying the Matter, Thread, Wi-Fi, Zigbee or Z-Wave label. Current behaviour must be verified for the exact device, platform, firmware and feature.

The principal limitation

Product pages often describe protocols and headline compatibility, but do not document every failure mode. A device may provide local switching while sending notifications, storing history or running advanced recognition in the cloud. If the documentation does not state what happens during a particular outage and you have not tested it safely, the correct classification is UNKNOWN.

A five-part mental model

Think of a smart-home action as a chain:

1. Device: the light, thermostat, lock, sensor, camera or appliance that performs the physical action.
2. Local connection: Ethernet, Wi-Fi, Thread or another radio link that carries messages inside the home.
3. Hub or controller: a bridge, Thread Border Router, platform controller or automation server that may route commands or run rules.
4. Cloud service: a vendor or platform service used for accounts, remote access, video storage, recognition, notifications or automation.
5. Control surface: a wall switch, device controls, app, voice assistant or remote web interface.

NIST describes a consumer IoT product as more than the device alone: it can include gateway hardware, companion software and backend cloud services. That is why one logo cannot describe the resilience of the whole product.

Matter is an application standard that uses IP networking over technologies including Wi-Fi, Thread and Ethernet. The Connectivity Standards Alliance describes Matter as local connectivity and Google documents a local fulfilment path for Matter devices. Matter can therefore remove a cloud hop from a supported control path. It does not prove that every vendor feature, automation, notification, account function or remote-control path works offline.

Thread is a local IP mesh. A Thread Border Router links the Thread network to the home’s Wi-Fi or Ethernet network. If the only required border router or controller fails, a Matter-over-Thread device may still be powered but lose the path needed by the app or automation. Multiple compatible border routers can provide network redundancy, but only when the implementation and shared credentials support it.

Five useful classifications

Classify a function, not an entire brand:

• LOCAL: the action is completed by the device and local network without a vendor cloud or dedicated hub. Example: a same-home command sent directly over the LAN, if the manufacturer documents that path.
• LOCAL-WITH-HUB: the action stays inside the home but requires a powered hub, bridge, controller or automation server.
• CLOUD-DEPENDENT: the action requires a reachable external service.
• HYBRID: a local core works, while other functions require a cloud, or the product can use more than one path.
• UNKNOWN: the available evidence does not establish the behaviour for the exact function and outage.

These are Nerd Mango working classifications, not certification labels.

Start with the outage, not the product label

1. The internet connection fails, but power and the local network remain

This is the most useful resilience test. Your router and Wi-Fi can continue moving local traffic even when the wide-area internet link is unavailable. Local and local-with-hub functions may continue if their controller and app do not need a cloud check. Cloud-dependent functions stop until the connection returns.

Do not assume the app result tells you what the device can do. Google documents, for example, that an offline Nest thermostat can still be adjusted on the thermostat itself even though app control is unavailable. Google separately documents that an offline Nest camera cannot stream live video or save video to the cloud. Two products in one ecosystem can therefore have very different outage behaviour.

2. The vendor or platform cloud fails

The home still has internet access, but a required service is unavailable. Test or document separately:

• physical controls;
• same-home app control;
• local automations;
• voice commands;
• remote control;
• alerts and push notifications;
• history, recordings and analytics;
• account login and new-device setup.

A service-status outage can look like a device or Wi-Fi problem. Google’s troubleshooting guidance explicitly separates power, ISP, Wi-Fi and Nest-service outages. That diagnostic separation is broadly useful even though the resulting behaviour remains product-specific.

3. The vendor stops operating or ends support

This is not merely a longer cloud outage. Account servers, app distribution, certificates, firmware updates, replacement-device onboarding and support channels may also disappear. A documented local path may preserve core control, but future setup or recovery can still fail.

NIST’s consumer IoT baseline expects manufacturers to communicate support terms, update availability and the end of support or functionality. Before buying a long-lived device, record the support commitment and what can be exported, reset or operated without the vendor account.

Do not write “works if the company disappears” unless the documentation and a safe test cover cold start, account expiry, app availability and replacement of a controller—not merely today’s warm, already-configured state.

4. The hub, bridge or controller fails

Local-with-hub functions stop when their required hub stops. Physical controls may still work; devices may retain schedules internally; another controller may or may not take over. Apple, for example, documents that a home hub enables away-from-home control and that Thread-enabled Matter accessories need a Thread-capable home hub or supported third-party border router. Current Apple documentation also notes that some recent iPhone configurations can add and control Matter accessories without a home hub, while recommending a hub for the best experience. Exact behaviour therefore depends on the platform, phone, accessory and feature.

For every required hub, ask:

• Is configuration backed up?
• Can a replacement hub be commissioned without the old one?
• Do automations live on this hub, in the cloud or on the device?
• Is there a second compatible controller or border router?
• What happens to locks, heating, alarms and other consequential functions during replacement?

5. The local network fails but internet service may still exist

If the router, access point or local DNS/DHCP service fails, Wi-Fi and Ethernet devices may lose the path to both local controllers and the cloud. A Thread radio mesh may retain local connectivity among participating devices, but app access usually needs a working path through a border router into the home network. The exact result depends on which controllers and services the function needs. A physical button or device schedule may remain available while app control stops.

Treat the router, access points, switches, hubs and their power supplies as part of the smart-home system. Internet resilience and local-network resilience are separate design problems.

The local-control and outage matrix

Create one row for each important function. Do not write one row for the whole product.

“Record” means write works, does not work, degrades, or unknown, with the exact model, firmware, controller and date.

How to fill the matrix without guessing

1. Name the action precisely. “Turn on a light from its wall switch” and “turn on the same light by voice while away” are different functions.
2. Draw the normal path. Include the phone, router, radio, hub, automation engine and any cloud named in the documentation.
3. Find exact-model evidence. Look for architecture notes, outage behaviour, local API statements, hub requirements, storage location, support term and reset procedure. A protocol badge is only one piece of evidence.
4. Mark missing evidence UNKNOWN. Marketing words such as “fast”, “reliable” or “works with” do not establish offline behaviour.
5. Run only a safe outage test. Before disconnecting the WAN, check whether anyone in the household depends on the connection for emergency communication, work, health, security or another consequential service. Notify occupants, choose a safe test window, keep an alternative emergency-communication route available and know how to restore the connection immediately. Then, for a convenience device, disconnect the router’s internet/WAN link while leaving the LAN and power on. Test the listed functions one at a time. Restore the link and confirm recovery.
6. Test a hub restart separately. Do not confuse an internet test with a hub-failure test.
7. Repeat after material updates. Firmware, app, platform and account changes can alter the path.

Do not deliberately disable connectivity for a lock, smoke/CO alarm, medical device, security alarm, garage door, critical heating/cooling control or any system where failure could endanger a person or property. Use documentation, a controlled non-critical test system or qualified installation support instead.

Three planning examples

A lighting system where manual control is essential

Require wall controls that operate the load without internet. If app automations matter, verify where those automations execute and whether the hub is a single point of failure. Treat remote control and notifications as separate, non-essential functions.

A camera where recording matters during an outage

Ask where footage is stored, whether recording continues without the internet, how long local storage lasts, whether the app can reach that storage on the LAN and what happens when the camera later reconnects. “The camera remains powered” is not the same as “the required evidence is still recorded.”

A thermostat where safe basic operation matters

Confirm that temperature can be changed at the device and that a safe schedule or control mode remains during network loss. Treat remote changes, energy reports and cloud automations as separate functions. Never infer safety from a convenience-feature test.

A practical buying rule

For every important function, prefer the least fragile path that meets the need:

1. a physical or manual fallback;
2. documented local operation;
3. a replaceable local controller with a recoverable configuration;
4. cloud features only where their loss is acceptable.

This is an editorial resilience hierarchy, not a universal product ranking. Cloud services can add valuable remote access, processing and support. The point is to know which capabilities you are renting from a continuing service and which remain inside your home.

Final check

Before calling a smart-home function “local”, you should be able to answer:

• What exact action is being classified?
• Which device performs it?
• Which network and controller carry it?
• Where does the automation run?
• Does it require account or cloud validation?
• What still works when the WAN is disconnected but the LAN remains?
• What fails when the hub is powered off?
• Can the system be restored or recommissioned without the original vendor service?
• What evidence supports the answer, and when was it checked?

If any material answer is missing, write UNKNOWN. That is more useful than false confidence.

Sources

• SH-S01 — Frequently Asked Questions — consumer IoT product components — NIST; retrieved 2026-08-07; market GLOBAL.
• SH-S02 — Matter FAQs — Connectivity Standards Alliance; retrieved 2026-08-07; market GLOBAL.
• SH-S03 — What is Matter? — Google Home Developers; retrieved 2026-08-07; market GLOBAL.
• SH-S04 — What is a Thread Border Router and how is it different from a hub or bridge? — Thread Group; retrieved 2026-08-07; market GLOBAL.
• SH-S05 — Multiple Thread Networks and the Seamless Interconnectivity of IP — Thread Group; retrieved 2026-08-07; market GLOBAL.
• SH-S06 — Troubleshoot your Nest thermostat is offline — Google Nest Help; retrieved 2026-08-07; market GLOBAL.
• SH-S07 — Fix issues with your Nest camera or doorbell Wi-Fi — Google Nest Help; retrieved 2026-08-07; market GLOBAL.
• SH-S08 — Troubleshoot Wi-Fi and connection issues for Nest products — Google Home and Nest Help; retrieved 2026-08-07; market GLOBAL.
• SH-S09 — Profile of the IoT Core Baseline for Consumer IoT Products — NIST IR 8425 — NIST; retrieved 2026-08-07; market GLOBAL.
• SH-S10 — Set up HomePod or Apple TV as a home hub — Apple Support; retrieved 2026-08-07; market GLOBAL.
• SH-S11 — If you cannot add a smart home accessory to the Home app — Apple Support; retrieved 2026-08-07; market GLOBAL.