Remote production sites—satellite facilities, field operations, distribution centers—were historically maintained as isolated networks because wide-area connectivity was expensive. SD-WAN has made it economically feasible to connect remote sites to central management infrastructure. The security and operational challenge is maintaining consistent security posture and zone boundaries across geographically distributed sites without overwhelming your operations team.
The most successful multi-site OT deployments we have worked with treat each remote site as an autonomous network with its own zone structure, local backup systems, and independent operation capability. Central connectivity provides visibility and data aggregation, but does not create operational dependency. This pattern scales to hundreds of sites without creating a fragile hub-and-spoke architecture.
Autonomous Site Architecture
Each remote site should have its own firewall, local historian, local backup power, and production control capability that functions independently even if central connectivity fails. This means each site is a complete mini-version of your headquarters OT architecture: zones, DMZ, segmentation rules, logging. Central systems aggregate logs, patch policy, and configuration baselines, but do not control moment-to-moment operations.
This architecture requires more hardware at each site compared to a thin-client model where remote sites depend on central storage and compute. But the operational resilience and security isolation are worth the cost. A breach at one remote site stays contained at that site and does not propagate through central infrastructure back to other sites.
SD-WAN Patterns for Distributed OT
- Hub-and-Spoke Central Visibility: Run SD-WAN in a hub-and-spoke topology where central headquarters is the hub and remote sites are spokes. This simplifies routing and makes central logging aggregation and policy enforcement straightforward. Spoke-to-spoke traffic (direct remote-to-remote communication) is rare in OT and can be routed through the hub when needed.
- Separate Tunnels for Different Traffic Classes: Create separate encrypted tunnels for production control traffic, security logging, and administrative access. This prevents non-critical traffic from consuming bandwidth on control paths and makes traffic analysis and auditing cleaner.
- Local Firewall Enforcement: Each remote site has its own firewall enforcing the same zone rules as headquarters. The SD-WAN tunnel terminates at the firewall boundary, not inside production zones. This creates a consistent security model across all sites.
- Redundant WAN Links at Each Site: Even remote sites should have dual WAN providers (primary broadband + 4G backup) so they are not dependent on a single carrier. This improves both availability and security—a breach of one carrier's network does not necessarily compromise your site.
Practical Deployment and Operations
Use centralized SD-WAN management to push consistent policies to all sites automatically. An engineer at headquarters should be able to update firewall rules, QoS policies, or VPN credentials at all sites without manual intervention at each location. Centralized management also simplifies compliance—you can audit whether all sites are running current firewall firmware, whether logging is flowing properly, and whether configurations match your security baseline.
If you're deploying SD-WAN to remote sites, reach out to discuss architecture for your environment.
This article was written by the Cascadia OT Security practice, which advises Pacific Northwest data centers and manufacturers on industrial cybersecurity. For engagement inquiries, reach our practice team.