Walk into any plant and ask to see the PLC program, and you'll be shown a version-controlled project with a change history, a factory acceptance test record and a management-of-change file with signatures on it. Now ask to see the MQTT topic hierarchy, the OPC server tag maps, and the transformation pipelines that decide where every piece of that plant's data goes and, increasingly, what happens next.
In most facilities, that second artifact doesn't exist. The knowledge lives in one engineer's head, a shared spreadsheet and a broker configuration nobody has exported since commissioning. Middleware became a control system, and it did so without inheriting any of the discipline we spent seventy years wrapping around control systems.
How the middle layer took over
The classic ISA-95 pyramid put intelligence at the bottom, in rigorously engineered Level 1 logic, and let information thin out as it climbed. That model is dissolving in practice even while it survives on paper: an informal industry poll of 269 practitioners across 41 countries found 92.9% still use ISA-95 in some capacity, but only 26.4% implement its full data exchange. What fills the gap is an ever-thicker middle: OPC servers, MQTT brokers, unified namespace architectures, edge gateways and the emerging industrial DataOps category, whose flagship vendors have tripled revenue three years running by their own accounting.
This layer no longer just moves data. It models it, transforms it and routes it, and routing is a decision. When the newest release of the industry's most widely deployed middleware platform ships an event streams module for routing between tag changes, Kafka topics and handlers, the platform is performing orchestration that used to require engineered logic. The boundary is blurring from below too: the OPC Foundation's Field eXchange specifications push the middleware protocol down into controller-to-controller exchange, and Sparkplug, the de facto payload convention of the unified namespace movement, is now an international standard, ISO/IEC 20237.
None of this is bad architecture. Much of it is good architecture. The problem is what didn't come with it.
Control-system responsibilities, hobby-project governance
Ask who owns the middleware layer and you'll usually find a seam. It's too "IT" for the controls team to claim, too "OT" for the enterprise change board to understand. Security ownership has consolidated upward fast, with 52% of organizations now putting OT security under the CISO, up from 16% in 2022, but a security reporting line is not an engineering owner. A retained-message edit or a topic remap in a broker can re-route a plant's decisions in seconds, with no management-of-change record, no test procedure and no signature. Try doing that to a safety PLC.
Even vendors inside the unified-namespace movement concede the concentration risk. One critique from within the industry puts it plainly: in a fully unified architecture, "one team or person must own the entire global schema," and when every node trusts the same hub, you've defined your blast radius. That's a competing vendor talking its own book, so weight it accordingly, but the observation matches what integrators see in the field: the topic map is folklore, documented nowhere, validated never.
To be fair, there is no public record of a broker outage blinding a plant; the single-point-of-failure argument is structural, not forensic. But the growing literature on broker high-availability engineering exists precisely because practitioners know the structure is real.
The attack surface already found it
Security researchers noticed the middle layer before most asset owners did. Claroty's Team82 spent two years on OPC UA alone, disclosing on the order of 50 vulnerabilities across clients, servers and protocol gateways, building an open exploit framework and chaining bugs into remote code execution on a commercial secure integration server, which is to say, on exactly the product class sold to make this layer safe. CISA has issued repeated advisories for the most widely deployed OPC server family, whose reach is multiplied by OEM rebranding across major automation vendors. The most popular open-source MQTT broker has carried its own recent CVEs.
Set that against what defenders can actually see. The SANS 2025 ICS/OT survey found 12.6% of organizations reporting full visibility across the kill chain, and 10% at Level 2, where SCADA and the data infrastructure live. The layer making an increasing share of the plant's routing decisions is the layer fewest people are watching.
The process industry already wrote the answer
Here's the part that should embarrass the rest of us: a standards body solved this problem years ago, for a different architecture. NAMUR's Open Architecture kept new data paths deliberately out of the control loop, as a "second channel with no impact on the automation system," and then wrote NE 177 to govern the security gateways that channel runs through: defined zones, defined gateway responsibilities, defined verification. The process industry treated its middleware as a control asset from day one.
Discrete manufacturing largely adopted the opposite architecture, putting the broker in the middle of everything, and skipped the accompanying homework. The architecture choice is defensible. Skipping the homework is not. Give the silent layer a signature line
The fix requires no new technology, which may be why it gets so little airtime. It's the transfer of sixty-year-old controls discipline to a layer nobody classified as control.
Classify it first. Under ISA/IEC 62443, brokers, gateways and DataOps hubs are conduits, and conduits carry target security levels and named owners like any zone boundary. If your 62443 zone model doesn't show the broker, the model is describing a plant you no longer run.
Then version-control the namespace. Topic hierarchies, tag maps and transformation configs are code and should live in a repository with history and review; the fact that leading platforms now ship native Git-based version control says the tooling has stopped being the excuse. Put broker and gateway changes through the same management-of-change gate as logic changes, test them in FAT and SAT, and write the middleware into the incident-response plan, because a 42-day dwell time hides comfortably in a layer nobody audits.
Of these, the ownership question matters most. Every other practice follows from someone having the middleware on their performance review, and none survives without it.
The pyramid's old promise was that anything capable of changing the plant's behavior had been engineered, tested and signed for. Middleware now changes the plant's behavior every day. It's time it signed for the privilege.
