When Hackers Can Set Freezers to 50°C, We Need to Rethink IoT Security
Why secure-by-design architecture and the Internet of Disconnected Things matter more than ever.
A Wake-Up Call for Connected Infrastructure
Across Europe, supermarkets are facing a disturbing new reality: refrigeration systems being remotely manipulated, temperatures rising dramatically, and large quantities of food being destroyed. On 2 November 2026, incidents were reported in several European countries, including Sweden, where ICA and Coop stores experienced disruptions to refrigeration and freezer systems. One ICA store in Sjöbo reported that its systems had been set to 50°C.
Similar cyberattacks affected hundreds of French supermarkets in October, demonstrating how vulnerabilities in connected infrastructure can have immediate physical and financial consequences. Investigations into the latest incidents are ongoing, and the precise mechanisms and relationships between attacks have not yet been fully established. But these events raise a much broader question.
Why should a remotely connected system be capable of issuing potentially destructive commands to physical equipment in the first place?
This is not simply a question of stronger passwords, additional firewalls or better intrusion detection. It is a question of architetcure.
Connectivity Should Not Mean Unrestricted Control
For decades, the technology industry has pursued an increasingly connected world. From industrial equipment and transportation systems to building automation, refrigeration and energy infrastructure, devices that once operated independently are now connected to networks, management platforms and cloud services.
Connectivity brings enormous benefits: remote monitoring, predictive maintenance, automated updates and operational efficiency. But it also introduces risk. When networking, security and application functionality share the same execution environment, a vulnerability in one component may expose capabilities that were never intended to be accessible remotely.
A compromised management interface should not automatically provide unrestricted access to the physical processes controlled by a device. Yet traditional IoT architectures frequently place enormous trust in the integrity of their communication and management layers.
What happens when that trust is broken?
The Internet of Disconnected Things
At RIoT Secure, we have spent years advocating a different philosophy. We call it the Internet of Disconnected Things - we even wrote a comprehensive whitepaper about the architecture in 2021. The idea may sound contradictory.
How can a device be connected and disconnected at the same time?
The answer lies in separation of concerns.
A device should be able to communicate securely with external systems without unnecessarily exposing its internal application logic, physical interfaces or safety-critical operations. Rather than treating the entire device as one interconnected software environment, we separate responsibilities into independent domains. One domain handles security, communication, device identity and lifecycle management. Another handles the application itself: the actual functionality the equipment was designed to perform.
These domains communicate through deliberately defined interfaces, rather than sharing unrestricted access to each other's resources. This architectural separation reduces the opportunities for vulnerabilities in the communication infrastructure to propagate into application functionality.
Security Enforced Through Hardware Separation
RIoT Secure's Fusion architecture implements this philosophy through independent microcontrollers. A dedicated security and communication processor handles connectivity, authentication, encrypted communication and device lifecycle operations. The application executes independently on another processor, retaining control over its own memory, peripherals, timing and operational behavior.
This is not simply software isolation or another virtual execution environment. It is physical separation of responsibilities. Our patented µTLS communication protocol provides secure, lightweight communication designed specifically for resource-constrained embedded devices. Together, these technologies establish a foundation in which secure communication and application execution can evolve independently.
Importantly, hardware separation alone does not guarantee safe application behavior. The application must still validate commands, enforce operational limits and implement appropriate safety mechanisms. But separating these responsibilities makes it possible to establish clear trust boundaries and prevent the communication stack from having unnecessary authority over physical operations.
Consider a refrigeration controller. A remote management system may legitimately need to read temperatures, receive alarms or request a controlled configuration change. That does not mean it should have unrestricted authority to disable safety mechanisms, manipulate defrost cycles or override acceptable operating limits.
The ability to communicate with equipment must not be confused with the authority to control everything it does.
Not Just Theory: Commercial Deployment at Stockholm Arlanda Airport
This architectural philosophy is not a recent response to the latest cybersecurity headlines.
RIoT Secure has already demonstrated its technology in commercial operations. At Stockholm Arlanda Airport, our secure IoT platform supported approximately 270 connected ground-handling devices in daily operations over more than three years. The deployment supported functionality including equipment monitoring, operational data collection, geofencing and integration with existing airport workflows. The devices operated in a demanding environment where reliability, secure communications and long-term maintainability were essential.
Our technology was designed to complement existing network security infrastructure, not replace it. In this deployment, the underlying cellular connectivity benefited from a private APN, while RIoT Secure provided its own encrypted communication and device management layer.
The result was a practical demonstration that secure IoT lifecycle management can be deployed commercially without requiring application functionality to be directly exposed to external networks. It is an architectural approach we believe deserves far greater attention across industrial and operational technology.
Security by Design Must Start at the Device
There is a tendency to address IoT security by adding more protection around existing systems.
More firewalls. More monitoring. More authentication. More patches. All of these measures have their place. But they cannot replace fundamental architectural decisions made when a device is first designed.
Security by design means asking difficult questions early:
- Does this device actually need direct internet connectivity?
- Which operations genuinely require remote access?
- What happens if the communication subsystem is compromised?
- Can the application continue operating independently?
- Are physical safety limits enforced locally?
- Can devices be updated without disrupting application behavior?
These questions become particularly important when connected equipment controls physical processes. A cybersecurity incident involving a website may result in unavailable information. A cybersecurity incident involving industrial equipment can result in damaged goods, disrupted infrastructure, financial losses or physical danger.
The consequences extend far beyond the digital world.
We Need to Change the Conversation
The recent supermarket refrigeration incidents should encourage manufacturers, system integrators and infrastructure operators to reconsider how connected devices are designed. The objective should not be to eliminate connectivity. It should be to make connectivity secure, controlled and appropriately isolated from the systems it serves.
At RIoT Secure, this has been our philosophy since 2017. Our work on hardware isolation, lightweight encrypted communications and secure device lifecycle management reflects a simple principle:
Connected does not have to mean exposed.
The technology to build more resilient connected systems already exists. The question is whether we are prepared to make secure architecture a fundamental requirement rather than an optional feature.
