When They Can Brick Your Fridge, You Don't Own Your Hardware

The risk of cloud-dependent hardware is simple: any device that needs a vendor's server to function can be disabled by that vendor, on purpose or by accident, at any time, with no input from you. You paid for the object. You never owned the thing that makes it work.

The fridge that ate itself

On September 22, 2026, Samsung pushed a firmware update to Bespoke AI refrigerators in South Korea through SmartThings. It went wrong immediately. Affected units "suddenly lost power and stopped functioning immediately after" the update tried to install, and South Korean broadcaster SBS reported hundreds of customer complaints filed within days.¹ Samsung's explanation was blunt: an error during its own internal testing of a refrigerator software update had gone out to real customers' appliances.¹

The timing made it worse. This happened right before Chuseok, Korea's three-day harvest holiday, when households stock refrigerators full of food for family gatherings. One user said he threw away 20 kilograms of spoiled food and asked, reasonably, how he was supposed to spend the holiday now.² Repair technicians couldn't reach some customers until October 1 or October 7, which meant entire households went without a working fridge for the full holiday despite having a brand-new, fully paid-for appliance sitting in the kitchen.²

A refrigerator is about as "dumb" a household object as exists. It keeps things cold. Samsung's version needed a server-side update to go right just to keep doing that.

This isn't a one-off

If Samsung were the only company to do this, you could file it under bad luck. It isn't. This is a pattern with a decade of receipts.

In 2016, Google's Nest division shut down the servers powering the Revolv smart home hub, a $300 device Nest had acquired along with its maker.³ Nothing physically changed about the hub. Google just turned off the cloud service it depended on, and the hardware went dark.⁴ Techdirt's commentary at the time nailed the underlying mechanic: "When you rent a product that only works as long as a company allows it to work, at some point, you are going to be left with nothing."⁵

In May 2024, Sonos shipped a rebuilt app that broke sleep timers, alarms, volume control, and accessibility features on speakers customers already owned.⁶ The fallout cost the company an estimated $600 million in market value, triggered layoffs, and ended with CEO Patrick Spence resigning in January 2025.⁶⁷

iRobot went a different route: it built the dependency in from the start. Its "Select" membership charged a monthly fee, and Roombas enrolled in the program simply stopped working without it, showing a "check your subscription status" error on hardware the owner had already paid for in full.⁸⁹ iRobot's own terms of service put it plainly: terminating the membership "will terminate your Robot's functionality entirely."⁹

And cloud dependency doesn't just create outage risk. It creates exposure risk. A researcher tinkering with his own DJI Romo robot vacuum, trying to rig it to a PlayStation controller, accidentally found a flaw in the cloud architecture that gave him access to roughly 6,700 other people's devices worldwide, including live camera and microphone feeds and floor plans of their homes.¹⁰

Four companies, four failure modes, one identical root cause: the hardware you hold in your hand isn't the whole product. The server is.

What does "cloud-dependent hardware" actually mean?

Cloud-dependent hardware is any physical device whose core function routes through a vendor's remote server rather than running entirely on the device itself. The fridge needs SmartThings to accept a firmware push correctly. The Revolv hub needed Nest's servers to interpret commands. The Roomba needed iRobot's billing system to say yes before it would clean a floor.

The mechanism that makes this risky is simple: a server-side change is a change you did not consent to and cannot undo. A vendor can push a broken update, shut down a service line, re-gate a feature behind a new fee, or get breached, and your device's behavior changes instantly, no matter what state your hardware is physically in. As our earlier look at bricked hardware and missing Git tags put it, if you don't control the software layer, you don't really own the thing on your desk, or in your kitchen.

How does cloud-dependent hardware actually fail?

Cloud dependency doesn't fail in just one way. There are four distinct patterns worth knowing, because each calls for a different fix:

