Note, 6 October 2026

A software update should not be able to stop the fridge

On 22 September 2026 a software update that was still being tested reached Samsung refrigerators in customers' homes in Korea. Owners reported that theirs went dark and stopped cooling. Any team that ships updates can ship a bad one. This note is about how far a bad one should be able to get.

What happened

Samsung's notice to its Korean customers on 23 September says that an error occurred the day before, during the testing of a refrigerator software update, and that some customers' refrigerators showed abnormal symptoms in their power and screen. The company told Ars Technica that the issue was limited to Korea and that it suspended the testing as soon as reports came in.

The Chosun Daily names the line, Bespoke AI 4-Door, and what owners saw after updating through SmartThings: interior lights off, cooling lost, the refrigerator shown as offline. The paper reports that Samsung found the update "was incorrectly distributed to some customers during testing", halted the distribution, and will repair the units free of charge. Owners wrote that technicians replaced the main board, Android Authority reports.

Samsung has not said three things: how many units, how an update in testing reached customers, and what failed inside. We do not know how these refrigerators are built, and this note does not guess. What the reports describe is an outcome in four steps. An update still in testing was installed in a kitchen. Owners say the appliance's main job stopped with it. The remedy in Samsung's notice was a call to the service centre and a technician's visit. And it reached enough homes that, according to Ars Technica, the broadcaster SBS reported hundreds of cases. Each step is something a design can guard against.

Four things an update path should guard against

1. A build still in testing installs on a customer's unit

Let the device decide, not the server. Sign test builds with one key and releases with another, and give the units that leave the factory only the release key. A test-signed build sent down the wrong channel then ends as a refused image. A release candidate carries the release key, so it still needs the stages below. Keep the test units as a named fleet of their own, so that "all units" never includes them by accident, or the other way round.

Even the basic check, that an image is genuine, is not a given. A Moxa advisory of 2 October describes protocol gateways that do not properly verify the authenticity of a firmware image before installing it.

2. An update stops the main job

Whatever a device's one job is (cooling, heating, dosing, locking a door), give it a controller of its own that keeps its own settings, with firmware that changes rarely, and let the connected side ask it for things instead of running it. Then the part that takes an update every month can hang, restart or sit half written while the main job keeps its schedule. This is decided on the schematic before it is decided in code: which processor switches the load.

3. A unit does not come back by itself

Write the new image to a second slot and start it on trial. If it does not mark itself as good, the bootloader returns to the old image at the next reset. MCUboot, an open source bootloader for microcontrollers, calls this a test swap, and says it is there "to prevent devices from becoming 'bricked' by bad firmware". Three details decide whether it works. Good has to mean that the job is being done (the sensors read, the controller answers), not that the image started. An image that has not marked itself good within a set time has to reset. And a watchdog, running before the new image starts, has to force the reset when the image hangs instead of crashing.

4. A bad build reaches everyone at once

Release in stages: your own units, then a small share of the field, then the rest, with a wait between stages. Have every unit report in after an update, and let the rollout stop by itself when updated units go quiet. A rollout that watches its own units can stop before the first customer has to write.

What went right

One part of Samsung's response is worth copying. According to The Chosun Daily, it plans to find the affected customers from the update history. A record of which unit took which build, and when, turns "some customers' refrigerators" into a list of units. It is the first question in our note on the Cyber Resilience Act, and the third question there, whether a fix can reach the units, is this note seen from the other side.

A drill for the bench

Three tests on the bench, through your real update path. Send a test unit an image that starts and then does nothing: does the unit come back by itself, and does its main job run the whole time? Cut the power while an image is being written, and again while the bootloader is swapping it in. Then offer a production unit a build signed with the test key. What happens in each case shows how far a bad update can get on one unit.

All notes