Since late August, freezers have been heating up instead of staying cold. It's happened at US military commissaries, where the Pentagon is investigating a suspected hack, in hundreds of French supermarkets, in stores in at least seven more European countries, and at three blood plasma sites in France. Where the cause is known, these freezer cyberattacks didn't target the freezers directly. They went after the refrigeration controller, the small computer that tells the freezers what to do, and they used a perfectly normal feature to do the damage.
You don't need to run a supermarket for this to matter. Most organizations have devices like these: bought by facilities or operations, serviced by an outside contractor, reachable from the internet, and missing from IT's inventory. This post walks you through what happened, how the attacks work, why the alarms stayed quiet, and what US agencies asked owners and operators to do on November 5.
If you'd rather watch than read, this two-minute video covers the same ground.
Tracing the attacks from August to November
The first failures showed up in late August, when freezers broke down at military commissaries, the grocery stores on US bases. Stars and Stripes reported that at least six bases or stores had outages. The Pentagon is investigating them as a possible cyberattack and, as of early November, hadn't confirmed a cause.
On the night of October 11, freezers and cold rooms in hundreds of French supermarkets were switched into defrost mode and left there. Some cases reached 50 degrees Celsius (122 degrees Fahrenheit), and stores had to throw out their stock. In the week of November 2, a new wave reached stores in at least seven more European countries, including Belgium, Luxembourg and Sweden.
Overnight from November 1 to 2, a similar attack reached cold rooms holding plasma at three sites run by the French Blood Establishment (EFS), through one of its refrigeration suppliers. The alarms did their job, and no blood products were lost.
On November 5, CISA, the FBI, the Department of Health and Human Services, the Department of Agriculture and the Department of Transportation published a joint fact sheet telling owners and operators how to lock these systems down. You'll find its recommendations further down.
Understanding what the attackers actually hacked
Supermarkets, cold stores and blood banks don't run each freezer by hand. A refrigeration controller sets the temperature for each case or cold room, runs its defrost cycles and raises an alarm when something drifts out of range, and in many stores one controller oversees all of them. Plenty of these controllers sit on the internet so refrigeration contractors can monitor and service them remotely. That's convenient for the contractor, and just as convenient for anyone else who finds the login page.
The ways in are familiar: controllers exposed directly to the internet, outdated firmware, default passwords nobody changed, and older models that no longer get security fixes. The fact sheet lists three routes in: getting around authentication, injecting code, and exploiting weak configurations. Attackers have used the same routes against routers and cameras for years. What's different here is what they did once they were inside.
They used defrost. Ice builds up on a freezer's cooling coil, so the controller warms the coil for a short, scheduled window to melt it, then switches back to cooling. The attackers forced units into defrost and kept them there. Left running, a cycle meant to clear a thin layer of ice heats the whole case. Nothing had to break. The equipment did exactly what it was told.
Figuring out why the alarms stayed quiet
A freezer that warms up should set off an alarm. It often didn't, because some warming is expected during defrost, so temperature alarms are usually held until the cycle ends. Put another way, a controller in defrost is a controller that's been told to put up with rising temperatures. In some French stores, defrost was reportedly stretched from about one hour to eight, which pushed the alarms past the end of the night.
The plasma sites show you the other outcome. There, temperature alarms caught the rise while it was happening, and staff stepped in before any plasma was lost. That wasn't luck. It was an alert tied to the temperature itself, and people ready to act on it.
Your backup infrastructure works the same way. An alert only helps if it fires on the change that matters and reaches someone who can do something about it. Backup security alerts that matter covers which ones to set up.
Reading the November 5 guidance
The joint fact sheet, "US Government Partners Urge Hardening Industrial Refrigeration and Cold Chain Monitoring Systems," is aimed at owners and operators in healthcare, food and agriculture, chemicals and transportation. "Every organization that depends on refrigeration and monitoring systems should assume it could be a target," said Chris Butera, CISA's acting executive assistant director for cybersecurity. Line the recommendations up against the weak spots above, and they match almost one for one.
| Recommendation | What to do | Weak spot it closes |
|---|---|---|
| Eliminate public internet exposure | Take controller panels off the public internet. Where you need remote access, put it behind a firewall or edge device kept on its latest version. | Controllers anyone can reach |
| Isolate OT devices | Put controllers on their own network segment, separate from business systems. | An easy path from the office network to the controllers |
| Enforce credential security | Change default passwords, require strong ones, and add phishing-resistant multifactor authentication wherever you can. | Default and reused passwords |
| Apply patches | Keep firmware current, and retire models the manufacturer no longer supports. | Old models with known, unfixed flaws |
| Restrict access | Allow changes only from approved devices and IP addresses. | Settings anyone can change from anywhere |
| Have reliable backups | Keep current backups offsite and offline, and test them. | No clean copy to restore after tampering |
| Monitor and report | Turn on logging and review the logs for anything unexpected. Where a device logs poorly, capture its network traffic instead. | Changes nobody notices or can reconstruct |
| Review setpoint ranges | Set reasonable setpoint limits so devices stay within safe ranges, and alert on any deviation. | Units driven to extreme temperatures |
If most of that table sounds like what you already do for servers, that's the point, and it leads straight to the first lesson.
Taking the lessons back to your own network
First, if it has a login, it's IT, no matter which department bought it. A refrigeration controller is a networked computer with an administrative interface, and it deserves what a server gets: an owner, a place in the inventory, a patch schedule, unique passwords and no direct path from the internet. The same goes for building management systems, cameras, door controllers, UPS management cards and the storage that holds your backups.
Second, keep known-good settings and logs where attackers can't change them. After an incident like this one, you have two questions to answer: what were the settings before the attacker arrived, and what exactly changed? If the only copy of the configuration lives on the compromised controller, and the only logs live on systems the attacker also reached, you can't answer either one with confidence. A configuration export and a log archive kept on storage that refuses changes answer both, and recovery becomes a matter of restoring a known state instead of rebuilding settings from memory.
The fact sheet points the same way: keep backups current, offsite, offline and tested. That's the thinking behind the 3-2-1-1-0 backup rule, which adds one copy that's offline, air-gapped or immutable, and a requirement of zero errors when you verify restores. Working out which saved configuration predates an intrusion is the same problem as choosing a clean recovery point after ransomware, and it's a lot easier when every saved version is still intact.
Where ARTESCA fits
ARTESCA is object storage software you use as a backup target, running on servers you control. It supports S3 Object Lock in governance and compliance modes, so restore points written by Veeam and other backup software can be locked the moment they're written, for a retention period you set. In compliance mode, the lock holds against every account, including ARTESCA administrators, so a stolen password can't be used to alter or remove a locked copy.
Object Lock is the first of five layers in CORE5, the cyber resilience architecture built into every Scality deployment, alongside identity and encryption controls, erasure coding, multi-site replication and an immutable write path. Any application that writes over the S3 API can use the same lock, including for the small files this incident shows are worth protecting: configuration exports and log archives that need to stay exactly as written for a set period.
ARTESCA scales from roughly 50 TB to 8.5 PB. What Object Lock actually guarantees explains where that protection starts and stops, and the free 48-hour ARTESCA Test Drive lets you try it hands-on before you install anything.
Running a quick inventory this week
Here's an exercise that shows you how exposed your own site is to attacks like these. List every device on your network that has a login, including the ones owned by facilities, operations or an outside contractor rather than IT. For each one, write down whether it can be reached from the public internet, whether its default password has been changed, whether its firmware is still supported, and who can change its settings remotely.
Now pick the device whose failure would hurt most, and assume someone tampers with it tonight. Where are its configuration and logs kept? Could you restore last week's settings within the hour, and could you show exactly what changed? Any device without a good answer belongs on the same remediation list as an unpatched server.