10
 min read
November 3, 2026
|
Updated: 

The Fridge Was Never the Target

Enterprise security

Protect vulnerable devices by protecting access to them

Hundreds of fridges, one open door

On the night of October 11, 2026, refrigeration controllers in hundreds of French supermarkets switched into forced defrost. Reports put the count somewhere between 500 and 700 stores. At around 150 Intermarché locations, cabinets ran at close to 50°C (122°F) for six hours before anyone intervened. Food spoiled by the ton, several stores reported fires, and retailers put the loss in the millions of euros.

Three weeks later it happened again. On November 2, supermarkets in Sweden, Belgium, Luxembourg, Ireland and Estonia reported fridges and freezers failing the same way. Delhaize, Carrefour, Colruyt and Coop all confirmed some impact. The Paris prosecutor's office has taken the case under national jurisdiction. Nobody has claimed the attacks, and no attribution has been confirmed.

The pattern may not stop at Europe's borders. Last week, Pentagon officials told Reuters they are treating freezer failures at six or more US military commissaries in late August as a suspected cyberattack. At Fort Huachuca in Arizona, the base commissary's freezers switched to defrost overnight, and the Army's Criminal Investigation Division is now working the case alongside French police. Nobody has confirmed that the commissaries ran the same controllers, though records for at least one, at Naval Air Facility El Centro in California, list a Danfoss control system.

The part of this story that matters for every other operator of connected equipment is how the attackers got in. They did not need to. The controllers were already on the internet, waiting for a visitor.

How they got in

The equipment at the center of both waves is a family of Danfoss refrigeration controllers, the AK-SM 800 and AK-SC 355 among them. Each unit runs a small web server so a technician can check temperatures and change settings from a browser. Danfoss describes them as legacy systems that no longer receive software or security updates.

Thousands of them were sitting on the public internet. Before the French attack, researchers counted more than 1,700 exposed instances in France alone. Claroty's Team82 had warned in 2025 that these controllers were at risk of remote compromise, and said public scanning tools still showed 2,765 of them online. None of this was new. In 2019, TechCrunch reported that thousands of internet-connected industrial refrigerators could be defrosted remotely because they shipped with default passwords.

So the attack, as reported, needed no exploit chain. Find a controller with its management page on the internet. Reach the forced-defrost function. Repeat across a country. The Register notes that the exact role of the known vulnerabilities is still unconfirmed, which only sharpens the point. Whether the attackers used a flaw or a password, the precondition was the same: a device that answered to anyone who asked.

France's cybersecurity agency ANSSI responded with the advice you would expect. Disconnect the affected models from the internet or restrict access to them, then update what can be updated. Danfoss said the same, and added that obsolete equipment should be replaced.

Why the door was open

A refrigeration controller ends up on the public internet because someone needs to reach it. A maintenance contractor servicing 400 stores cannot drive to each one to adjust a setpoint. A regional facilities manager wants to see alarms from home at two in the morning. The controller has a web page, the store has a router, and a port forward takes five minutes.

These devices were available on the public Internet so staff could access them. Unfortunately, so could attackers.

The alternatives were worse in practice. A VPN for every store and every contractor is expensive to run, and it hands a third party a network path far wider than one web page. Firewall allowlists break the moment a technician's IP address changes. So the port stays open, the firmware ages out of support, and the device becomes a search result.

This is the pattern behind most incidents involving building and operational systems. The device is fragile, and the device is rarely the thing you can fix. Nobody can patch firmware the vendor stopped shipping. What an operator can change is who reaches the device, from where, on what kind of machine, and what they can do once they arrive. That is an access problem, and access problems have good answers.

What Island Private Access changes

Island Private Access is zero trust access built into the Island Enterprise Browser and the Island Desktop service. Applied to a refrigeration controller, it removes the one condition the attack depended on. The controller leaves the public internet, and the people who need it keep their access.

Access path before and with Island Private Access

On the left, the controller's own web page answers anyone who finds it. On the right, nothing in the store listens for inbound connections, and the technician's session is checked and logged before it reaches the same controller.

No inbound path. A lightweight Island connector runs as a virtual machine inside the store or regional network, next to the controllers. It opens an outbound-only connection to Island Cloud. In Island's own words, no inbound listeners and no open firewall rules. The port forward goes away. A scanner sweeping for Danfoss web servers finds nothing at the store, because nothing there is listening.

Identity before connection. When a technician types the controller's address, the Island browser recognizes the destination, intercepts the request, and routes it through the nearest Island point of presence to the connector. Before any packet reaches the controller, Island checks who the user is through the identity provider, what device they are on and whether it meets posture requirements, where they are connecting from, and which application they are trying to reach. An unknown person on the internet never sees the login page. A known technician on a compliant device does.

The right scope for contractors. Refrigeration maintenance is usually outsourced. The contractor's technicians install the Island browser on their own laptops, sign in with their credentials, and see only the controllers they are assigned. There is no VPN client, no network-wide access, and no agent required on an unmanaged device for browser-based access. Island's framing is simple: contractors install the Island browser and authenticate with their credentials, and every data governance and session control applies regardless of who owns the device.

