When Hackers Defrost Your Supermarket: OT Security Lessons

Imagine you're the night-shift manager at a supermarket in Lyon. At 3 a.m., the overnight crew notices frost melting off the frozen-food cases. Then the compressor alarms start firing — not on one aisle, but across the entire store. By the time anyone figures out what's happening, the walk-in freezers have been remotely commanded into defrost mode, and thousands of euros of frozen stock are quietly warming toward the legal discard threshold. That's roughly what happened when attackers hit refrigeration controllers at French supermarket chains this year, and it's a useful wake-up call for anyone who thinks operational technology security is someone else's problem.

The attack wasn't some Hollywood-grade exploit chain. According to reports, attackers triggered automatic defrost cycles on internet-exposed refrigeration controllers — commercial units from a major industrial vendor — and the damage spread across stores in multiple countries. Around the same period, a separate incident forced a Belgian-Dutch grocery group to take chunks of its IT offline, disrupting distribution and delivery. Coincidence or coordination, the result was the same: the physical world got hacked through the digital one.

Why Is a Freezer on the Internet Anyway?

The most common reaction to this story — and it flooded the comments everywhere — was some version of "why on earth would you connect a fridge to the internet?" It sounds rhetorical, but there's a real answer, and pretending otherwise is how we keep having this conversation every few years.

Commercial refrigeration is not a fridge. A mid-sized supermarket runs a distributed thermal system: dozens of display cases, walk-in coolers and freezers, compressor racks, condensers, all orchestrated by controllers that balance temperature against energy cost. The business case for remote connectivity is genuine:

• Remote diagnostics. A refrigeration contractor serving hundreds of stores can see a failing compressor signature days before a breakdown. Sending a technician to press a physical button for a routine defrost costs real money; a remote command costs nothing.
• Energy optimization. Supermarkets are among the most energy-hungry buildings per square meter. Chains tune case temperatures and defrost schedules across their entire estate, and some participate in demand-response programs where the utility pays them to shed load during grid stress.
• Compliance logging. Food safety regulations require continuous temperature records. Networked controllers produce an automatic audit trail — no clipboard, no falsified paper logs.
• Fleet comparison. When you operate 2,000 stores, spotting that one store's compressors draw 15% more power than its peers is how you find refrigerant leaks before they become five-figure repair bills.

So the connectivity isn't stupid. What's stupid is the implementation. Early reporting suggests many of these controllers were reachable directly over the internet — some with their own cellular modems and SIM cards, sitting on public IP space with no VPN, no gateway, no allow-list. And the authentication story, per one widely-shared account, was a username of admin paired with a password derived from the current date. That's not an attack surface; that's an open door with a welcome mat.

This Is What an OT Attack Actually Looks Like

Software engineers tend to picture cyberattacks as data theft: exfiltrated databases, leaked credentials, ransomware notes. OT attacks are different in kind, not just degree. The target isn't information — it's a physical process. The payload isn't encryption; it's a legitimate-looking command sent to a device that trusts whoever shows up.

Notice how elegant the defrost attack is. The attackers didn't need to write malware, escalate privileges, or even fully understand the protocol. A defrost cycle is a normal, authorized function of the controller — it exists because frost builds up on evaporator coils and has to be melted periodically. The attacker just invoked it out of schedule, at scale. No safety interlock fired, because from the controller's perspective nothing abnormal was requested. This is the OT equivalent of a confused deputy problem: the device faithfully executes commands it should never have received.

That pattern generalizes depressingly well. Water treatment plants have been "attacked" by someone moving a chemical dosing slider. Building management systems have been taken over through their HVAC vendor's remote access. In nearly every case, the dangerous capability isn't a bug — it's a feature, reachable by people who were never supposed to reach it. Which is why the fix isn't better code review. It's architecture.

The most dangerous OT vulnerabilities aren't memory corruption bugs. They're legitimate functions exposed to illegitimate callers.

The Patch That Nobody Applied

Here's the detail that should make every security engineer wince: the underlying vulnerability in these controllers had been publicly disclosed months earlier, in a coordinated process with the vendor. Security researchers published a detailed write-up. Patches existed for at least some models. And the attack happened anyway.

This is the dirty secret of industrial patching. In enterprise IT, we're spoiled: a critical CVE drops, and within days your fleet management tooling has nagged, staged, and deployed the fix. OT doesn't work like that. The controller in a supermarket freezer case might run for fifteen years. It's owned by the store, maintained by a third-party refrigeration contractor, manufactured by a vendor, and configured by an installer who left the company six years ago. Who, exactly, is responsible for applying a firmware update at 2,400 sites across nine countries? In practice: nobody.

Worse, the vendor apparently shipped the fix without clearly flagging it as security-critical. To a maintenance contractor with a backlog of actual broken equipment, "firmware update available" reads as optional busywork. This is a communications failure as much as a technical one. If you ship a patch for a vulnerability that lets strangers defrost a country's groceries, the release notes should say so in words a facilities manager can't miss. The gap between specification and implementation doesn't just create bugs — it creates entire fleets of unpatched devices that their operators don't know are vulnerable.

