DEV Community: NewLine Break

Your device will outlive your support

NewLine Break — Tue, 13 Oct 2026 12:32:36 +0000

On the night of 11 October 2026 a cyberattack hit the refrigeration of hundreds of French supermarkets. Danfoss, whose controllers were among those compromised, told AFP that most of its affected units no longer receive updates. A device keeps working long after its maker has stopped looking after it. This note is about those years.

What happened

E. Leclerc, Intermarché and Coopérative U confirmed to AFP that they had suffered a cyberattack. Their counts to AFP exceed 400 stores; BFM TV was told fewer. BFM TV reports that the attackers are said to have forced the automatic defrost to run continuously, set to 50 °C. Intermarché told AFP that the affected branches have to throw away all their fresh and frozen products. The Paris prosecutor's office has opened an investigation; it told AFP victims reported "foodstuff losses and the outbreak of fires".

France's CERT-FR, in an alert dated 12 October, says it knows of numerous compromises of Danfoss AK-SM and AK-SC remote refrigeration controllers. It now also lists Copeland and Dixell xweb units. It does not say how the attackers got in. It does say that attack campaigns are probably still under way, and that exposing a management interface online is in general against good practice.

Danfoss told AFP that most of the affected equipment was "legacy" products which "no longer receive software or security updates". Its statement to Cooling Post, as the paper reports it, names the AK-SM 800, declared end of life in 2021, and the AK-SC 355, phased out in 2016, and says the affected units of the current AK-SM 800A ran outdated firmware.

It had happened before

In its customer newsletter of October 2025 Danfoss listed earlier cases. "Russia, 2022: Sixteen supermarkets using AK SM 800 were targeted by cyberattacks at the start of the war." And "Israel, 2022: Forty stores were hacked. All affected stores lacked proper firewall or VPN protection, and all used AK SM 800." In the same text it says it enforces a "hard End of Service" on products past end of life, and recommends moving to its current model.

In 2023 Synacktiv reported that the SM800 firmware it tested accepted, besides a user name and password, a code of the day computed from the date alone, and gave out its date to anyone. By Synacktiv's account Danfoss answered that the flaw affected only end-of-life products, and set out network protections and a notice to customers. The advisory's mitigation is one line: "Restrict network access to the affected products." In August 2026 Claroty described a code of the day in the current AK-SM 800A as well, which it says Danfoss has fixed in newer firmware, and found 2,765 of those units exposed to the internet, by a Censys scan. Neither CERT-FR nor Danfoss has said whether any of this was the way in on 11 October.

Four questions for the years after

A maker cannot make a customer replace a machine that still works. It can decide, while it still writes the firmware, how the device behaves once nobody updates it. Four questions.

1. Who can reach it?

A device that serves its management page to whoever finds its address is one flaw, or one password, away from a stranger. Build it the other way round: the device calls out to your service and listens for nothing from outside, and a technician goes through that service, under a name. CERT-FR's advice for affected units: off the internet, and back only through a secure VPN or protected network.

2. Is there a way in that only you know?

A code worked out from the date alone would be one password for every unit, and it stops being yours the day somebody reads the firmware. If field service needs a way in, make it belong to one unit and need a person standing at it: a button held down, a code shown on the unit's own display.

3. What can a remote command not do?

Defrost is an ordinary function. Most devices have one like it: a mode that is harmless for minutes and ruinous for hours. Decide, for each, the limit that no setting can lift, and keep that limit close to the hardware, below the part that takes commands from the network. Send the alarm by a second route.

4. What happens on the last day of support?

Decide it while the product is new. Tell the buyer the date, and let the device show it on its own screen. Use the last update you will ever ship to close what you will no longer watch: remote management off, until someone standing at the unit turns it on. CERT-FR is blunt about end-of-life units left on the internet: they are very likely to be compromised, and a factory reset alone is not enough, because the unit stays vulnerable.

A drill

Three checks. List every product you have shipped that has a network port, each with the date of its last update. Search Shodan or Censys for the title of your product's management page and count the answers. Take one unit to the bench, pick the function that could do the most harm, and find out what stops it when the command comes from outside.

Sources

AFP: French supermarkets suffer refrigerator shutdown (12 October 2026)
BFM TV (12 October 2026, in French)
CERT-FR: alert CERTFR-2026-ALE-012 (12 and 13 October 2026, in French)
Cooling Post: Danfoss moves to mitigate cyberattack (12 October 2026)
Danfoss: Tech Insider October 2025 (31 October 2025)
Synacktiv: Authentication bypass in Danfoss SM800 and SC255 (2023)
Claroty Team82: Freeze the Controller, Defrost the Food (9 August 2026)

All notes

First published at newlinebreak.com/notes/device-outlives-its-support.

Your device is not a browser

NewLine Break — Wed, 07 Oct 2026 20:57:49 +0000

