What the French Supermarket Attack Teaches Cold Chain Operators About Control Systems

On the night of October 11, attackers took remote control of refrigeration controllers in hundreds of French supermarkets, including stores operated by Intermarché, Netto, Coopérative U, Carrefour, Monoprix, and E.Leclerc. At Intermarché, fridges and freezers were forced into defrost and heated to as much as 50°C (122°F) for six hours. The chain’s CEO told BFM TV that losses would reach tens of millions of euros nationwide in a single day.

French authorities traced the attack to internet-exposed Danfoss AK-SM and AK-SC controllers running outdated firmware. Danfoss said most affected units were older products that no longer receive security updates.

The attackers did not break the equipment. They used it. Defrost is heat that a controller adds to a freezer on purpose, on a schedule, many times a week, and every controller treats it as a legitimate event. Once the attackers held the controller, the system did exactly what it was told.

Patching firmware and securing remote access to controllers are necessary, and every operator should do both this week. But those steps protect the controller. They do nothing for you on the day the controller is wrong, whether the cause is an attacker, a bad configuration, or a failed component.

What a controller can and cannot protect you from

Ndustrial has been integrating with legacy refrigeration controls for more than a decade, starting in industrial cold storage and blast freezing. From the beginning, we chose to work with existing controllers rather than replace them. That meant inheriting their built-in protections: dead bands, rate limits, set point bounds, and interlocks refined over decades of real failures.

We built around that. An edge layer inside the facility, behind the firewall, is the only thing that talks to the controls, and every command it passes down still has to clear the controller’s own limits. If the cloud connection drops, the facility runs on its legacy logic as it always has. Our cloud optimization is treated as untrusted. Intelligence sits at the top, and enforcement stays at the bottom.

That design means a bad recommendation from above runs into the controller’s limits. Our models could never push a freezer to 122°F.

But the French attack exposes the other half of the problem. Those limits protect you from a bad command. They do not protect you from someone already inside the controller who can rewrite the limits. At that point, alarms, set points, and defrost schedules are all just configuration. The controller will carry out its new instructions and report that everything is operating as intended.

A control system can only tell you what it believes it is doing. It cannot tell you whether it is right.

The independent layer

The answer is a monitoring layer that the controller does not own. Independent temperature monitoring runs on its own sensors, separate from the refrigeration controller. An attacker who takes over the controller does not take over the sensors watching the cases. Because those sensors report on their own, a temperature rise like the one in France is detected quickly, and store teams and corporate can be alerted in real time.

Independence is what makes the layer trustworthy. Context is what makes it useful. When the monitoring layer can see what the controller claims to be doing, it can flag the contradiction: “the controller reports a routine defrost; the case has been warming for ninety minutes.” That is a statement a person can act on.

And it has to end with a person. Someone who trusts the data needs to be able to take manual control of the equipment, up to and including cutting power at the panel. No amount of automation replaces an operator who knows something is wrong and has the authority to act.

None of this needs to be justified as a cybersecurity project. Independent temperature monitoring pays for itself in reduced shrink, food safety, and audit readiness, and operators who deploy it for those reasons get the security benefit with it.

What to do this week

• Check controller firmware versions and identify units that no longer receive updates.
• Review who can change defrost schedules, set points, and alarm thresholds.
• Ask whether anything outside the controller would notice if those settings changed.

Then ask the harder question: if your controller reported normal tonight while your cases warmed, who or what in your building would notice? If the answer is the morning crew opening the door, that is the project to start.