The ISA-95 Bottleneck: Getting Plant Data Past Level 2 Network Segmentation
Cloud analytics projects often stall at the OT/IT boundary. Here are the architectural patterns that work for getting Level 2 data out of the plant without weakening the segmentation that protects it.
A cloud analytics team finishes its models and dashboards, then discovers it can only see plant data that arrives through a slow historian replication job. The data scientists want live PLC values. The OT team will not open a path from the business network into the control network. The project stalls, and both sides are right about something.
This is the Level 2 boundary: the line between the control systems that run the process and the business and cloud systems that want its data. This article explains why that boundary exists, the three patterns that get data across it safely, and how to choose between them and budget for them.
Why the boundary exists
ISA-95 was created to define the interface between control functions and other enterprise functions, based on the Purdue Reference Model in its hierarchical form [1]. In plant terms, Levels 0 to 2 are the sensors, controllers, and supervisory systems that run the process; Level 3 holds operations management such as MES and historians; Level 4 holds business systems. Network segmentation between those levels is what keeps a problem on the business network from reaching the controllers.
NIST SP 800-82r3, the federal Guide to Operational Technology Security, provides guidance on securing OT while addressing its unique performance, reliability, and safety requirements [2]. The UK NCSC's secure connectivity principles for OT are specific about the boundary: industrial control protocols such as Modbus, OPC DA, and EtherNet/IP should be restricted to isolated OT segments; data exchange between OT and IT should be brokered through a DMZ using secure, standardised protocols such as OPC UA over TLS, MQTT over TLS, or HTTPS; and there should be no inbound connectivity from IT to OT [3].
So the question is not how to get around segmentation. It is how to design data paths that respect it.
Why projects stall at Level 2
The pattern is familiar:
- Analytics is designed first. The cloud architecture assumes live data and is built before anyone asks how data leaves the plant.
- Polling is proposed. The first idea is often to have a cloud service or business-network server poll controllers directly, which breaks the no-inbound rule.
- Historian replication is the fallback. It respects the boundary but may deliver data in batches that are too slow for some use cases.
- Costs appear late. DMZ infrastructure, security assessment, network upgrades, vendor services, and cutover windows were never in the original budget.
Starting with the boundary instead of the dashboard avoids most of this.
Key Statistics
Purdue model [1]
The hierarchical reference ISA-95 used to define the control and enterprise interface
DMZ [3]
Where the NCSC says OT to IT data exchange should be brokered
No inbound [3]
The NCSC principle that IT should never open connections into OT
2008 [4]
Release of OPC UA, the platform-independent, service-oriented successor to OPC Classic
Pattern 1: DMZ broker architecture
The default pattern places a broker in a DMZ between OT and IT. Systems in the OT network push data outward to the broker; business and cloud systems read from the broker. Nothing on the business side initiates a connection into OT.
Strengths: matches the NCSC guidance [3], works with existing historians and gateways, and keeps a clear security boundary.
Watch for: capacity. A broker sized for normal process tags can struggle when you add high-rate data such as vibration waveforms. Do heavy processing at the edge inside OT and send features or summaries through the broker, rather than raw high-frequency streams.
Pattern 2: publish-subscribe over secure protocols
Polling every tag on a schedule wastes bandwidth and puts load on controllers. Publish-subscribe sends updates when values change. OPC UA is a platform-independent, service-oriented architecture with an information modeling framework and security controls including encryption, message signing, and certificate-based authentication [4]. MQTT is an OASIS standard messaging protocol for IoT, designed as an extremely lightweight publish/subscribe transport [5].
Combined with the DMZ pattern, an OT-side gateway publishes changes, over TLS, to a broker in the DMZ, and cloud subscribers consume from there. The information model travels with the data, which helps keep asset context intact.
Watch for: topic and namespace design. Agree naming that maps to your asset hierarchy up front, or you will rebuild it later. Our guide to why predictive alerts point to the wrong asset covers the identity side.
Pattern 3: unidirectional security gateways
For the most critical sites, some operators use unidirectional gateways that allow data to flow out of OT and physically prevent any flow back in. Because there is no return path, many remote-access and command paths are simply impossible.
Strengths: the strongest separation available for outbound data.
Watch for: anything that needs a return path, such as acknowledgements, remote configuration, or writing results back to OT systems, must be redesigned or handled locally. Hardware and redundancy costs are higher than for a software broker, so reserve this pattern for sites whose risk assessment calls for it.
| Pattern | Security posture | Supports return path | Best fit |
|---|---|---|---|
| DMZ broker | Strong, if no inbound from IT | Only through controlled, brokered paths | General manufacturing |
| Publish-subscribe via DMZ | Strong, with TLS and certificates | Only through controlled, brokered paths | High-volume telemetry and context-rich data |
| Unidirectional gateway | Strongest for outbound data | No | Critical infrastructure and high-consequence sites |
| Historian replication | Depends on the replication path | Limited | Legacy integration and batch analytics |
| Direct connection from IT | Breaks the no-inbound principle [3] | Yes | Avoid for production control networks |
Latency: decide what you actually need
Before choosing a pattern, list each use case and the latency it really needs:
1. Control and safety functions stay in OT. They should never depend on a cloud round trip. 2. Operator-facing alerts may need seconds; run them at the edge inside OT where possible. 3. Maintenance and reliability analytics can usually tolerate seconds to minutes. 4. Reporting and model training can tolerate batch delivery.
Most analytics use cases sit in the last two groups, which any of the patterns above can serve. For the time-critical cases, our article on the edge-to-cloud latency budget explains how to keep the critical path local.
Process at the edge, send summaries across the boundary
High-frequency vibration or image data rarely needs to cross the boundary raw. Run transforms and feature extraction on edge devices inside OT and send spectra, features, and alerts through the broker. It cuts bandwidth and keeps the broker within capacity.
The vendor lock-in trap
Control system vendors offer integrated edge and connectivity products that work well inside their own ecosystems. Mixed-vendor plants are common, though, and a single-vendor path can leave other systems out. Prefer open, standardised interfaces such as OPC UA and MQTT at the boundary so the data path survives changes in analytics platform or controller vendor. Also check support agreements: some vendors restrict third-party software on their servers, which affects where gateways and agents can run.
Building the business case
IT-led proposals often budget for cloud services and assume data ingestion is solved. A realistic estimate includes:
- DMZ infrastructure: firewalls, broker servers, and licensing.
- Edge gateways: hardware and software inside OT, per plant or per area.
- Network upgrades for the added OT to IT traffic.
- Security assessment and testing against NIST SP 800-82r3 [2] or your corporate OT standard.
- Vendor professional services for controllers and historians.
- Cutover windows scheduled around production.
Price each line with real quotes. Then tie the value to specific use cases, such as predictive maintenance alerts reaching the CMMS faster or quality data reaching engineers within a shift. Our CMMS integration architecture guide covers the downstream side.
FAQ: common Level 2 extraction questions
Can we install agents on SCADA servers to push data to the cloud? Check the control system vendor's support terms first; many restrict third-party software on those servers. A gateway on a separate device inside OT, pushing to a DMZ broker, is usually safer.
Do we need a unidirectional gateway? Only if your risk assessment says any return path is unacceptable. For most plants, a well-designed DMZ broker with no inbound connectivity from IT meets the need [3].
How do we handle high-frequency data? Process it at the edge and send features and summaries, not raw streams.
Is historian replication good enough? For reporting and model training, often yes. For alerts that need to reach people quickly, use an edge path inside OT or a publish-subscribe path through the DMZ.
Next steps for breaking through the Level 2 boundary
1. Map your levels: which systems sit at Levels 0 to 4 and where the boundaries are today. 2. List use cases with latency needs, using the four groups above. 3. Pick the pattern that meets the strictest use case without breaking the no-inbound principle. 4. Design the namespace so asset identity is preserved end to end. 5. Budget the full path, including security assessment and cutover, before committing to the analytics build.
References
[1] International Society of Automation, "ISA95, Enterprise-Control System Integration." https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95
[2] NIST, "SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security," September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final
[3] UK National Cyber Security Centre, "Secure connectivity principles for OT, Principle 4: Use standardised and secure protocols." https://www.ncsc.gov.uk/collection/operational-technology/secure-connectivity/principle-4
[4] OPC Foundation, "Unified Architecture." https://opcfoundation.org/about/opc-technologies/opc-ua/
[5] MQTT.org, "MQTT: The Standard for IoT Messaging." https://mqtt.org/
Related articles
Ready to put this into practice?
See how Monitory helps manufacturing teams implement these strategies.