Fail-Safe Defaults: Designing for the Worst Day

Let's talk about what good looks like, because the principles here aren't exotic. They're the same defensive design ideas we apply in safety-critical software, just rarely enforced in the OT world. I've written before about defensive engineering that resists catastrophe, and refrigeration controllers are a textbook case for it.

Rate-limit dangerous state changes

A defrost cycle is physically safe to run occasionally and destructive to run constantly. So enforce physics in firmware: after a defrost completes, refuse another one for a minimum interval regardless of what any remote command says. The attacker who can send one defrost request can send a thousand; the device shouldn't honor more than physics allows. This costs a few lines of code and one timer, and it caps the blast radius of any control-plane compromise.

Local interlocks beat remote authority

If the case temperature is already above a threshold, or the product sensors read warm, a remote defrost command should be rejected and logged loudly. The controller has the sensor data to know a command is insane. Make it use that data. A command that would push a system toward a known-bad state isn't a command; it's an error.

Signed commands, not passwords

Passwords on embedded devices are a lost cause — they'll be defaults, shared, written on a sticky note, or derived from the date. The stronger model is asymmetric: controllers verify a signature on every remote command against a vendor or operator public key burned in at provisioning time. Now stealing a password doesn't help; you need the signing key, which lives in an HSM at the operations center, not on 2,400 freezer cases. Yes, this means key management, rotation, and revocation infrastructure. Yes, it's worth it. We solved this problem for software updates a decade ago; command channels deserve the same treatment.

Assume the network is hostile

If a device ships with a cellular modem and a default credential, it will end up on a search engine for exposed devices within weeks of deployment. The only durable fix is to design as if that's guaranteed: inbound connections refused by default, outbound-only telemetry to a broker, management plane reachable only through a mutually-authenticated tunnel. "Don't expose it to the internet" is advice; "make exposure survivable" is engineering.

Isolation Is Not Optional: Segmentation Done Right

Every OT security framework — IEC 62443, NIST's guidance, the classic Purdue model — says the same thing: keep control systems off flat networks. And yet the cellular modem in the freezer case is the anti-pattern incarnate. It bypasses the corporate firewall entirely, creating thousands of unmonitored, individually-addressable entry points that the security team may not even know exist.

The architecture that actually works looks like this:

1. Controllers live on a dedicated OT VLAN with no route to the internet and no route to corporate IT. Only a single gateway can talk to them.
2. The gateway enforces protocol allow-lists — the controller speaks Modbus or the vendor protocol to the gateway and nothing else. Anomalies here are high-signal alerts, because legitimate traffic is boring and predictable.
3. Remote access goes through a jump host with MFA, session recording, and time-boxed credentials. The refrigeration contractor gets a four-hour window to a specific store, not a standing VPN to the estate.
4. Outbound-only telemetry. If the vendor's cloud needs temperature data, the gateway pushes it. Nothing pulls from inside.
5. Inventory everything. You can't segment what you don't know about. That cellular modem in the freezer case is exactly the kind of shadow connectivity that inventories miss — until Shodan finds it for you.

None of this is hypothetical or expensive relative to the alternative. The hard part is organizational, not technical: it requires the facilities team, the IT security team, and the vendors to agree on who owns what. In most retail organizations, OT falls into the crack between those teams — too physical for IT, too networked for facilities. That ambiguity is the real vulnerability, and it's the same one that turns cloud authentication gaps into invisible breaches, as we've seen in the blind spots in cloud authentication logging: if nobody owns the telemetry, nobody sees the attack.

What Software Engineers Should Take From This

You might never touch a refrigeration controller, but the failure modes here are the failure modes of every connected system, and they're increasingly your problem. The line between IT and OT keeps dissolving: your warehouse robots, your office HVAC, your lab instruments, your smart building all run embedded Linux and talk to clouds. Some hospital lab machines now refuse to run tests unless their subscription account is topped up — meaning an internet-connected billing outage or breach can halt medical diagnostics. We built that world, one convenience feature at a time.

So the lessons transfer directly. Inventory your exposure — if you don't know what's listening, someone else will find it. Treat dangerous operations as privileged even when they're "normal features," because the attacker who reaches your control plane will use your features against you. Sign what matters and expire everything else. Design the failure state to be the safe state: a controller that loses connectivity should keep cooling, not assume every queued command is trustworthy. And when you ship a security fix, say so loudly — a patch nobody applies is indistinguishable from no patch at all.

The supermarket defrost attack will be remembered mostly for its absurdity — hackers versus frozen peas. But the next one won't target ice cream. It'll target the same class of exposed, unpatched, weakly-authenticated controllers in a cold-storage pharmaceutical warehouse, a data center's cooling plant, or a municipal water system. The hardware is the same. The credentials are just as bad. The only variable is what warms up, floods, or shuts down when someone types the password of the day.