1. Botched remote updates. A vendor pushes a firmware or app change that goes wrong and disables function on hardware that was working fine the day before, as with Samsung's fridges and Sonos's speakers.¹⁶
2. Server shutdown or end-of-life. The vendor decides to stop running the backend entirely, and hardware that depends on it becomes permanently inert, as with the Revolv hub.³⁴
3. Feature re-gating behind a new subscription. Functionality you had, or thought you'd bought outright, gets locked behind a recurring fee, as with iRobot's Select membership at $30 a month.⁹
4. Cloud architecture as a security and privacy liability. Because the device's data and controls run through a shared vendor backend, a single flaw can expose thousands of unrelated households at once, as the DJI Romo incident showed.¹⁰

Why do vendors build hardware that depends on their servers?

None of this happens by accident on the business side. Cloud-tethered hardware is a deliberate design choice, and the incentives behind it are straightforward:

• Recurring revenue. A subscription-gated feature turns a one-time hardware sale into a monthly line item, which is exactly what iRobot's Select program did.⁹
• Telemetry and data. Every command routed through a vendor's server is also a data point the vendor can use, sell insight from, or train on.
• Faster iteration. Server-side logic can be changed instantly, without a slow, expensive hardware refresh cycle, which is efficient right up until an update goes wrong.
• Lock-in. A device that depends on a proprietary cloud service is much harder for a customer to leave, because leaving means the hardware itself stops working. It's the same hardware lock-in playbook that shows up whenever a vendor controls the device instead of the buyer.

These are rational business reasons. They are also the exact reasons the customer ends up holding the risk instead of the vendor.

The SaaS parallel: renting your own business the same way

This isn't just a smart-appliance story. It's the same rent-versus-own dynamic, playing out at every scale.

The average US adult now spends $1,080 a year on subscriptions, and about $204 of that goes toward subscriptions they aren't even using.¹¹ That's the consumer version of the fridge problem: money committed to ongoing access rather than a thing you own outright.

Zoom out to the enterprise and the numbers get serious. Roughly two-thirds of businesses spend between $600,000 and $12 million a year on SaaS, and 22 percent spend over $12 million annually, according to Flexera's 2024 State of the Cloud survey of 753 IT professionals.¹² Every one of those dollars pays for the right to keep using software the business does not control. If the vendor changes pricing, sunsets a feature, or gets acquired and shut down the way Revolv was, the business ends up exactly where Sonos customers were during the app crisis: watching functionality they paid for disappear, with no lever to pull.³⁶

That's why the smarter move, for a business or a household appliance, is to look hard at which pieces of your stack are load-bearing and rented rather than load-bearing and owned. Some companies are already doing this by building internal tools they actually control instead of adding another vendor dependency to the pile, for the same reason you'd rather own a fridge outright than lease its compressor from a company that can flip it off remotely.

What does real hardware ownership actually require?

Ownership isn't a feeling. It's a set of concrete guarantees, and most cloud-dependent products fail to offer any of them:

1. A local-first fallback mode. Core functions, cooling a fridge, vacuuming a floor, playing a saved playlist, should keep working even if the vendor's server is unreachable.
2. Right-to-repair and parts-pairing protections. If a device is designed so only the vendor's server can authorize a part or a repair, you are renting your own hardware from the manufacturer indefinitely.
3. Contractual data and export rights. Before you buy into a platform, know exactly what you can pull out, and in what format, if the vendor shuts the service down.
4. Treating critical software as owned infrastructure. For a business, this means running the software your operations actually depend on, not just the appliance in your kitchen, on infrastructure you control rather than a subscription you're trusting to stay lit. Our piece on the hardware and software ownership renaissance lays out what that shift looks like in practice.

The bottom line

Samsung's fridges, Google's Revolv hub, Sonos's app, and iRobot's Select subscription are four unrelated companies that arrived at the same design pattern independently, and four unrelated groups of customers who learned the same lesson the hard way: if a vendor can flip a switch and turn your paid-for asset into a brick, you were never the owner. You were a tenant with a receipt. The fix isn't refusing every connected device. It's asking, before you buy or build, exactly what happens the day the server goes quiet, and deciding whether you can live with the answer.