Overnight on November 2, freezers in supermarkets across Sweden, Belgium, Luxembourg and Ireland climbed to around 50°C, and stores awoke to spoiled stock. This is the second wave within a month, after a similar attack on hundreds of French stores in October. No one has publicly claimed either attack, and the attack vector hasn't been confirmed.
Regardless of who is responsible, the targets are what should worry us. These were refrigeration controllers: small, purpose-built devices that most of their asset owners likely didn’t think of as computers at all.
Invisible by design
The first problem is that nobody is looking for, or often even aware these devices are network connected. These devices often become effectively invisible once the integrator puts them in place. They perform their function reliably, and quietly. Unless something breaks, nobody thinks about them as computers that need ongoing security maintenance.
A refrigeration controller is installed by a contractor, commissioned, and then left to run. It rarely appears in an IT asset inventory, it often sits outside the security team's remit, and even worse, it may be reachable remotely so the maintenance provider can service it. That combination: connected, unmonitored, and effectively unowned, is an attacker’s dream target.
A patching problem with no easy fix
That invisibility creates a serious patching problem. Many embedded and industrial devices remain exposed not only to recently disclosed vulnerabilities, but also to flaws that were remediated decades ago, along with product-specific firmware weaknesses that may never be publicly documented.
The gaps come in several forms:
- No fix exists. The manufacturer is unaware of the issue, has ended support for the product, or has no incentive to address it.
- A fix exists but never reaches the field. The operator may not realize the device is vulnerable, may not know an upstream update is available, or may no longer have a clear owner responsible for maintaining it.
- The fix is difficult to apply. There usually is no equivalent of Windows Update or Linux's `yum`/`apt` that can centrally track and deliver these updates. Updates may require a technician, a vendor-specific utility, physical access, or downtime that operators are reluctant to schedule.
The French attack shows how this plays out. Intermarché's owner said its systems were managed by Danfoss (an external engineering/product firm), and Reuters reported some of the November targets used the same technology. In August, Claroty's Team82 disclosed flaws in Danfoss refrigeration controllers, including a hidden credential that could grant admin access, and found thousands of the controllers reachable from the internet. The saddest part here: A firmware fix was available at the time of attack. Whether those flaws were used hasn't been established, but a fix that has been released is not the same as a fleet that has been patched.
Built for a different era, kept for decades
A lot of this equipment was also designed in an era, or for an environment, where security was not only not a primary focus, but often wasn't even considered. As a result, you still encounter weaknesses that the broader software industry has treated as solved problems for years: weak authentication, exposed services, hard-coded credentials, insecure update mechanisms, and other basic issues.
Those weaknesses persist because the hardware does. These devices can remain operational long after the vendor has ended support or stopped producing security updates. From an operational perspective, replacing a device that still does its job can be difficult to justify, even though it may be extremely vulnerable.
And even when manufacturers consider software security, hardware security often remains unaccounted for. Maintenance and debugging interfaces intended for technicians can sometimes provide surprisingly direct access to a device if someone can reach it physically. Features that are useful during manufacturing or servicing can become security liabilities when equipment remains deployed unattended, and a rooftop condenser or back-room controller cabinet is about as unattended as equipment gets.
This isn't a supermarket problem
It would be easy to file these attacks under retail and move on, but that misses the point. The broader issue is not at all specific to supermarkets or refrigeration. These kinds of niche embedded and IoT systems are deployed across retail, manufacturing, building automation, healthcare, critical infrastructure, solar, agriculture, and many other industries.
They are everywhere, but because they are purpose-built and usually quietly doing their jobs, they are often overlooked until an incident makes them visible. This month, that incident was spoiled food. In another sector, the same class of weakness could mean a stalled production line, a building with no climate control, disrupted energy assets causing blackouts, or tainted water at a utility.
What to do now
Organizations running embedded, IoT, and OT equipment, in stores or anywhere else can reduce exposure with a few practical steps:
- Understand what you have. Inventory every connected device, including those installed and managed by third-party integrators, record the firmware version of each, and note the update mechanism/method.
- Assign an owner and write processes. Every device needs a named person or team responsible for its security, not just its uptime, and they need to be aware of how to properly patch the device.
- Take it off the internet. Devices should not be directly reachable from the public internet. Put remote vendor access behind a VPN or secure gateway with MFA and logging.
- Patch, and plan for what you can't patch. Check vendor advisories, schedule firmware updates, and segment or monitor devices that are out of support until they can be replaced.
- Change the defaults. Remove shared and default credentials and ask vendors directly about hidden or maintenance accounts.
- Protect physical access. Secure cabinets and service ports on unattended equipment.
- Alert on the physical outcome. Independent temperature or process alarms can catch tampering that the compromised controller itself would hide. Establish a baseline and expected value ranges, find a way to track them, and alert on them if they deviate.
- Test it. Product (hardware/firmware) and OT- focused penetration testing finds the forgotten device before an attacker does.
The freezers in Sweden, Belgium, and France were doing exactly what they were built to do, until someone else told them otherwise. The lesson is simple: if it runs code, it can be compromised. And if your business depends on it, you can't afford to pretend it's just an appliance.