On 6 October 2026 Google said that attackers had compromised three country-code domain registries and used them to obtain HTTPS certificates, issued by real certificate authorities, for domains that were not theirs, several of Google's among them. Chrome blocked the certificates Google found. A connected device calling its server is not Chrome. This note is about what it would have done.

What happened

According to Google's account, the attackers compromised the registries of .gh, .sl and .as, changed DNS records, and obtained unauthorised certificates covering several Google domains and domains of other organisations. Google writes that it has "no reason to believe" the certificate authorities that issued them did anything wrong. Ars Technica reports that, holding the DNS records, the attackers passed the authorities' automated checks of who controls a domain. That Chrome had to block the certificates suggests it would otherwise have accepted them.

Chrome blocked the certificates for Google's own domains through CRLSets, the list it uses to block certificates in an emergency, and Google worked with the authorities that issued them to have those revoked, in its words "to protect users in clients other than Chrome". When Certificate Transparency logs showed certificates for other organisations, Chrome blocked those as well; Google does not say whether they have been revoked. It also writes that it cannot guarantee its analysis "identified every affected domain", and that Chrome's measures do not "reliably protect non-Chrome users". Its post does not name the other organisations or give a number of certificates.

A device is a client other than Chrome

A browser has a vendor that can send it a block list quickly. A device has the TLS library, the list of trusted authorities and the settings that were compiled into the firmware it runs. Whether a certificate like these could be used against your product is decided there. Four questions.

1. Whom does the device trust?

Some firmware projects compile in a whole public root list. ESP-IDF's certificate bundle, for one, comes by default with the complete list from Mozilla's root store, more than 130 certificates. With such a list any of those authorities can vouch for your server, and a certificate obtained through a hijacked registry would be accepted like the real one. A device usually talks to one or two servers. It can trust one authority. If that is your own, kept for device traffic, a certificate from any public authority is refused. If it is the one public authority you buy from, the list shrinks from more than 130 to one, but whoever controls your DNS can ask that same authority.

2. Does it check revocation?

Revocation is how Google meant to protect, for its own domains, the clients other than Chrome. It works only for a client that checks. Find out whether yours does, as you built it. Mbed TLS, the TLS library ESP-IDF builds on, tests a certificate against a revocation list only if your own code hands it one for the authority that signed the certificate; fetching the list is your job. Where nothing checks, a certificate that should not exist stays acceptable to the device until the day it expires, for anyone who can get between the device and its server.

3. Can you change the trust list in the field?

The list of trusted authorities is data, and it will have to change: an authority is distrusted, your own is replaced. In ESP-IDF the bundle is embedded in the application and changes with an over-the-air update. That update must not lean on the trust it is replacing. Have the device check the image's own signature, as in our note on updates, so that somebody holding a valid certificate for your update server still cannot install an image you did not sign. Add a version check, so that an old signed image is refused too. If you pin a single certificate or key, ship a second pin beside it, for a key you keep offline, and know the date the first certificate expires. Otherwise the pin locks out your own devices.

And over the connection itself: do not send a secret that can be used again, and give the commands that matter a signature of their own, with a counter, so that an old command cannot be played back.

4. What does the device's address hang from?

Google says its own systems were not compromised; the registries above its domains were. Every name depends on its registry, and .io and .ai are country codes, as .gh, .sl and .as are. For the name that is written into firmware, choose the registry on purpose, publish a CAA record that names the authorities allowed to issue for it, and watch the Certificate Transparency logs for certificates you did not ask for. The last two are Google's advice to domain owners, and Google is plain about the limit: CAA "can not prevent certificate issuance during an active DNS hijack". It counts once you have your DNS back, and the logs tell you after the fact.

A drill for the bench

Three checks. Count the authorities in your firmware's trust list and find the date the list was made. Put a test server behind your device's server name, on a test network of your own, with a certificate from a public authority you do not use, and see whether the device connects. Keep the test key on the bench, revoke the certificate afterwards, and see whether the device ever notices.

Sources

Google: Chrome's Response to Recent ccTLD Registry Hijacks (6 October 2026)
Ars Technica: Hackers obtain counterfeit TLS certificates for Google and other large services (6 October 2026)
The Chromium Projects: CRLSets
Espressif: ESP x509 Certificate Bundle, ESP-IDF programming guide
Mbed TLS API: X.509 module, the notes on mbedtls_x509_crt_verify
IANA: Root Zone Database
RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record

All notes

First published at newlinebreak.com/notes/your-device-is-not-a-browser.

A software update should not be able to stop the fridge

NewLine Break — Tue, 06 Oct 2026 18:00:21 +0000

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.

Sources

