Refrigeration System Cyberattacks: The Ownership Gap Behind Europe's Defrost Campaign

The second wave of refrigeration system cyberattacks across Europe did not need a zero-day. Overnight into Monday 2 November, someone switched supermarket cooling units into defrost mode and pushed freezer setpoints as high as 50°C. Stores in at least nine countries pulled chilled stock. Cold-room monitoring at several French blood bank sites was hit. The method was not clever. Commercial controllers were reachable from the internet, some were past end of life, and some still had their default passwords.

The technical fix is old advice. The more useful question is a management one: who, in each of these businesses, owned the controller? Our reading is that in many cases nobody did, at least not in a way that included its security. That ownership gap is not specific to fridges. Most cloud estates have the same one.

What we know, and what we don’t

On 4 November, ENISA, the European Commission (DG CNECT), Europol’s EC3, the EU CSIRTs Network and EU-CyCLONe issued a joint statement. It says that “since 11 October 2026, several commercial refrigeration systems and similar devices have been impacted” across a number of Member States, with a new wave on 1–2 November. It asks organisations to take immediate action to reduce exposure.

Reporting by The Hacker News, citing national broadcasters and the retailers, fills in the detail:

• Belgium: Delhaize (several dozen stores), Carrefour (15 of more than 700), Intermarché (10 to 15), Spar, and one IKEA store. Units were switched into defrost mode.
• Sweden: ICA freezers in Sjöbo set to 50°C; Coop hit at 6 or 7 of about 800 stores.
• Ireland: Musgrave/SuperValu, 13 of 223 stores, chilled stock removed.
• Elsewhere: Estonia (Selver, fixed in about ten minutes), Finland (Kesko), Portugal (Intermarché, 7), Italy (at least 4), Luxembourg, and at least 17 businesses in the Netherlands, according to Danfoss.

Security Affairs, citing the French ministry and Reuters, reports that several regional sites of the French Blood Establishment (EFS) had cold-room monitoring and control systems affected. EFS said there was no impact on blood supplies. Staff moved products to unaffected refrigerators and remote access was disabled.

On the equipment: Danfoss has said several of the affected systems were its products, and that most of the units hit in France were older AK-SM 800 and AK-SC 355 controllers it no longer updates. Danfoss told Dutch broadcaster NOS that the Dutch systems “were not on a secure network and still used default passwords.” According to The Hacker News, the French national CERT alert (CERTFR-2026-ALE-012, which we have not read directly) covers Danfoss AK-SM and AK-SC controllers and Copeland and Dixell xweb, and describes the campaigns as “probably still underway”.

What we don’t know is who is doing this. No group has claimed it. Belgium’s federal prosecutor has opened a criminal investigation, and Belgium’s Centre for Cybersecurity has said attribution may never be determined. We won’t guess.

A controller with three half-owners

Consider how a supermarket refrigeration controller usually gets onto a network.

A refrigeration contractor installs and maintains it. They need remote access to answer alarms at 3am, so they ask for a port to be opened or a remote-access route to be set up. The vendor supplies the hardware and the firmware, and at some point stops supplying updates. The retailer pays for the asset and carries the risk when the ice cream melts. The retailer’s IT team often doesn’t know the box exists, because it was never in IT’s asset register: it came in as refrigeration equipment through facilities.

Each party has a reasonable view of its job:

• The contractor owns uptime, not security.
• The vendor owns the product, but not its deployment, and not after end of support.
• Facilities owns the cold chain, not the network.
• IT owns the network, but only what it can see.

The default password survives because changing it is nobody’s task. The internet exposure survives because the person who opened it moved on to the next site. The end-of-life firmware survives because replacing a working controller costs money and nobody in particular has to argue for it. None of this is negligence by one person. It is a structural gap.

The same gap exists in your cloud

Put the cloud equivalents side by side and the pattern is familiar:

