Multi-Site OT Security: How to Scale Zero Trust Across 50+ Locations

The Multi-Site Problem

A single manufacturing plant with 200 OT devices is a security project. A company with 50 plants across 12 countries, each with different network topologies, equipment vintages, and local IT capabilities, is an architecture problem.

The challenges are structural:

• Policy consistency: The same vendor should have the same access restrictions at every site. In practice, each site configures its own firewall rules, VPN tunnels, and access lists independently.
• Visibility: The central security team cannot see who is accessing what at Site 37. Each site has its own logs, its own formats, its own retention policies.
• Staffing: Most remote sites have zero dedicated security staff. A water treatment plant with 3 operators does not have a security engineer. A substation has no on-site IT at all.
• Network diversity: Site A has a modern segmented network. Site B has a flat Layer 2 network from 2008. Site C is air-gapped. A security architecture that requires uniform network infrastructure will never deploy.
• Deployment speed: If adding a new site takes 6 weeks of on-site configuration, the security program will never catch up with business expansion.

The Traditional Approach (and Why It Fails)

Most organizations attempt multi-site OT security by replicating the same per-site deployment at each location:

1. Deploy firewalls at each site
2. Configure site-specific rules
3. Set up VPN tunnels for remote access
4. Install jump hosts for vendor access
5. Configure local logging
6. Repeat 50 times

This approach has predictable failure modes:

• Configuration drift: By month 6, no two sites have the same firewall rules. Policies diverge as local teams make exceptions and adjustments.
• No central visibility: Logs exist at each site, but nobody aggregates or correlates them. A vendor accessing 5 sites in one day is invisible to the central team.
• Slow incident response: When an incident occurs at Site 23, the central team needs VPN access to the site, familiarity with the local configuration, and access to local logs. Response time is measured in hours or days, not minutes.
• Unsustainable cost: Each site needs firewall licenses, VPN concentrators, jump hosts, logging infrastructure, and periodic on-site configuration. At 50+ sites, this becomes a multi-million-dollar recurring cost.

The Centralized Overlay Architecture

The alternative is a centralized policy, distributed enforcement model. The architecture has three components:

1. Central management plane: A single policy engine where the security team defines all access rules, user permissions, and compliance requirements.
2. Distributed enforcement at each site: A lightweight appliance or VM at each location that enforces policy locally, mediates all access, and records sessions.
3. Encrypted overlay network: A secure, software-defined network connecting all sites to the central management plane without requiring changes to the underlying network infrastructure.

This is the pattern the Access Gate implements. Here is how it works in practice.

Deployment: What Happens at Each Site

Day 0: Ship the Appliance

The central team configures an Access Gate appliance (or prepares a VM image) with the site's baseline policy. The appliance ships to the site.

Day 1: Connect and Register

On-site staff (an operator, a plant manager, anyone who can plug in an Ethernet cable) connects the appliance to the local network. The appliance:

• Obtains a network address
• Establishes an encrypted tunnel to the central management plane
• Registers itself and pulls the latest policy configuration
• Begins discovering local network assets

No firewall reconfiguration. No VLAN changes. No on-site security expertise required.

Day 2: Enforce and Record

The appliance is live. All access to OT assets at this site now routes through the local Access Gate. The central team can:

• See all sessions at this site in the central dashboard
• Push policy updates that take effect immediately
• Review session recordings
• Receive alerts for policy violations

Total deployment time per site: 1-2 days, most of which is shipping time. Compare this to the 4-6 weeks typical for a traditional firewall and VPN deployment.

Day 2 Operations for the Central Team

Once sites are deployed, the central security team manages everything from one place.

Adding New Sites

1. Configure the new site's baseline policy (copy from a template, adjust for site-specific assets)
2. Ship the appliance
3. Remote staff plugs it in
4. Site appears in the central dashboard within minutes

Updating Policies

A policy change (e.g., "all vendor sessions require MFA and session recording") propagates to every site simultaneously. No site visits. No per-site configuration. The change takes effect at all 50+ locations within minutes.

Investigating Incidents

When an alert fires at Site 23:

1. The central team sees the alert in the unified dashboard
2. They pull the session recording immediately, no VPN required
3. They review exactly what happened: who connected, what protocol, what commands
4. They can revoke the user's access across all sites with a single action

Compliance Reporting

Generate a single compliance report covering all sites. The report shows:

• Total sessions by site, user, and protocol
• Policy violations and remediation actions
• Session recording coverage (percentage of OT access paths recorded)
• User access patterns across sites

One report, all sites, ready for the auditor.

Comparison: Per-Site Deployment vs. Centralized Overlay

What This Means for Different Industries

Manufacturing (10-200 plants)

Each plant has different equipment, different vintages, different network setups. The overlay approach treats each plant as a policy enforcement point. The central team defines role-based access (maintenance engineer, vendor, operator) and the policy applies uniformly regardless of what the plant's network looks like underneath.

Utilities (substations, treatment plants, pump stations)

Dozens or hundreds of unmanned remote sites. No on-site IT. The appliance ships, plugs in, and connects. The central team has visibility into every session at every substation without maintaining VPN tunnels to each location. See how this works in practice for power grid substations and ski resorts with 55+ distributed lift stations.

Defense and Aerospace (multiple facilities, strict compliance)

CMMC requires consistent controls across all facilities handling CUI. A centralized overlay ensures every facility meets the same audit standard, with session recording and access logs generated uniformly across all sites.

Retail and Distribution (warehouses, distribution centers)

High site count, low complexity per site, zero security staff on location. The appliance model was designed for this: ship, plug in, manage remotely.

Scaling Principles

Three architectural principles make multi-site zero trust practical:

1. Policy lives in one place. Every access rule, every user permission, every compliance requirement is defined once and enforced everywhere. Configuration drift becomes impossible.
2. Enforcement is local. The appliance at each site handles all mediation locally. If the connection to the central management plane is interrupted, local enforcement continues with the last-known policy. No single point of failure.
3. The overlay is independent of the underlay. It does not matter whether the site has an unsegmented network, a segmented network, or an air-gapped network. The overlay creates a consistent security layer on top of whatever exists. For a detailed comparison of this overlay approach versus traditional VLANs, see overlay networking vs VLANs for OT segmentation.

Multi-site OT security is not a deployment problem. It is an architecture choice. Deploy the right pattern once, and every additional site is a one-day operation instead of a six-week project.

For more Zero Trust OT resources, architecture guides, and comparisons, visit the Zero Trust for OT Networks hub.