How to Connect Sites Without Increasing Risk: Technical Guidance for Critical Environments For CISOs, IT Directors, network engineers, and operators managing critical infrastructure, a single network connection across sites can be both an operational benefit and a potential hazard. The intent may be simple—enable operational insight, optimize supply chains, or facilitate central control—but the path from isolated islands to interconnected networks is littered with security pitfalls, protocol mismatches, and trust problems.

This article takes a detailed, realistic look at the architectures and disciplines necessary to connect sites safely, especially when the stakes involve industrial or critical infrastructure environments. We'll avoid buzzwords, favoring technical depth and honest assessment.

A Brief History: From Air Gaps to Converged Networks

Before the wide adoption of IP networking, most industrial and critical process environments operated in blissful isolation. This air-gapped security model—where systems were physically disconnected—meant threats had to cross a physical perimeter, typically with removable media as the only vector. While simple, this model failed to scale when real-time visibility and centralized management became business imperatives.

The push towards IT/OT convergence emerged in the 2000s, as Ethernet and TCP/IP replaced serial and fieldbus protocols. Vendors started embedding more intelligence into devices (“smart” PLCs, SCADA nodes), often with limited appreciation for hardening practices. This created attack surfaces within operational technology (OT) that never encountered remote threats before. High-profile incidents (e.g., Stuxnet, 2010) demonstrated the weaknesses of both air gapping and naive network bridging.

Core Principles for Safe Site Interconnection

• Minimize Trust: Do not assume one site (or segment) is as secure as another. Assume breach, and limit trust boundaries by default.

• Explicit Boundaries: Use segmentation at every transition—both logically (VLANs, VRFs, firewalls) and physically, where feasible.

• Least-Privilege Connectivity: Connect only the required assets or protocols, with the narrowest ruleset possible, justified and documented.

• Inspection, Not Just Routing: Transit traffic should be inspected and logged, not only routed or switched via a backbone.

• Resilience and Recovery: Prepare for the loss (or compromise) of routed links; maintain isolation options where “pull the plug” is a viable response.

Network Architecture Models: Choices and Trade-Offs

Flat Routed Networks: The Anti-Pattern

The path of least resistance—simply extending L2/L3 connectivity between sites, sometimes slapping firewalls at perimeters—almost always leads to lateral movement opportunities for attackers. One compromised device or user can traverse networks, exploiting legacy protocols (e.g., SMB, DNP3, Modbus/TCP) and trusted paths.

Annotation: The "flat" architecture was common in early converged networks, under the mistaken impression that VLANs offered security. VLANs, while useful for segmentation, do not enforce strong isolation without ACLs and firewalling.

Hub-and-Spoke with DMZ Control Points

A more defensible approach is the hub-and-spoke topology, where remote sites connect to a central location via point-to-point links or VPNs. Here, traffic is forced through a demilitarized zone (DMZ)—a dedicated tier, often built with dual firewalls and inspection systems such as next-generation firewalls (NGFW), NIDS/NIPS, and/or industrial protocol proxies.

Key Advantages:

• Enables deep packet inspection at the choke point

• Simplifies policy enforcement (default deny on everything but vetted flows)

• Breaks direct trust between remote sites—compromise at one site doesn't grant access to others directly

Key Challenges:

• Potentially single point of failure or bottleneck at DMZ

• Scalability can become an issue as numbers of sites increase

• Requires well-maintained policy management to prevent “rule creep”

Zero Trust Network Access (ZTNA), Microsegmentation, and Identity-based Controls

The most modern approach is to implement Zero Trust security principles across the network, including between sites. This means:

• Authentication and authorization for every connection, ideally using device and user identities, not just IP addresses

• Application-level allowlisting, so only specific workload-to-workload flows are permitted

• Network microsegmentation: Even within a site, or across inter-site VPN, everything is “default deny” unless expressly allowed, possibly enforced by software-based firewalls (host or container)

No magic solution exists—open-source platforms like OpenZiti, SDN-based policy engines (e.g., NSX-T, Cisco ACI), or cloud-based brokers (SASE) each present complexity and require expertise to maintain and troubleshoot.

