When was the last time you read a review of the software running a supermarket’s walk-in freezer? Not the point-of-sale system, not the inventory forecasting tool, not the shiny AI shelf-scanner some vendor pitched at a trade show. The freezer. The thing with a temperature setpoint and a defrost schedule and, apparently, a remote management interface reachable by people who do not work there.
I spend most of my time here poking at AI tools and automation stacks, writing up what actually holds together under load and what falls apart the second you push on it. So the story out of France this week landed differently than most security news. Attackers remotely triggered forced defrosting across refrigeration systems in a large number of European stores, hitting French chains hardest. Intermarché, Coopérative U, Carrefour Market, Monoprix, Leclerc, and Super U all show up in the reporting, with estimates between 250 and 350 affected stores. Investigators believe the target was refrigeration management equipment from Danish manufacturer Danfoss, widely used in commercial refrigeration.
The detail that stuck with me is the configuration itself. Automatic defrosting is a normal, boring function that typically runs about two hours a day. The attackers reportedly set it to a continuous cycle at 50 degrees Celsius. Not disabled. Not deleted. Reconfigured into something that looks legitimate to the system and catastrophic to everything inside it. Reports describe a wave of heat coming off the cases, food losses across hundreds of stores, and fires at several locations.
Why a Tool Reviewer Cares About Fridges
Because this is the exact failure mode I keep flagging in the automation tools I test, just with physical consequences attached.
Every remote management platform I review gets evaluated on roughly the same questions. Who can authenticate? What can they change? Does the system know the difference between a valid command and a sane one? Can you see what changed, when, and by whom? Most dashboards score well on the first question and poorly on the rest. They assume that if a request is authenticated, it is intentional, and if it is intentional, it is reasonable.
A continuous defrost cycle at 50 degrees is a perfectly valid command made of perfectly valid parameters. There is probably no field in that interface marked “destroy inventory.” The attack did not need an exploit chain or a clever memory bug to do its damage. It needed access and a settings page.
That is the pattern I run into constantly in the AI and automation space right now. Teams are wiring agents, schedulers, and remote control planes into systems that were designed on the assumption that a human with context would be the one turning the dial. The tooling gets wider reach and faster execution, and the guardrails stay exactly where they were.
The Checklist Nobody Runs
If you are responsible for anything that controls physical equipment, or anything that lets software change physical equipment, the review criteria are not exotic:
- Range limits on every writable parameter. If a value can be set to a number that destroys the asset, the interface should refuse it regardless of who is asking.
- Duration caps on cycles. “Continuous” should not be a selectable option for a function designed to run two hours a day.
- Change alerting that reaches a human fast. Hundreds of simultaneous configuration changes across a chain is a pattern worth paging someone about at 3am.
- Segmentation between store systems and anything internet-facing. Convenience of remote access is real. So is its cost.
- Audit trails you can actually read during an incident, not after a vendor exports them for you in three weeks.
None of that is new thinking. It is the same defensive design that good automation tools ship with and mediocre ones leave as an exercise for the customer.
What This Says About the Tools We’re Buying
My honest read: the industry has gotten very good at building control surfaces and very lazy about building constraints. We review integrations on how many systems they touch, how quickly they deploy, how little configuration they demand. Almost nobody reviews them on what happens when the wrong actor reaches the same controls a legitimate operator would use.
Operational technology has been the standing example of this gap for years, mostly in abstract terms involving power grids and water treatment. A frozen food aisle near Nantes is a more legible version of the same lesson. The attackers did not break the refrigeration system. They used it, as designed, at a scale and setting nobody thought to prohibit.
If you are evaluating any tool that can change the state of something in the real world, add one question to your list before you sign. Not “can it do this.” Ask what it refuses to do, and who decided.
đź•’ Published: