Why 2026 will force internet onto your factory floor, and why your firewall cannot stop it.
Welcome to the near future. It is 2026, and you just bought a shiny new vibration sensor for the plant floor. It is critical, it is expensive, and it refuses to turn on until it pings a licensing server in the cloud. Congratulations, your air gap just evaporated. You are now facing a dilemma that makes a root canal look pleasant: to run your business, you must expose your critical infrastructure to the internet. That ‘secure’ fortress you built? It is actually made of plywood, and the termites just moved in. In this post, we are going to look at why your reliability model is broken, why your firewall is now a decoration, and why the Purdue model belongs in a museum.
The Reliability Roulette
Picture this: You’ve just commissioned a shiny new piece of critical industrial hardware. It promises efficiency, AI-driven insights, and a promotion for whoever signed the PO. But there’s a catch buried in the EULA. This machine doesn’t just run on electricity; it runs on connectivity. It demands a constant heartbeat to a license server or a real-time telemetry stream to function. If that pulse stops, the machine stops.
Suddenly, your factory’s reliability metric has nothing to do with the mean-time-between-failures of the bearings or the motors. It is entirely dependent on the stability of your local ISP. You have effectively built your manufacturing castle on a foundation of wet sand. When the internet connection jitters, your production line hiccups. If a backhoe down the street severs a fibre line, you are dead in the water. To survive this, you are forced to over-engineer your connectivity. A single uplink is now negligence. You need Dual WAN, cellular backups, and satellite failovers. You are now managing a complex telecommunications hub, not just a factory floor.
This introduces a labyrinth of routing complexity that you never asked for. As detailed in High Availability Dual WAN Remote Industrial Connectivity, simply plugging in a second cable doesn’t automatically solve session persistence or failover logic. Furthermore, trying to manage access across these shifting, redundant paths creates a routing nightmare, a struggle we outline in Multiple Connections Inbound Access Challenge. The vendors have effectively offloaded their cloud architecture requirements onto your local network team, forcing you to adopt this fragility and complexity just to keep the gears turning. You’re playing roulette with reliability, and the house — or in this case, the vendor’s cloud — always wins.
Firewalls Made of Wet Tissue Paper
Let’s rip the bandage off: the “Air Gap” isn’t just dead; it’s a fairy tale we tell junior engineers to help them sleep at night. That new piece of operational technology you just integrated? It needs to “phone home” to the vendor’s cloud for licensing, telemetry, and updates. In the old days, you would have simply asked the vendor for an IP address to whitelist in your firewall. Simple, effective, secure.
But this is 2026. The vendor doesn’t use a single static server in a basement. They use a massive Content Delivery Network (CDN) with thousands of dynamic IP addresses that rotate faster than a politician’s promises. You cannot whitelist the cloud.
So, faced with a machine that won’t function, you make the capitulation. You are forced to create a firewall rule allowing outbound access to “Any.” The moment you click apply, your expensive perimeter firewall turns into wet tissue paper. It is technically “on,” but it is entirely porous. You have effectively defanged your own defence.
Now, consider the blast radius. When — not if — that connected device is compromised, it has an unrestricted outbound tunnel. It can exfiltrate data to a command-and-control server or pull down a malicious payload from anywhere on the internet. You didn’t just open a door; you removed the wall. This didn’t happen overnight. As I discussed in Who Moved My Air Gap?, this is the classic “slow boiling frog” scenario. You kept trading small bits of security for functionality, rule by rule, until the water started scalding you. You wanted the blinking lights to turn green, so you let the wolves in.
Purdue is Past Tense and the Zero Trust Fix
If your firewall is now wet tissue paper, the architectural diagram hanging in your office is little more than historical fiction. Let’s be blunt: the Purdue Model is past tense. That cherished hierarchy of OT security has collapsed because you now have Layer 1 devices — sensors and actuators — talking directly to the Cloud (Layer 5), bypassing your DMZ, supervision layers, and every safety control you authourised. Your network map is no longer a neatly layered cake; it is a Mobius strip where ‘inside’ and ‘outside’ are indistinguishable, and lateral movement is just a hop away.
Stop fighting the future with tools from the 90s. The solution is to stop trusting the network entirely. We need to shift from securing the ‘wire’ (which is now porous) to securing the ‘identity’ and the ‘transaction.’ This is the core of Agilicus AnyX and the Identity-Aware Proxy. We replace the concept of a broad network connection with Precision Authorisation. This means allowing a specific user — whether a human on an iPad or a system user in the cloud — to access exactly one endpoint.
This approach allows for outbound-only connections. There are no open inbound ports for the bad actors to scan, effectively restoring a virtual air gap while allowing the necessary data flow. You don’t need a VPN; you need a way of Merging Local Identity With Online Identity without exposing your soft underbelly. It is time to admit that the hierarchy is dead and start Piercing the Purdue Model on your own terms before a hacker does it for you.
Conclusions
You cannot fight progress, even when it is stupid. The vendors have decided that your Operational Technology needs to be online, and your risk model was not invited to the meeting. You can be the curmudgeon who refuses to upgrade and watches the plant rot, or you can adapt. The air gap is dead. Long live Zero Trust. By moving to an identity-centric model with Agilicus AnyX, you can let that greedy little sensor talk to the cloud without handing the keys to your kingdom to every bad actor with a script. It is time to stop securing the network and start securing the transaction. Good luck.