In critical environments, the caveat is latency, ‘fragile’ legacy protocols, and a population of devices that may not play well with frequent authentication or deep inspection.

Control Plane Considerations: Routing, Resilience, and Monitoring

Routing Protocol Security

Multi-site connectivity is typically established with dynamic routing (OSPF, BGP) or static routes. These protocols need hardened configurations—use OSPF authentication (MD5 or SHA), BGP MD5 password protection, and limit route advertisement. Where possible, Avoid route redistribution between boundary routers except for absolutely required prefixes.

Annotation: BGP, originally designed for the open Internet (see RFC 1105, 1989), lacks built-in strong authentication and is susceptible to route leaks/poisoning when not carefully managed.

Site-to-Site VPN and Encryption

Connectivity should always occur over protected tunnels: IPSec for IP-based systems, potentially GRE-over-IPSec for carrying multiple VLANs or non-IP traffic, and TLS-based VPNs (like OpenVPN or WireGuard) for simpler setups. Certificates and keys must be managed centrally with clear revocation paths.

Caveat: Encryption can introduce overhead on older industrial devices that lack hardware crypto accelerators; always test for performance impact.

Monitoring and Telemetry

Proactively collect flow and packet data at DMZs and site borders. Deploy network detection and response (NDR) systems aware of industrial protocols. Logging must be secured and centralized—unlogged traffic is “invisible” for both troubleshooting and incident response.

IT/OT Collaboration in Practice

A brutal truth: IT and OT have both valid perspectives, and their friction points are unavoidable. The right answer is sometimes a “lesser evil.”

• OT Engineers: Prioritize deterministic traffic, low latency, and system availability.

• IT Practitioners: Focus on maintainable controls, incident detection, and layered defense.

Real integration occurs not by imposing “the IT way” or “the OT way,” but by enforcing minimum standards—network segmentation, strong authentication, reliable monitoring—without undermining production safety or uptime.

Annotation: In practice, pilot new connections “sideways” before rolling out to production, and perform tabletop exercises with joint OT/IT teams.

Deployment Patterns: Practical Examples

Pattern 1: DMZ Data Diode / Unidirectional Gateway

For situations where periodic data exfil (e.g., historian uploads) is required, but inbound commands would introduce unacceptable risk, consider hardware data diodes. These physical unidirectional gateways guarantee—at the circuit level—that information only moves in one direction.

Cons: Application protocols must tolerate “send only,” and human factors (“why can’t I just remote in?”) become social friction points.

Pattern 2: Jump Servers (“Bastion Hosts”) in the DMZ

Deploy hardened jumpboxes as single-points-of-entry for remote administration. All RDP/SSH traffic terminates at these hosts, where strong authentication (MFA, short-lived tokens) is enforced, session is audited, and OT endpoints remain unreachable from external addresses.

Pattern 3: Distributed Firewall + Microsegmentation

Leverage modern distributed firewalling at hypervisor or network edge to create microsegments, controlling which hosts can talk, on what protocol and port, regardless of VLAN or physical segment. This approach is especially valuable for facilities with “flat” legacy networks that cannot be physically separated easily.

Security Basics That Should Never Be Optional

• Patch management for all exposed systems, even when upgrades must be carefully staged for OT devices

• Comprehensive asset inventory—no “unknown” endpoints on critical networks

• Regular risk assessment and validation of segmentation—test what “shouldn’t” be reachable

• Credential hygiene: unique admin credentials per site/facility, rotated regularly

• Incident response plan: document and rehearse how to rapidly disconnect links, contain spread, and restore minimal operation

Conclusion: There Is No Shortcut

Securely connecting sites in critical environments is never about a single tool or magic architecture. Effective strategies combine classic network discipline (segmentation, monitoring), modern security principles (ZTNA, microsegmentation), and, above all, honest collaboration across IT and OT domains.

Every shortcut to "quick connectivity"—from flat networks to one-size-fits-all firewalls—has a price: either in future incident response or in unplanned downtime. The work is in the details, the discipline in policy management, and the wisdom in periodic redteaming to find what’s been missed.

Trust nothing, verify everything, and keep the playbook (and wire cutters) within reach.