Your Freezer Doesn't Need a Digital Transformation. It Needs to Stay Cold.

There is something particularly ridiculous about having to include a supermarket freezer in a cybersecurity incident meeting. Its job description is not especially ambitious. Keep things cold. Continue keeping things cold. Ideally, do this without becoming an international news story.

But the European refrigeration incidents reported on November 2, 2026, deserve more than a joke about smart appliances. I think they raise a much less comfortable question for anyone building connected hardware: when we sell remote control as a convenience, how much responsibility are we taking for what somebody can remotely control? (insurancejournal.com)

What happened

Insurance Journal’s November 2 report described suspected attacks affecting supermarket refrigeration in Belgium, Ireland, Sweden, Finland and Estonia. Reported cases included 15 Carrefour outlets in Belgium, around five Spar stores and 13 SuperValu locations in Ireland. Food was discarded or removed from sale. Danfoss confirmed its products were involved. (insurancejournal.com)

The initial accounts were not equally definitive. Sweden’s Coop confirmed a hack, while ICA described an incident without confirming an attack. Finland’s Kesko reported temperature anomalies and said an IT-related cause remained possible. That distinction matters: a collection of disrupted freezers is not, by itself, a complete forensic explanation. (insurancejournal.com)

A Reuters follow-up published by Insurance Journal on November 4 described attacks across eight countries. ICA said all 23 of its affected stores had equipment connected outside its centrally managed network. Coop’s seven affected stores were operating again, with refrigeration disconnected from the internet. Danfoss advised against making systems directly internet-accessible. (amp.insurancejournal.com)

The scope of exposure was still substantial. On November 5, Censys reported 3,124 internet-exposed hosts across two refrigeration-controller product families, down from 6,695 on October 9. Those are exposure measurements, not an attacked-store count. Censys also said nobody had claimed responsibility and that a common perpetrator across the October and November waves remained unconfirmed. (censys.com)

Why it matters

What interests me here isn't the novelty of somebody interfering with refrigeration. It's the definition of a successful system.

If we were reviewing a proposed supermarket installation, would we call it successful because the remote dashboard worked? Because a contractor could change settings without visiting? Because the rollout finished within budget?

Or would we require evidence that the equipment could keep doing its essential job when remote management became unavailable, untrustworthy or actively hostile?

Those are rather different acceptance criteria.

My reading of the ICA detail is that network ownership deserves as much attention as the device itself. Equipment outside the centrally managed network featured in every affected ICA store identified in the follow-up. That does not establish the exact entry point. It does make the boundary between central oversight and local installation an obvious place to investigate. (amp.insurancejournal.com)

For a builder, I would turn that observation into a requirement: every path capable of changing refrigeration behavior needs an owner, an inventory entry and an approved purpose.

Not just the path our application happens to use.

A beautifully secured dashboard should not earn us much confidence if nobody has checked whether a maintenance connection goes around it. That's a design-review question, not an allegation about how these particular incidents happened.

And this is where I think the conversation becomes useful for smaller teams. You don't need to solve every possible attack to ask whether your product gives someone more authority than their job requires.

A connected freezer should lose its internet connection before it loses its ability to keep food cold.

Remote access is a feature. Unlimited authority shouldn't be.

I'm not interested in the lazy conclusion that refrigeration should never have a network connection.

If a customer wants remote monitoring, I would rather understand the operational need than deliver a lecture about how everything was better before Ethernet. Ask what they need to see, what they need to change, and how quickly either action needs to happen.

Then design those capabilities separately.

For a refrigeration project, I would propose making routine observation available without granting routine control. Someone checking conditions should not automatically receive permission to change operating parameters. A maintenance technician's access should have an explicit scope and duration. An exceptional operation should look exceptional in the interface and in the audit trail.

These are proposed design rules, not a reconstruction of the attacks.

The harder question is what the machine should refuse to do even when an instruction arrives through an approved account.

I would want the refrigeration engineer, equipment manufacturer and software team to define that together. What are the legitimate operating modes? Which changes require local confirmation? What happens if a remote command conflicts with a locally enforced limit? How is maintenance distinguished from ordinary operation?

