In modern Operational Technology (OT) environments, network segmentation on paper can appear robust by using architectural diagrams containing clearly defined zones and conduits, logically constructed communication paths, and risk boundaries that are aligned with frameworks such as ISA/IEC 62443.
However, when we compare the real-world operational requirements, this structured design often begins to erode and exceptions, custom tunnels, and site-specific configurations start introducing inconsistencies in the design and the boundaries are no longer strictly enforced. Because of this a condition forms that can be described as an “illusion of segmentation”.
The Hidden Complexity of Snowflake Sites
In a typical SD-WAN enabled OT network, to ensure a centralized configuration, control and enforce consistent policies a hub-and-spoke model is deployed.
The hubs usually contain centralized management devices and servers to manage all sites at one location containing templates for quick deployment and configurations. However, locations with unique operational dependencies, legacy integrations or non-standard communication requirements, also called snowflake sites, can disrupt this centralized communication.
The snowflake sites often require direct communication paths that bypass the hub-and-spoke model:
- A remote plant requiring access to another site’s Historian.
- A DAS server aggregating data from multiple geographically distributed sites
- Engineering teams needing cross-site access for troubleshooting or maintenance
Because of these requirements, direct site-to-site communication flows are introduced in the network, and the predictable hub-and-spoke design is transformed into a loosely controlled mesh. Over time these temporary workarounds evolve into permanent architectural dependencies.
How Custom Tunnels Disrupt SD-WAN Design
SD-WAN and centralized management-based architectures rely on standardization, templates, and centralized policies and when snowflake-driven exceptions are introduced these principles get compromised.
Breakdown of Automation
When custom tunnels are introduced in the intent-based configurations in a SDWAN based design:
- Routing logic gets manually adjusted and diverts from standard
- Custom policies are needed
- Site-specific configurations override global templates
Because of this the network becomes dependant on manual intervention and reduces the effectiveness of automation and templates.
Reduced Visibility and Troubleshooting Complexity
When custom tunnels and paths outside standardized SD-WAN templates allow the traffic to flow it reduces visibility and troubleshooting complexity increases.
- Monitoring tools lose end-to-end visibility
- Alerts may not correspond to actual traffic routes
- Latency and packet loss become difficult to trace
- Root cause analysis requires manual correlation across sites.
Practical Example:
In a multi-site OT network, working on hub-and-spoke model, direct communication between two level 3 environments is required for historian replication. To enable this, a dedicate tunnel will be made between both sites, separate from the SDWAN zone and additional exceptions will be introduced for engineering access and multiple unmanaged conduits will be emerged. If later there is an intermittent packet loss in the network, troubleshooting will require analyzing configurations across several sites, significantly increasing resolution time.
Configuration Drift Across Sites
As the custom implementations increase in the network, slight variations in behaviours introduced:
- Sites no longer follow identical policy structures
- Inconsistencies in the security controls increase
- The “single source of truth” is fragmented and instead of a standardized template each site gets specific configurations
Over time this reduces predictability which is one of the key benefits of a SD-WAN and centralized management-based designs.
Impact on ISA/IEC 62443 Compliance
Snowflake sites also impact one of the principles of ISA/IEC 63443 emphasizing clear segmentation, controlled communication, and repeatable architectures.
Erosion of Zone Boundaries
When direct communication is enabled between sites it can unintentionally extend trust boundaries. A system in one zone may gain indirect access to systems in another, violating segmentation intent.
Uncontrolled Expansion of Conduits
Ad-hoc tunnels effectively create new conduits that are:
- Often undocumented
- Rarely reviewed against security policies
- Not aligned with defined communication rules
- Potentially bypassing centralized monitoring
Weakening of Access Control
Access scope can get unintentionally broaden by cross-site dependencies. For example, if a vendor access is granted at one site it may indirectly expose systems at another site increasing the attack surface.
Root Cause: Legacy Architectural Assumptions
In many OT networks, legacy OT systems designs cause these issues. These systems are not built for:
- SD-WAN Architectures
- Zero-trust principles
- Multi-site segmentation strategies
- Modern cybersecurity frameworks
Additionally, many Historian and DAS systems often rely on static IP configurations, fixed communication paths, continuous polling mechanisms, and tight interdependencies between nodes.
These constraints force engineers to introduce exceptions simply to maintain operational continuity.
A Structured Path Forward: Policy-First Architecture
To address this challenge, an intentional, policy-driven architecture is needed instead of a reactive design.
Define Policies Before Implementation
To ensure that architecture decisions are guided by policy rather than operational shortcuts , the design process should begin with:
- Clear zone definitions
- Approved conduits and communication flows
- Application-level requirements
- Vendor access controls
- Cross-site data exchange needs
Enforce Standardization Through Templates
To minimize or eliminate exceptions, standardized designs should be made for SDWAN and templates should consistently define:
- Routing behaviours
- Security Policies
- Zone-to-zone communication rules
- Monitoring and logging standards
- Approved data flows only (including Historian and DAS traffic)
Rationalize Legacy Dependencies
To reduce architectural complexity and compliance to standardize designs, following steps should be ensured where possible:
- Consolidate Historian architectures
- Reduce unnecessary cross-site communication
- Introduce intermediary aggregation layers
- Replace direct dependencies with controlled, policy-compliant flows
Conclusion
The illusion of segmentation arises when operational reality differs from design intent and diagrams that may suggest strong isolation, unmanaged exceptions can make it difficult to bring into reality, eroding both security and reliability. To achieve true segmentation, strict adherence to policy, consistent implementation across sites, and disciplined control over exceptions is needed. Eliminating architectural inconsistencies will not only improve technical aspects of the network but also make the networks more secure, resilient and scalable, ultimately achieving sustainable alignment with frameworks such as ISA/IEC62443.