• A contractor’s deployment. A consultancy builds a proof of concept in a sandbox account, opens a management port to its own office IP range “for now”, and the engagement ends. The resource keeps running and keeps billing, and nobody’s on-call rota covers it.
• A vendor integration. A SaaS tool gets a cross-account role or an OAuth grant during a trial. The trial converts, or doesn’t, and the access stays. We covered how this played out in the Northflank vendor-access case earlier this week.
• A marketplace appliance. A virtual firewall, mail gateway or WAF image is launched from a cloud marketplace by the network team. Its admin interface sits behind a security group someone set to 0.0.0.0/0 during setup. It is patched on the appliance vendor’s schedule, which nobody is tracking.
• An end-of-life runtime. A function or container image runs on a version that no longer gets security fixes, because it works and nobody is assigned to move it.

In every case the asset exists, it is reachable, and the security tasks attached to it (rotate credentials, close exposure, patch, retire) belong to no named person. Attackers don’t need a sophisticated exploit for these. They need a scanner and patience, which is what this refrigeration campaign appears to have used.

Regulation is moving the ownership question onto vendors

There is a policy angle here. ENISA’s statement notes that since 11 September 2026, manufacturers must report severe incidents and actively exploited vulnerabilities through the Cyber Resilience Act’s single reporting platform. The CRA’s main requirements, including security updates over a defined support period, apply from 11 December 2027. Entities in scope of NIS2 must report significant incidents to their national CSIRT or authority.

That helps with new products. It does nothing for a controller installed ten years ago that is already out of support. The legacy estate, in buildings and in cloud accounts, stays the operator’s problem. Regulation can push vendors to support products for longer. It can’t assign an owner inside your organisation.

The CloudShieldSecure perspective

At CloudKonsult we built CloudShieldSecure around the idea that you can’t secure what nobody owns, and that the first job is to make the unowned visible. In practice that means three questions, asked continuously rather than once a year:

1. What answers on the internet? Every public IP, load balancer, open security group and exposed admin port across your cloud accounts, including the ones created by contractors and marketplace images.
2. Who does it belong to? Resources without an owner tag, a known creator, or a matching entry in your asset register get flagged as unowned rather than ignored.
3. What does it trust, and what trusts it? Cross-account roles, third-party OAuth grants and long-lived keys mapped to the vendor or person they serve, so dormant access stands out.

None of this replaces the fix. It shortens the time a forgotten resource stays forgotten, which is the gap this campaign exploited.

Recommended actions

If you operate commercial refrigeration or similar building controllers:

• Take controllers off the public internet. Allow remote access only through a VPN or another protected route, as CERT-FR advises (per The Hacker News).
• Change default passwords. For Danfoss controllers, set the security level to “Strict”, per the same guidance.
• Check defrost schedules and setpoints for unexpected changes.
• Treat end-of-life controllers that were internet-facing as likely compromised. A factory reset alone won’t keep them clean while they stay exposed. Plan replacement.

For everyone, including cloud estates:

• Name an owner for every internet-reachable asset, including those installed or operated by third parties. If the contract with your contractor doesn’t say who changes credentials and closes access at the end of the job, add it.
• Run an exposure inventory from the outside in. List what answers on the internet, then match each item to an owner. Anything you can’t match is the priority.
• Track end of support as a risk date, not an accounting date. An unsupported device or runtime that is internet-facing should have a replacement date and a sponsor.
• Review third-party access quarterly. Remove vendor roles, grants and keys that no longer match a live contract.
• Know your reporting obligations. Check whether NIS2 applies to you and what your national CSIRT expects if something like this hits your estate.

The refrigeration attacks will probably be remembered for melted ice cream and blood bank alarms. The lesson worth keeping is less dramatic: the devices that get hacked most easily are the ones nobody is responsible for.

Sources & references

• ENISA et al., Joint statement on cyber incidents in refrigeration systems across the EU (4 November 2026)
• The Hacker News, Second wave of cyberattacks hits refrigeration systems (3 November 2026), including Danfoss statements to NOS and VTM and a summary of CERT-FR alert CERTFR-2026-ALE-012
• Security Affairs, Cyberattack hits French blood banks as hackers target refrigeration systems across Europe (4 November 2026), citing Reuters and the French ministry