Controls inside the session. Traditional ZTNA stops once the connection is made. Island keeps working after it. Policy can restrict downloads, clipboard, printing and screenshots on the controller's pages, watermark the session, and log it in detail, including screenshots and click locations, with keystroke recording where policy requires. If someone does trigger a defrost across 150 stores, you know who, from which device, at what time, and what they clicked. As Island puts it, traditional ZTNA tells you who connected to an application. Island Private Access tells you what they did inside it.

A second factor on the dangerous button. A refrigeration controller from the mid-2000s will never support MFA on its own, and the vendor is not going to add it now. Island adds it from the outside. Because the Island browser renders the controller's web page, it can recognize a specific action inside that page, such as the submit on a setpoint or defrost form, and hold it until the user clears a fresh MFA challenge. Island describes this as inserting a layer of MFA during login or inside a critical workflow without touching a line of source code, with the challenge attached to any action or workflow. In practice, a technician reads temperatures and alarms freely. The moment they try to change a setpoint or start a defrost, Island asks them to prove who they are again. A stolen password or a hijacked session cannot clear that step on its own. Because the check lives at the presentation layer, it works the same on an unsupported controller as on a modern SaaS application, and Island says it can be added within hours rather than months.

Credentials nobody can abuse. Every one of these controllers shipped with a default password, and the 2019 reporting suggests many still ran on it. The first fix is unglamorous: reset every default password to something long and unique. The second is to make sure the new password never circulates. Island's Privileged User Account Management stores the controller credential in the Island Enterprise Password Manager and injects it at the network layer when an authorized technician reaches the login page. In Island's words, the true password never appears in the DOM or UI and cannot be reused outside the Island runtime. The technician signs in as themselves and never learns the shared admin password, so it cannot end up on a whiteboard, in a ticket, or on a former contractor's laptop. Access to the credential can sit behind an approval workflow, expire automatically, and demand a fresh MFA challenge before a sensitive action such as a defrost. Island logs every credential access and use event, so a shared admin account always resolves back to one named person.

Legacy equipment without a rebuild. None of this touches the controller. The Danfoss web interface stays exactly as it is, unpatched firmware and all. Island sits in front of it. The same connector carries the RDP and SSH sessions used to manage site servers and building systems, and Island Desktop extends coverage to other protocols where a team needs them.

Two limits are worth stating plainly. Island Private Access does not fix the firmware, so an end-of-life controller still belongs on a replacement schedule. And it governs the path to the device, so an attacker who is already inside the store network, or who holds a technician's credentials and a compliant device, is a different problem. Multi-factor authentication through the identity provider, device posture checks and session logging shrink that problem considerably. They do not make it zero.

The same night, with Island in place

Picture October 11 again, with the retailer's controllers behind Island Private Access.

At 11:40 p.m., a technician at the refrigeration contractor gets an alarm from a store near Lyon. They open the Island browser on their own laptop and go to the controller's internal address. Island recognizes the destination and asks them to sign in through the retailer's identity provider, with multi-factor authentication. It checks that the laptop meets the retailer's posture policy, confirms the technician is assigned to that region, and routes the session through the nearest point of presence to the connector in the store. The controller's web page loads. They adjust the setpoint, clear the second MFA prompt that Island places in front of the change, confirm the alarm has cleared, and close the tab. The whole session is logged against their name.

At the same hour, a scanner sweeping French address space for Danfoss web servers reaches the retailer's 400 stores and finds nothing. No inbound port is open. No login page is there to probe. The controllers are exactly as old and unpatched as they were the day before, and nobody outside the policy can reach them.

The forced defrost across 150 stores does not happen, because the only route to that function now runs through an identity, a device check and a recorded session.

With Island Private Access, only authenticated, secure staff can access the devices. Everyone else is unable to see or access the devices.

What to do this week

The French and Belgian investigations will take months. Operators of connected equipment do not have to wait for them.

  1. Find every controller, building management system, HVAC unit and camera with a public address. Use the same scanning tools the attackers use, and assume the list is longer than you expect.
  2. Close the inbound path. Remove the port forwards and put an Island connector on the network beside the devices.
  3. Reset every default password on those devices. Store the new credentials in the Island Enterprise Password Manager and let Island inject them at login, so no technician or contractor ever holds the shared admin password.
  4. Route employees and contractors through Island Private Access, with access scoped to the sites and devices each person services.
  5. Put a second factor on the commands that matter. Require a fresh MFA challenge before a setpoint change or a defrost, even on controllers with no native MFA.
  6. Turn on session logging for anything that can change a physical state, so a bad change is traceable to a person and a device within minutes.
  7. Put end-of-life equipment on a replacement schedule rather than waiting for the next advisory.

‍

The next wave will look for whatever else has a web page and a public address: HVAC, access control, lighting, pumps, signage. Those devices will keep aging, and their vendors will keep ending support. The one variable an operator fully controls is whether the path to them still starts on the open internet.

‍

Michael Leland

Michael is Field CTO at Island, bringing over 30 years of data networking, operations, and cybersecurity domain expertise. He formerly served as Head of Technical Marketing and Chief Cybersecurity Evangelist at SentinelOne where he was responsible for messaging and strategic development of their XDR product roadmap as well as the identity security portfolio. Prior to SentinelOne, he held the title of Chief Technical Strategist for McAfee. Michael was the co-founder and CTO of NitroSecurity – later acquired by McAfee – where he was responsible for developing and implementing their overall SIEM technology vision and roadmap and has held senior technical management positions at Cabletron and Avaya.