The fridge was never on the list

A vulnerability scan tells you what's exposed. It can't tell you what the business can't afford to lose.

Sometime Sunday night on October 11th, attackers reached the refrigeration controllers in hundreds of French supermarkets and forced them into a defrost cycle. Reports say the target temperature was set to 50 degrees. By Monday, Intermarché, Coopérative U and Leclerc had closed display cases and thrown out stock, and the Paris prosecutor had opened an investigation.

The details are still being pieced together, so we'll stick to what has been reported. Many of the affected controllers made by Danfoss were running older software versions. Security researchers had already published weaknesses in that product line. Some retailers also reported that external service providers responsible for refrigeration management were affected. How those pieces fit together in the actual attack is still unclear. We know even less about how the grocery chains were managing this internally, whether the controllers were in an inventory, whether anyone had rated them critical, whether the suppliers' access had ever been reviewed. 

This incident is a useful way into a problem that exists regardless of what happened in France: knowing something is vulnerable and knowing what it means to the business are two different pieces of information, and they usually live in different places.

The second scenario isn't a tooling problem. We have more information about what is vulnerable than we can act on. Security tools can identify a weakness, but they don’t necessarily show how it could disrupt the business. A refrigeration controller illustrates that gap. On a scan report it's an embedded device with old firmware, which in most environments is unremarkable. In a supermarket it's what is standing between the store and a dumpster full of spoiled food. The severity score is the same in both places. The risk obviously isn't.

Most organizations already have a document that says which of those two situations they're in. It's the business impact analysis, and it's a business exercise rather than a security one. The business impact analysis identifies a) the processes the organization can't operate without, b) how long each can be down before the damage becomes serious, and c) what each one depends on, including the technology, the suppliers, and the people and access involved. For a grocery chain, cold storage would be on page one and the refrigeration supplier would be listed as a dependency. What the analysis generally won't tell you is: 

a) how that supplier connects to the equipment 

b) what its access can do, or 

c) which controllers it can reach 

That detail only comes from mapping the business dependencies to the actual systems and access arrangements, and that mapping is the work is often missing.

The starting point exists but what happens to it afterward? Two problems come up regularly. 

1. The analysis gets treated as a checkbox, produced because a continuity plan needs one and never revisited. 

or 

2. It's done properly and then left with the team that wrote it. 

Nobody connects it to the actual IT and OT environment, and the security team either doesn't know it exists or has never read it. The continuity people have a list of critical processes, the security people have a list of vulnerable hosts, and the mapping between the two is something everyone assumes someone else is doing.

Mapping is often regarded as the most useful thing a security team can do with a business impact analysis, and it's not complicated. Take the dependency list and walk it against the asset inventory. For each critical process, work out which systems support it, who manages them, and which outside parties can reach them. If the business impact analysis identifies a critical dependency missing from the asset inventory, that gap deserves attention. A vulnerability scanner may detect a device, but it cannot establish on its own how much the business depends on it.

This mapping can also reveal security risks that vulnerability scans don’t capture. Vendor remote access isn't a security risk on its own; a refrigeration supplier that can't reach its own equipment isn't much use to anyone. The question is how that access is governed, how far it reaches, and what happens when it's compromised. One account, or one supplier, that can change setpoints in several hundred stores at once is a concentration of authority that deserves its own entry on the risk register, whether or not anything about it is technically vulnerable. The same goes for a shared credential across a fleet of controllers, or a refrigeration system with no manual fallback when the controller stops taking instructions. Those risks can still exist even when all software is up to date. They can be missed by both vulnerability scans and a business impact analysis. Connecting critical business processes to the systems and access they depend on can help uncover them.

This is not a clean fix. Someone has to own the connection, the analysis has to be refreshed more often than once per audit cycle, and plenty of these controllers sit on networks the security team doesn't control. None of that is technically hard, but it crosses a departmental line, and in most organizations that is harder than any patch.

If the reports about the French attack hold up, the supermarkets will spend the next few months on firmware updates and supplier access reviews, and they should. But one question deserves attention: before Sunday night, had anyone identified the refrigeration supplier as a critical dependency? If so, who was responsible for managing the risk?

‍Sources

1. Reuters, October 13, 2026. Hackers heat French supermarket fridges, sparking fires and spoiling food. Reporting on the affected retailers, 50°C temperatures, food losses, prosecutor's investigation, and refrigeration equipment.
2. BleepingComputer, October 12, 2026. Cyberattack shuts down refrigerators at French supermarkets. Details on Danfoss controllers, older software, affected supermarket chains, service-provider statements, and previously disclosed vulnerabilities.
3. Le Monde, October 13, 2026. Cyberattaque contre les supermarchés : après ceux de l’entreprise Danfoss, d’autres systèmes de réfrigération ont été visés. Follow-up reporting on additional attacks involving Dixell equipment and the ongoing investigation.
4. IT-Connect, October 2026. Super U, Intermarché : des pirates font chauffer les congélateurs à 50 °C. French technical reporting on the refrigeration attacks and affected equipment.
5. Claroty Team82, August 2026. Danfoss AK-SM 800A vulnerability research. Research into vulnerabilities affecting Danfoss refrigeration management controllers. The existence of these vulnerabilities does not establish that they were exploited in this incident.

‍