The foundations of traditional site-to-site connectivity - IPsec tunnels between trusted sites, MPLS circuits with implicit trust, SD-WAN overlays with broad policy - predate Zero Trust by decades. All three assume that once a site authenticates and its tunnel comes up, traffic flowing through it inherits that trust.

That assumption fails in production. Tunnels become attack propagation paths when one side is compromised: a branch breach moves laterally to headquarters through the very tunnel meant to constrain it. Threat actors target site-to-site connectivity specifically, because implicit trust turns a foothold at either endpoint into broad access.

Why the traditional patterns fail

IPsec authenticates at establishment, then encrypts everything between the sites. Encryption protects traffic in transit; it enforces nothing about what should be allowed to flow.

MPLS provides provider-managed connections with committed performance. Enforcement happens at the gateway interfaces, not within the path - sites on the same service trust each other implicitly.

SD-WAN consolidates transports under centralized policy, a genuine operational improvement over IPsec mesh. But that policy usually operates on IPs, protocols, and ports rather than identity, so the implicit trust between sites remains.

The common failure: traffic between authenticated sites is treated as legitimate because it arrived through an authenticated path.

What changes under Zero Trust

Identity is cryptographically attested, not asserted. Sites prove identity through workload identity frameworks like SPIFFE/SPIRE, cloud provider attestation, or hardware-backed identities - not pre-shared keys.

Traffic carries identity attribution. Each flow carries identity that policy evaluates, and audit traces back to the originating workload rather than to the site that hosted it.

Policy operates on workloads, not subnets. Rules express what workloads may reach what other workloads, and follow those workloads as they move or scale between sites.

Verification is continuous. Each operation is evaluated against current policy, not against an authorization from when the tunnel came up days ago. Changes take effect immediately rather than at renegotiation.

Implementations typically run over TLS 1.3 rather than network-layer IPsec: identity attribution at the application layer is more granular, the cryptographic protection is equivalent for this use case, and the traffic pattern works across any transit network.

The architectural patterns

Identity-based gateway authentication. Each site's gateway identity is rooted in a trust anchor - a certificate authority, cloud attestation service, or HSM - that peers verify cryptographically. Connections establish only after mutual verification, with proofs refreshed on a cadence rather than persisting indefinitely.

Workload identity propagation. Workloads behind each gateway carry their own identities, so when a workload at site A talks to one at site B, policy evaluates the actual workload rather than just its site of origin.

Microsegmentation across site boundaries. Traditional connectivity collapses policy into "site A can reach site B." Microsegmentation expresses it as "the order processing workload at site A can read the inventory database at site B" - the same workload-to-workload policy applied locally, extended geographically.

Where this applies

Branch to headquarters - lateral movement from a compromised branch becomes structurally impossible, because each flow requires authorization instead of inheriting branch-level trust. Datacenter to datacenter - replication and failover continue unchanged, but the flows are identity-attributed. Hybrid and multi-cloud - the same workload identity model applies over Direct Connect, ExpressRoute, or Interconnect, regardless of which cloud the workload runs in. IT to OT - identity-attributed connectivity with content inspection preserves the separation a diode provides while still supporting firmware updates, vendor maintenance, and telemetry.

How the approaches compare

Trust model. IPsec, MPLS, and SD-WAN grant trust at site or overlay level; Zero Trust verifies per flow, which is why lateral movement is structurally prevented rather than merely monitored.

Policy granularity. Subnet-to-subnet, site-to-site, or application-aware in some SD-WAN implementations - versus workload-to-workload at operation level.

Audit attribution. Traditional approaches attribute to a source IP and tunnel ID. Zero Trust attributes to the originating workload - the difference between knowing a connection came from the branch and knowing which workload made it.

These are not always alternatives. Mature SD-WAN deployments often extend with Zero Trust rather than being replaced, keeping the transport consolidation while adding the security properties.

Deployment

Expect six to eighteen months, driven mainly by site count. Start with architecture design and identity infrastructure - gateways cannot authenticate until it is operational. Deploy a first site pair to validate the design against production-like traffic, then extend in tranches with legacy connectivity running in parallel, each site cutting over on its own schedule. Refine policy from site level toward workload level once the foundation is stable; that is where the benefit over traditional patterns actually appears. Decommission legacy last - usually the longest phase, because organizations keep the old path as fallback.

How truePass implements it

Reverse Access™ foundation. Site gateways establish outbound connections over TLS on port 443 rather than accepting inbound connections from peers. The inbound listener attack surface that VPN concentrators present disappears entirely - connectivity operates with no exposed service on either side.

Site and workload identity. Gateways authenticate cryptographically; workloads behind them propagate their identities through the connection, and policy evaluates both for every operation crossing the boundary.

One policy framework, one deployment pattern. The same framework governs user-to-application access, workload-to-workload segmentation, and site-to-site connectivity - and the same pattern applies whether sites are on-premises datacenters, cloud regions, branch offices, or partner sites.

Frequently asked questions

How does this differ from IPsec VPN?

IPsec authenticates at tunnel establishment and trusts everything afterwards; Zero Trust authenticates per flow and per operation. IPsec expresses policy in subnets and ports; Zero Trust expresses it in workload identities and attributes.

Is SD-WAN an alternative or a complement?

Usually a complement. SD-WAN delivers transport consolidation and centralized management; Zero Trust adds identity attribution and workload-level granularity on top.

Does it suit OT and industrial environments?

Yes. Identity-attributed traffic, content inspection on files crossing the boundary, and microsegmentation between IT and OT provide the security properties industrial environments need while supporting the operational connectivity distributed OT actually requires.

Conclusion

Site-to-site Zero Trust replaces the implicit trust that IPsec, MPLS, and SD-WAN depend on with identity-attributed, continuously verified traffic between sites. It addresses the risk those approaches structurally cannot prevent - the recurring pattern where a foothold at one site becomes access to every other.

The path forward starts with architecture design and identity infrastructure, then a first site pair, planned expansion, and legacy decommissioning as the new architecture matures.