Micro-segmentation is replacing broad Purdue zones as the preferred approach for securing modern OT networks. Instead of grouping all PLCs into one Level 1 zone, organisations are creating dozens of small, isolated segments based on business function. A packing line gets its own segment. A bottling line gets its own segment. A water treatment process gets its own segment.
The security benefit is clear: if attackers compromise one segment, they're contained. They can't pivot to other processes or systems. But this granular segmentation creates a monitoring challenge that most organisations don't anticipate until deployment.
Standard SolarWinds deployments require bidirectional access that breaks segmentation boundaries, or they can't see into isolated segments at all. This article walks through how to deploy SolarWinds in micro-segmented environments without compromising either security or visibility.
As a bonus, this approach also satisfies SOCI compliance requirements for Australian critical infrastructure operators.
How to deploy SolarWinds in micro-segmented environments
The architecture uses separate SolarWinds instances for IT and OT networks, with remote collectors deployed within each OT micro-segment. Here's an architecture diagram (SolarWinds components shown in orange).
The OT monitoring instance
A single SolarWinds instance is deployed in a secure location outside all micro-segments (typically in a management network or DMZ). This instance serves as the central aggregation point for all monitoring data across your OT environment.
This instance doesn't poll devices directly. It receives data pushed to it from remote collectors deployed within each micro-segment. This is a critical architectural distinction: the monitoring system doesn't reach into segments, segments push data out to the monitoring system.
Having this separate OT instance allows the OT network to be isolated from IT during security incidents while maintaining full monitoring capability.
One remote collector per micro-segment
Inside each micro-segment, deploy a dedicated remote collector. This lightweight agent sits within the security boundary, collects monitoring data from devices in that segment, and sends it upstream to the OT instance via encrypted, outbound-only connections.
Why one collector per micro-segment?
Respects security boundaries: The collector lives inside the micro-segment. It doesn't reach across boundaries or require cross-segment access. Each micro-segment remains isolated. If a micro-segment is compromised, collectors can't communicate with each other, therefore containing the breach.
No inbound firewall rules: Remote collectors only communicate outbound. You don't need to open inbound ports through your micro-segment firewalls, which would create potential attack vectors. The traffic flow is strictly one direction: micro-segment devices to collector, collector to OT instance.
Data buffering during connectivity loss: If connectivity to the OT instance breaks (network issues, deliberate isolation during an incident), monitoring continues locally in the micro-segment. Data queues for up to 24 hours and syncs when connectivity returns. Your micro-segment doesn't go dark just because the network hiccups.
Traffic flow architecture
The monitoring data flows in a single direction:
Devices within micro-segment → Remote collector (within the segment boundary)
Remote collector → OT monitoring instance (outbound-only, encrypted)
At no point does the OT instance or any other segment have inbound access to your micro-segment. The firewall rules remain strict: outbound monitoring traffic is permitted, everything else is default deny.
This architecture scales naturally. Whether you have 10 micro-segments or 100, the pattern remains the same: one collector per micro-segment, all feeding to a central instance. Adding new micro-segments means deploying another collector, not redesigning your entire monitoring architecture.
Achieving end-to-end visibility
End-to-end visibility across both IT and OT networks is achieved with the enterprise console layer on top of your IT and OT instances. This provides unified visibility across IT and OT without compromising the independence of either environment.
During normal operations, the enterprise console aggregates data from both IT and OT instances. During security events that require isolation, the OT instance stops communicating with the enterprise console but continues operating independently with full visibility into all micro-segments.
Micro-segmentation vs Purdue: Different approaches, same monitoring principles
Micro-segmentation and Purdue represent different philosophies for network security:
Purdue approach: Horizontal layers based on function level
All Level 1 devices (PLCs) in one zone
All Level 2 devices (SCADA) in another zone
Security boundaries between layers
Micro-segmentation approach: Vertical slices based on business process
Packing line devices in Segment A
Bottling line devices in Segment B
Quality control devices in Segment C
Security boundaries between processes
Both approaches share a common requirement: monitoring must respect security boundaries without compromising visibility. Whether you're separating by Purdue level or by business function, the architectural principle remains the same. Use remote collectors to monitor within boundaries, not across them.
For organisations implementing the Purdue model, we've written a detailed guide on aligning SolarWinds with Purdue architecture. The same core principles apply: separate instances for IT and OT, remote collectors within security zones, outbound-only communication.
The bottom line
Remote collectors are the key to monitoring that respects segmentation boundaries. Deploy one in each micro-segment, let them push data outbound to a central instance, and maintain strict firewall rules. This way, your segments stay isolated and your monitoring stays comprehensive.
For a real-world example of how this architecture supports regulatory compliance and operational continuity, read our case study on maintaining continuous monitoring during SOCI compliance lockdowns. It details how a Queensland utilities provider uses this architecture across 30+ isolated network segments.
For help aligning SolarWinds with a micro-segmented environment, get in touch and we'll walk you through the process.
