Internet-connected refrigeration, eight-hour defrost cycles, and a few uncomfortable questions about defensive programming.
Hot Baguette*, straight from the freezer. No oven required.*In October 2026, hackers targeted refrigeration systems in hundreds of French supermarkets.
Freezers stopped freezing. Cold rooms reportedly reached 50°C, with one store reporting temperatures as high as 80°C. Food was destroyed, equipment was damaged, and fires were reported.
All because someone remotely changed the settings of refrigeration controllers.
As a software developer, I have a few questions.
1. Why Does a Freezer Need Internet Access?
Fair question.
Commercial refrigeration systems need monitoring, maintenance, temperature reporting and alarms. A supermarket may operate hundreds of refrigeration units, so centralized management makes perfect sense.
Remote access can also be useful.
But does that mean the controller needs to be accessible from the public Internet?
Absolutely not.
You can provide remote maintenance through a secured VPN, restrict access to trusted networks and isolate the equipment from other systems.
In fact, that is precisely what France’s national cybersecurity response team, CERT-FR, recommended after the attacks.
It also recommended changing default passwords and updating firmware.
Which brings us to a simple analogy.
Would you leave your bicycle unlocked outside a bakery?
Probably not.
So why would you leave an industrial refrigeration controller exposed to the Internet?
2. Where Was the Firewall?
Security researchers had already identified vulnerabilities in Danfoss refrigeration controllers before the October attacks.
Some could allow authentication bypass or remote code execution. The manufacturer released firmware updates, but many affected installations reportedly used outdated or unsupported equipment.
Researchers also found thousands of refrigeration controllers accessible from the public Internet.
A firewall is not a magical solution. Neither is a password.
But network isolation, authentication, software maintenance and restricted remote access are basic security practices.
The question is not why hackers discovered these systems.
The question is why so many systems were reachable in the first place.
3. Since When Can a Freezer Cook?
Here is where things get interesting.
Commercial freezers often contain heating equipment.
It is used for automatic defrosting. Ice accumulates on evaporators and must periodically be removed, sometimes using electric heaters or hot refrigerant.
Perfectly reasonable.
But during the French attacks, defrost cycles were reportedly extended from one hour to eight hours.
The results were anything but reasonable.
A cold room reportedly reached 50°C. Another store reported temperatures approaching 80°C.
That raises an obvious question:
Why can an appliance designed to preserve frozen food reach temperatures associated with cooking?
To be technically precise, a hot defrost heater, a warm evaporator and the temperature of the refrigerated compartment are three different things.
Nevertheless, an abnormal defrost cycle should not be allowed to create dangerous operating conditions.
The next feature might as well be:
French fries. Straight from the freezer. No oven required.
4. Has Anyone Heard of Defensive Programming?
Developers know that inputs cannot always be trusted.
Configurations can be wrong. Sensors can fail. Firmware can contain vulnerabilities. Administrators make mistakes.
And attackers sometimes gain access.
That is why we establish operating boundaries.
Temperature limits. Time limits. Sanity checks. Automatic shutdowns.
And for potentially dangerous equipment, independent protection.
A simple design principle:
The system controlling a machine should not be the only system capable of protecting it.
Imagine a refrigeration controller that accepts an eight-hour defrost configuration.
A separate safety mechanism should still prevent the heating equipment from producing dangerous conditions.
The normal controller could be compromised, misconfigured or malfunctioning.
The independent protection should continue doing its job.
This is not revolutionary cybersecurity.
It is defensive engineering.
5. Secure by Design. Safe by Design.
There are two different problems here.
Cybersecurity: Prevent unauthorized access to the controller.
Functional safety: Prevent dangerous physical consequences, even when the controller behaves incorrectly.
We should not confuse them.
The public reports do not establish exactly which independent safety mechanisms were installed in the affected refrigeration systems or why some installations experienced such severe damage.
It would therefore be premature to conclude that a particular manufacturer omitted essential safety protection.
But the incident raises legitimate questions about the design, installation and maintenance of connected industrial equipment.
And it demonstrates something important.
Keeping attackers out is one problem.
Making sure the machine remains safe when they get in is another.
Conclusion
Connected refrigeration is useful. Remote maintenance is useful. Automatic defrosting is useful.
None of these features is inherently dangerous.
But combining Internet exposure, vulnerable software and powerful physical controls creates risks that software developers and engineers should anticipate.
Security protects the controller. Safety protects us from the controller.
And when both fail, your freezer might become the world’s most expensive French-fry machine.
Sources
- CERT-FR — Security alert CERTFR-2026-ALE-012
- Claroty Team82 — Freeze the Controller, Defrost the Food (August 2026)
- Le Monde — A disastrous day for French supermarkets (October 13, 2026)
- Cooling Post — Danfoss moves to mitigate cyberattack (October 12, 2026)
- Censys — European Refrigeration Controller Exposure (November 5, 2026)
- Danfoss — ERC 112 Controller User Guide, defrost parameters (2024)
Top comments (0)