Samsung Members: notice on the refrigerator software error (23 September 2026, in Korean)
Ars Technica: Owners mourn spoiled food after firmware update bricks Samsung smart fridges (23 September 2026, updated 24 September with Samsung's statement)
The Chosun Daily: Samsung Refrigerators Fail After Update, Repairs During Chuseok (23 September 2026)
Android Authority: Samsung accidentally freezes its smart fridges with a software update (23 September 2026)
Moxa security advisory MPSA-269540, CVE-2026-86326 (2 October 2026)
MCUboot: bootloader design, the section on boot swap types

All notes

First published at newlinebreak.com/notes/update-that-stopped-the-fridge.

Cyber Resilience Act: what your devices should be able to tell you

NewLine Break — Tue, 06 Oct 2026 06:13:27 +0000

Since 11 September 2026, a manufacturer that learns one of its connected products is being attacked through a flaw has at most 24 hours to send an early warning. That warning is short. The notification due two days later is not, and most of it can only be answered if the device and the system behind it can tell you.

What changed on 11 September

Article 14 of the EU's Cyber Resilience Act, the manufacturer's reporting duty, applies from that date. Most of the rest of the regulation follows on 11 December 2027 (Article 71). The Commission's summary gives the clock for a vulnerability that is being actively exploited:

24 hours: An early warning, counted from the moment the manufacturer becomes aware.
72 hours: A fuller notification.
14 days: A final report, counted from the day a fix or a mitigation is available.

A severe incident runs on the same first two steps, with its final report due a month after the notification. Everything is filed once, through ENISA's Single Reporting Platform.

Article 69(3) says the duty covers products placed on the market before December 2027. If a product is in scope, that includes units shipped three years ago.

Whether a product is in scope, and who is its manufacturer, is a question for a lawyer. This note is about the engineering.

What the reports ask for

Article 14 reads like a list of questions. The early warning names the Member States where the product is known to be available. The notification gives general information about the product, the nature of the exploit and of the vulnerability, what has been done about it, and what users can do. The final report describes the vulnerability with its severity and impact, who exploited it where that is known, and the update that fixes it. Paragraph 8 adds one more job: tell the users who are affected.

None of this is hard to write down. All of it is hard to know in three days, unless the product was built to tell you.

Four things the device should be able to answer

1. Which units run the affected code

Give every build an identity: a version and the commit it was built from, compiled into the image and readable over the wire. Have every unit report the build it runs and its hardware revision. Keep, for each build, the list of what is in it and how it was configured: bootloader, RTOS, TLS library, radio stack, each with its version and its build options.

The regulation asks for that list as a software bill of materials from December 2027 (Annex I, Part II). It is needed sooner: it is what turns "there is a flaw in this library" into a list of serial numbers.

A test from last week: CVE-2026-71973, published on 29 September, is an integer overflow in the SquashFS reader of the U-Boot bootloader, in versions before 2026.10-rc4. Its record describes an out-of-bounds heap write from a crafted image and no known attacks, so on that record it is not "actively exploited" as the regulation defines it. It is still a good question to practise on. SquashFS support is a build option in U-Boot. How long would it take to say which of your units carry a U-Boot built with it?

2. Where they went

The early warning names countries. A device does not know its country. The shipping record does. When a unit leaves for a customer, record who it went to and which country, against its serial number. If it is sold through distributors, record the distributor and its market.

3. Whether a fix can reach them

The update path has to exist before the problem does: signed images, a version floor so that a fixed unit cannot be put back on the old build, a second slot to fall back to, a rollout that can be staged and stopped. Check what the path covers: on many boards it updates the application and never the bootloader. Know which units have not checked in, and for how long. Send a harmless update through it on a schedule, so its first real use is not its first use.

4. What users can do until then

The notification asks for measures users can take. Decide now what they are: a service that can be switched off remotely, a port closed by configuration, an instruction that fits in two lines. Keep a way to reach users that does not depend on the broken feature.

How you would find out

The clock starts when the manufacturer becomes aware. The Commission's guidance reads that as the point where, after a first assessment, the manufacturer is reasonably certain that a flaw in its product is being exploited. The first sign arrives in three ways. Someone tells you: publish a security contact, usually a security.txt file. Your telemetry shows it: have devices report resets, failed updates and rejected signatures. Or a component you ship gets an advisory that reports attacks: watch the advisories for every entry on the list from point 1.

Not every flaw starts the clock. The regulation's word is "actively exploited": there is reliable evidence that an attacker has used the flaw against a system without its owner's permission (Article 3).

A drill for this week

Pick one component in your current firmware. Assume a flaw in it is being used against your product, and start a timer. Which units. Which countries. Can a fix reach them. What do users do meanwhile. Whatever cannot be answered within the hour is the work list.

Sources

European Commission: CRA reporting obligations (11 September 2026)
Regulation (EU) 2024/2847, Articles 3, 14, 69 and 71, Annex I
European Commission: CRA guidance, Section 9.1
ENISA: The CRA Single Reporting Platform is launched (11 September 2026)
NVD: CVE-2026-71973 (published 29 September 2026)
U-Boot: fs/squashfs/Kconfig
RFC 9116: security.txt

First published at newlinebreak.com/notes/cyber-resilience-act-24-hours.