The Split Brain: What It Takes to Run Industrial Edge Applications

Industrial operations are supposed to run on live data, autonomously, always-on. Underneath that: unreliable connectivity, strict network separation, and decades-old control systems that were never built to talk to the cloud. A cloud-first architecture does not survive contact with a vessel mid-Atlantic or a substation behind an air-gapped network.

This is where the industrial edge application becomes essential.

One application, two brains

An industrial edge application is a solution that connects physical machinery (operational technology) and digital infrastructure (information technology). On the plant floor, machinery is monitored and controlled by supervisory control and data acquisition systems, built from a few recurring parts:

• Human-machine interface: software that visualizes data and lets operators act on it.
• Controllers: programmable logic controllers (PLCs) and remote terminal units (RTUs): the microprocessors that talk directly to machinery and turn raw signals into usable data.
• Communication network: very often a deliberately isolated, air-gapped connection that reaches the industrial assets.

The cloud is excellent at large-scale analytics, long-term storage, and central coordination. But industrial plants live in a world where milliseconds matter and where connectivity cannot be assumed. Either because coverage is poor (a vessel in transit) or because isolation is a design choice (network separation for safety and cyber security).

So the application splits. Half of it lives in the cloud. Half of it lives at the edge, right next to the controllers, on a network that is separated from everything else by design. The two halves are frequently out of contact with each other, and each half has to keep working on its own. That is the split brain: a single application whose two hemispheres run in fundamentally different trust environments and cannot rely on staying connected.

This is exactly the problem Zero Trust was built for. Zero Trust replaces “trust everything inside the perimeter” with “never trust, always verify”. When your application spans a trusted cloud and an untrusted, intermittently-connected edge, there is no perimeter left to trust anyway. Every node, every workload, and every person has to prove who they are, on both sides of the brain, whether or not the link is up.

Six services

To get real value from an industrial edge application, you need a set of foundational services. We organize them as six services that, not coincidentally, map directly onto the six Zero Trust pillars. Each one has to hold on both sides of the split brain.

Identity & Access Management

In a split-brain application there is no shared network you can lean on to decide who is trusted. Identity has to be intrinsic to each node, each workload, and each user. It also has to be verifiable at the edge when the cloud is unreachable.

That starts with a local root of trust: a hardware-backed identity in every edge node, so it can prove what it is after a reboot or a tampering attempt. On top of that sits a per-node public key infrastructure (PKI): every node carries its own certificate, and downstream modules communicate over encrypted, mutually-authenticated channels (mTLS). No shared credentials. If one node is compromised, the blast radius stays at that one node.

The same principle covers people: operators and engineers authenticate and are authorized explicitly.

Nodes

The edge half of the application runs on physical compute in places nobody wants to travel to. Those nodes are the most exposed surface you have, so they are treated as untrusted until they prove otherwise.

The Nodes service manages that hardware end to end. Ruggedized devices are provisioned with the correct operating system image, packages, and dependencies, then hardened so unauthorized access is closed off. Because vulnerabilities do not wait, security patches and upgrades are delivered over the air across the whole fleet. No flying, sailing, or driving to site with a memory stick. The service audits the real state of each node and reconciles it. And when a site is decommissioned, the node is wiped: secrets, certificates, and connections removed.

Provision, harden, patch, decommission for thousands of nodes.

Networks

The defining property of the edge is separation: air-gapped or tightly segmented networks that keep operational technology isolated from the rest of the world. The Networks service preserves that separation while still letting the two brains exchange what they need to.

The model is verify explicitly and connect outbound-only. The edge device dials out to the cloud; nothing on the device is reachable from the public internet, and no inbound firewall ports are opened. Combined with segmentation between the operational and information networks, this removes most of the “exposed service” attack surface that has traditionally plagued connected industrial systems. The link can drop at any time and the design assumes it will at some point. Neither brain depends on the other being reachable to stay safe.

Applications & Workloads

Once nodes and networks are in place, you need to run things on them: data collectors, control applications, historians, vision models. The Applications & Workloads service is the control plane for that. The service combines orchestration and configuration into one.

Orchestration lets you deploy, upgrade, and roll back workloads across thousands of distributed devices, whether they are online, on constrained links, or fully air-gapped. Workloads can declare dependencies on one another, e.g.: a historian feeding a dashboard, an image pipeline feeding a vision model. Another use case is a control workload that can take direction from the cloud while still setting local values from local data, so, for example, energy consumption never exceeds the grid connection even if the cloud goes quiet.

Configuration handles the fact that no two sites are alike. One customer scaled by buying grid hardware from five different vendors, which left every site as a mixed bag with its own network settings. Rather than writing bespoke software per site, the service discovers what assets exist, configures workloads to match, updates them as equipment changes, and flags configuration drift. You deploy one workload to the whole fleet and tailor it per site.

Data

The old picture of a one-way, bottom-up data pipeline does not fit the split brain. Some data must flow to the cloud; some is too high-resolution to ship over a limited link; and the connection to send any of it may not be there at all.

The Data service begins at the edge, ingesting from machinery over the usual industrial protocols (OPC UA, SIMATIC S7, Modbus TCP), then buffering, transforming, and forwarding. Along the way it aggregates and filters to fit the available bandwidth and latency. High-frequency data lands in an edge historian for immediate local analysis; dashboards and control logic read it without a cloud round trip, and AI models run inference on it in place, close to the source.

Crucially, both brains have to agree on what the data means. A Unified Namespace replaces the rigid, pyramid-shaped model of pushing everything upward with a real-time semantic hierarchy in a hub-and-spoke arrangement: power is always labelled power, always in kilowatts, wherever it is read. That shared contract is what lets you train a model on data in the cloud and trust that it sees the same shape of input when it runs inference at the edge.

Observability

At the edge, the network is the first thing to fail. Most monitoring stacks quietly assume it never will. On a vessel mid-ocean or a remote site on a flaky cellular link, that assumption breaks quickly.

Observability therefore has to be lightweight and distributed. Each device captures its own metrics, logs, and traces locally, buffers them while the network is down, and forwards them when it returns. Nothing depends on the cloud being reachable to keep working. Pushing intelligence onto the device itself pays off twice: proactive alarms warn operations about a degrading component before it fails, and for well-understood failure modes, a stuck service, an expired certificate, self-healing routines resolve the issue without a human. All of this telemetry, including authentication events and configuration changes, converges into a single pane of glass so security and operations see one consistent picture across information and operational technology. It is what makes running a large fleet with a small team feasible: you only get paged for what actually needs you.

Ending the split

Most companies still run a hard split between operational technology and information technology: two teams, two networks, two versions of the truth. The industrial edge application closes that gap. Its two halves do not have to agree on everything, and they will not always be in contact. They have to keep working together when they can, independently when they must. Get these six services right, and the split brain becomes the architecture: cloud-scale insight and edge-grade autonomy in one application, secure by default on both sides of the divide.