The first devices that phoned home

The moment the appliance called out

The household object with a network port was not, at first, understood as something that could expire. It was a novelty — a refrigerator that could check a recipe site, a coffee maker that accepted a schedule over dial-up, a thermostat that sent temperature logs to a web dashboard. The dependency on a remote server was experienced as a feature: you could see your data, control your device from elsewhere, get alerts on a pager. Nobody in 1999 was thinking about what happened in 2007 when the company behind it quietly closed its doors.

The first wave arrived roughly between 1998 and 2003, riding the consumer broadband expansion in the United States and Western Europe. These were not sophisticated devices by any subsequent standard. Many communicated over standard TCP/IP through home routers that were themselves new enough to confuse their owners. A few used proprietary wireless protocols over the 900 MHz band. What they shared was a design assumption: the appliance's intelligence lived partly or entirely on a server the manufacturer controlled, and the appliance was correspondingly dumb without it. That assumption — made casually, without much commercial pressure to examine it — turned out to be load-bearing.

The products and what they actually did

Most did neither, which meant the service was subsidised by the product margin and had a finite life tied to the manufacturer's business health.

The LG Internet Refrigerator ↗, shown at trade exhibitions around 2000 and 2001, became the archetype for journalistic ridicule, but it was a genuine product rather than a concept. It included an embedded Windows CE terminal on the door, a barcode scanner for logging grocery inventory, and a connection to an LG-operated service for recipe and shopping data. The server dependency was total: without the backend, the terminal was an expensive screen showing nothing useful. LG's early internet appliance program has not operated for decades. The hardware is landfill.

Sunbeam's Mister Coffee with internet scheduling, marketed around 2000 under the brand's "Smart" line, accepted brewing schedules sent over a home network. The scheduling logic that the user interacted with resided on Sunbeam's servers rather than in the device's own firmware. When the service closed, the appliance reverted to its manual controls — which was a best case outcome the industry would rarely match as devices grew more complex. At least the coffee came out.

Honeywell and its competitors were shipping web-connected thermostats before 2005, and the pattern there was subtler. The thermostat itself could run a schedule programmed locally, but its cloud dashboard — the part that let you adjust the temperature from a browser at work — depended on Honeywell's own relay servers. Early commercial building controllers and some residential units from this period are still in place, running their local schedules in isolation, the remote-access layer long dead. That accidental resilience came from having a meaningful local fallback, not from any design principle.

The broadband router itself entered homes during this window and immediately acquired its own dependency structure. Routers from this era would poll manufacturer servers for firmware updates and, in some implementations, for configuration validation. The update mechanism was rudimentary and often insecure, but the phone-home behaviour was there from the first generation. When a manufacturer exited the consumer networking market — as several did between 2002 and 2008 — routers stopped receiving patches and the update servers went dark, leaving devices exposed and without the ability to self-correct.

What was not designed in, and why it mattered later

Open protocols existed in 1999. MQTT ↗, the lightweight publish-subscribe messaging protocol designed by Andy Stanford-Clark and Arlen Nipper, had been specified in 1999 for constrained network links, and it was precisely suited to the kind of low-bandwidth, intermittent communication these appliances needed. It was not used in consumer products because consumer products were built to create closed ecosystems, not open ones. The commercial incentive was to keep the user inside a branded service, not to make the device interoperable.

Zigbee's predecessor specifications were being developed by the same period, aiming at a low-power mesh radio standard that devices from different makers could share. The Zigbee Alliance — now the Connectivity Standards Alliance ↗ — formalised the specification in 2004. Consumer product manufacturers largely ignored it for the better part of a decade. The radio protocols that would eventually prove durable were available; the industry chose not to use them.

The dependency was also financial in a way that was not disclosed to buyers. Running a cloud service costs money — servers, bandwidth, engineering staff to maintain the API. A connected appliance sold at retail generated no ongoing revenue unless the manufacturer layered in a subscription or sold the usage data. Most did neither, which meant the service was subsidised by the product margin and had a finite life tied to the manufacturer's business health. When a startup failed, or when a division was wound down, the server went with it — and the device became, in the terminology that would later develop, a tethered device whose tether had been cut.

Resale value was the first practical signal that something was structurally wrong. A five-year-old non-connected appliance sold used for a fraction of its original price, limited by age and wear. A five-year-old connected appliance sold for less, or not at all, because a buyer had no way to know whether the manufacturer's service would outlast the purchase. By the mid-2000s, listings for early internet appliances on secondary markets were effectively worthless. The hardware worked; the network layer did not; the product was not the hardware.

iFixit, which began documenting device repairability systematically from 2003, noted early that the teardown of a connected appliance raised a question that a teardown of a mechanical one did not: even if every component was replaceable, who controlled the software that made it function? A cracked screen on a laptop could be fixed. A dead authentication handshake, where the device required a valid response from a server that no longer existed, could not.

The pattern, set early

By around 2005, the template was complete. A consumer electronics company could sell a hardware product at or near cost, build the product's core utility around a server it operated, collect whatever data the device generated, and face no obligation — legal, regulatory or reputational — to maintain that server for any defined period. The buyer purchased a device; they received, without being told as much, a subscription to an infrastructure they did not control and could not replace.

The European Commission would not begin examining connected-product obligations in earnest until the 2010s, and the legislation that emerged from that examination — the Radio Equipment Directive ↗ and eventually the Cyber Resilience Act — arrived well after the pattern had replicated across hundreds of product categories. The devices shipped between 1998 and 2005 established the default, and the default proved sticky. Nothing that came later, from smart speakers to connected locks to robot vacuums, invented a new problem. It shipped the same problem at higher volume, with a more polished interface and a shorter stated support window.

The server dependency was not an engineering oversight. It was a product decision, made at the beginning, when nobody had yet seen what the end looked like.