The answer shouldn't be a web developer picking a temperature range because it looks reasonable.

Nor should it be that administrator access means every possible instruction is acceptable. Administrator is a permission category. It is not a qualification in refrigeration engineering.

I'd also put independent verification on the design agenda. Can the operator compare commanded behavior with separately measured conditions? Can an alert reach somebody without depending entirely on the same management component being investigated?

I wouldn't claim those measures guarantee safety. I would insist that the team explain which failures they address, which they don't, and how they will be tested.

That is a considerably more useful conversation than whether the dashboard needs another shade of green.

The controller needs a retirement plan, not a permanent exception.

The original report raised legacy software that might not be patchable as one possible reason equipment remained vulnerable. It did not establish that explanation for every affected installation. (insurancejournal.com)

Even with that uncertainty, there is a procurement question worth taking seriously: what exactly are we buying when we buy connected equipment?

I would want the purchase to include a support timeline, a documented update process, configuration export, recovery instructions and a credible way to operate without permanent vendor access. If those aren't available, I would want the limitations recorded before installation, not discovered during an incident.

This doesn't mean throwing away useful machinery whenever its software becomes inconvenient.

It means treating mechanical usefulness and software support as separate decisions. Ask whether the controller can be replaced without replacing the refrigeration plant. Ask whether remote functions can be restricted while preserving validated local operation. Ask who will fund and approve that work.

For a small retailer, I would prefer a phased, documented plan over a grand modernization proposal nobody can afford. Put the most consequential exposures first. Assign deadlines. Require someone with budget authority to accept any temporary exception.

The important word there is temporary.

Censys observed a substantial fall in exposed controllers, but explicitly cautioned that its measurements could not explain why systems disappeared from view. A falling exposure count should not be presented as proof that every underlying installation has been repaired. (censys.com)

My proposed completion test would be stricter: show the approved access routes, identify the supported software, demonstrate local operation, and rehearse recovery.

A device disappearing from a search result is encouraging. I wouldn't make it the handover certificate.

What to actually do

If we were reviewing a connected refrigeration deployment at Kordspace, I would start with these six tasks. Treat them as a review agenda to work through with qualified refrigeration and security specialists, not instructions to improvise on running equipment.

1. Inventory the control paths, not just the boxes. Record each controller, software version, support status, network connection and maintenance account. Include contractor access and separately installed communications equipment. Ask who can change behavior from outside the premises and who approved that route.

2. Remove unnecessary public access through a controlled change. Danfoss's advice in the follow-up was that systems should not be directly accessible through the internet. Plan any change with the equipment maintainer, confirm local operation, and verify that necessary alarms still reach their recipients. Pulling an unidentified cable is not a security architecture. (amp.insurancejournal.com)

3. Write down the limits of remote authority. Define which roles can observe, acknowledge alarms, modify settings or enter maintenance modes. Require the engineering team to document valid operating boundaries and exceptional procedures. Test those rules against misuse scenarios before calling the feature finished.

4. Rehearse losing the management service. In an approved test environment or maintenance window, establish what happens when remote connectivity disappears. Who receives notice? What continues locally? Who can intervene? Record actual results rather than accepting a reassuring answer in a sales presentation.

5. Make alerts somebody's job. Name the primary responder, backup responder and escalation route. Rehearse an overnight scenario. Include the refrigeration maintainer and the people responsible for product handling; software developers should not invent food-disposition decisions while troubleshooting a controller.

6. Define recovery before reconnection. Agree how configurations and relevant logs will be preserved, how access will be reviewed, and who authorizes a return to remote operation. Give unsupported equipment a funded replacement or containment plan. Avoid treating a successful reboot as the end of the investigation.

None of that requires pretending we already know the exact exploit or perpetrator behind every reported incident.

It requires being precise about what we know, honest about what we don't, and unwilling to confuse connectivity with operational readiness.

The freezer doesn't need to be impressive. It needs to stay cold when the impressive parts stop working.