Why Site-to-Site Connectivity Needs a Zero Trust Approach

Network Security Engineers responsible for site-to-site connectivity face a recurring tension. The architectural foundations of traditional site-to-site connectivity – IPsec VPN tunnels between trusted sites, MPLS circuits with implicit trust, SD-WAN overlays with broad policy enforcement – predate Zero Trust security models by decades. These foundations assume that once a remote site authenticates and establishes its tunnel, traffic flowing through that tunnel inherits the trust of the established connection.

The assumption fails in 2026 production environments. Site-to-site tunnels become attack propagation paths when one side is compromised. Branch network compromises move laterally to headquarters through the very tunnel that should have constrained them. Compromised cloud infrastructure attacks on-premises systems through the site-to-site connectivity that connected the environments in the first place. Threat actors specifically target site-to-site connectivity because the implicit trust model gives them broad access once they establish a foothold at either endpoint.

Site-to-site Zero Trust connectivity replaces the implicit trust between sites with identity-attributed, attribute-evaluated, continuously verified inter-site traffic. The architectural shift produces dramatically different security properties than traditional approaches while supporting the same operational connectivity that branch networks, datacenter-to-datacenter replication, hybrid cloud integration, and multi-cloud architectures actually require.

This guide documents the architectural patterns, protocol-level implementations, deployment scenarios, and operational realities of site-to-site Zero Trust connectivity. The audience is Network Security Engineers, network architects, and security engineering teams responsible for designing, deploying, and operating inter-site connectivity in enterprise, federal, and critical infrastructure environments. The objective is practical technical guidance for moving from traditional site-to-site approaches to identity-attributed Zero Trust patterns without disrupting operational continuity.

How Traditional Site-to-Site Connectivity Works (and Why It’s Failing)

Three architectural patterns dominate traditional site-to-site connectivity. Each has well-documented strengths; each carries assumptions that conflict with Zero Trust principles.

IPsec VPN tunnels establish encrypted point-to-point connections between site gateways. The tunnels authenticate at establishment (typically with pre-shared keys or certificate-based mutual authentication), encrypt all traffic flowing between sites, and provide a logical broadcast domain extension. Once established, the tunnel becomes a trusted path – packets crossing the tunnel inherit the authentication that occurred at tunnel setup. The encryption protects traffic in transit; it provides no enforcement of what should be allowed to flow.

MPLS (Multi-Protocol Label Switching) circuits provide dedicated provider-managed connections between sites. The provider commits performance characteristics (bandwidth, latency, packet loss) and provides logical separation between customers. MPLS predates internet-scale security threats and operates on implicit trust between sites connected by the same MPLS service. Security enforcement happens at the gateway interfaces, not within the MPLS path.

SD-WAN overlays consolidate site-to-site connectivity across multiple underlying transports (MPLS, internet, LTE) with centralized policy management. SD-WAN improves operational management compared to IPsec mesh deployments and adds policy enforcement at the overlay layer. But SD-WAN policy typically operates on traditional network attributes – source/destination IPs, protocols, ports – rather than identity attributes. The implicit trust between sites remains.

The common failure pattern across all three: traffic flowing between authenticated sites is treated as legitimate because it arrived through an authenticated path. Network Security Engineers responding to incidents repeatedly observe attackers leveraging this assumption – establishing footholds at one site, then moving laterally through site-to-site connectivity to access resources at other sites. The site-to-site connectivity that enabled normal operations becomes the attack propagation infrastructure.

The architectural shift away from this pattern – moving from network-trust models to identity-attribute models – applies the same Zero Trust principles to inter-site connectivity that organizations have applied to remote user access. The foundational pattern of the move from perimeter-based to identity-based access in network architectures extends naturally from user-to-application scope into site-to-site scope.

What Site-to-Site Zero Trust Connectivity Means

Site-to-site Zero Trust connectivity inverts the trust model that traditional approaches depend on. The core principles:

Site identity is cryptographically attested, not asserted. Rather than authenticating sites through pre-shared keys or simple certificate exchange, sites prove their identity through cryptographic attestation – typically through workload identity frameworks like SPIFFE/SPIRE, cloud provider identity attestation (AWS IAM Roles Anywhere, Azure Managed Identities, GCP Workload Identity Federation), or hardware-based attestation (TPM/HSM-backed identities).

Traffic carries identity attribution, not just routing information. Each packet, flow, or session crossing the inter-site connection carries identity information that policy can evaluate. The identity follows the traffic rather than being inferred from the source network. Audit attribution traces back to the originating workload identity, not to the site that hosted the workload.

Policy operates on workload identities and attributes, not network locations. Site-to-site policy expressions reference what workloads can communicate with what other workloads under what conditions – not which subnets can reach which subnets. The policy follows workloads as they move between sites, scale, or replicate.

Continuous verification replaces session-establishment trust. Each operation across the inter-site connection is evaluated against current policy state – not against authorization that occurred when the tunnel was established hours or days earlier. Policy changes apply immediately rather than requiring re-establishment of underlying tunnels.

The data plane separates from the control plane structurally. Identity attestation, policy distribution, and audit telemetry flow through control plane infrastructure independent of the data plane carrying production traffic. This separation enables policy enforcement that doesn’t compromise data plane performance. The architectural pattern of control plane and data plane separation in modern Zero Trust deployments provides the foundation that site-to-site Zero Trust extends across geographic boundaries.

The implementation typically uses application-layer protocols (HTTPS over TLS 1.3) for both control and data planes rather than network-layer IPsec. This choice reflects the architectural priorities: identity attribution at the application layer is more granular than network-layer association, modern TLS provides equivalent or better cryptographic protection than IPsec for the use case, and HTTPS traffic patterns blend with general internet traffic for transit network compatibility.

Core Architectural Patterns for Site-to-Site Zero Trust Deployment

The architectural patterns that produce site-to-site Zero Trust connectivity organize into five categories. A complete deployment typically uses several of these patterns in combination.

Pattern 1: Identity-Based Site Gateway Authentication. Each site deploys a gateway component that establishes its identity through cryptographic attestation rather than through pre-shared secrets. The gateway identity is rooted in a trust anchor (a certificate authority, cloud provider attestation service, or hardware security module) that allows peer sites to verify the identity cryptographically. Site-to-site connections establish only after both sides verify each other’s identity through this attestation, with the identity proof refreshed on a defined cadence rather than persisting indefinitely.

Pattern 2: Workload Identity Propagation Across Sites. Workloads behind each site gateway carry their own cryptographic identities – typically using SPIFFE/SPIRE for cloud-native deployments, X.509 client certificates for legacy deployments, or platform-native identity attestation (IRSA, Managed Identities). When workloads at site A communicate with workloads at site B, the originating workload’s identity propagates with the traffic, allowing policy evaluation at the destination site based on the actual workload identity rather than just the source site.

Pattern 3: Application-Layer Policy Enforcement. Inter-site traffic flows through policy enforcement points that evaluate application-layer attributes – HTTP methods, API endpoints, GraphQL queries, gRPC procedures – not just network-layer attributes. The policy can distinguish between a database read query and a schema modification, between an API GET and POST, between approved file types and prohibited ones, between operations during business hours versus off-hours. The granularity matches actual security requirements rather than approximating them through network rules.

Pattern 4: Microsegmentation Across Inter-Site Boundaries. Traditional site-to-site connections collapse inter-site policy into “Site A can reach Site B” decisions. Microsegmentation patterns express policy at workload-to-workload granularity even across sites – “the order processing workload at Site A can reach the inventory database at Site B for read operations only.” The architectural foundation for this pattern is identity-based microsegmentation that extends across geographic and cloud boundaries, allowing site-to-site connectivity to enforce the same workload-to-workload policies that intra-site microsegmentation enforces locally.

Pattern 5: Continuous Re-Verification of Inter-Site Authorization. Site-to-site authorization isn’t a one-time event at tunnel establishment. The connection re-evaluates authorization on a continuous basis – short-lived tokens that refresh, policy state that updates immediately rather than at tunnel renegotiation, anomaly detection that can revoke specific flows without affecting other site-to-site traffic. This continuous verification enables rapid response to detected threats without disrupting overall site connectivity.

Site-to-Site Zero Trust Deployment Scenarios

The architectural patterns above support six common deployment scenarios that Network Security Engineers encounter in 2026 environments:

Scenario 1: Branch-to-Headquarters Connectivity. Enterprise organizations operating branch networks (retail locations, regional offices, manufacturing sites) replace MPLS or IPsec-based branch connectivity with identity-attributed site-to-site Zero Trust. Each branch deploys a small gateway that authenticates to the HQ infrastructure cryptographically. Branch users and devices access headquarters resources through identity-attributed flows rather than through general branch network access. Lateral movement from a compromised branch becomes structurally impossible because individual flows require identity authorization rather than relying on branch-level trust.

Scenario 2: Datacenter-to-Datacenter Replication. Organizations operating multiple datacenters (typical for financial services, government, and large enterprise) require continuous replication, failover capability, and cross-site coordination. Site-to-site Zero Trust patterns secure this inter-datacenter traffic with identity-attributed flows that preserve required replication relationships while preventing the lateral propagation that previous IPsec-based replication tunnels enabled.

Scenario 3: Cloud-to-On-Premises Hybrid Connectivity. Hybrid cloud deployments require connectivity between cloud-hosted workloads and on-premises systems. The traditional pattern uses AWS Direct Connect, Azure ExpressRoute, or GCP Interconnect with IPsec or MACsec encryption. The Zero Trust pattern adds identity attribution and application-layer policy to this connectivity, allowing fine-grained control over what cloud workloads can access what on-premises systems through workload-identity-based policy rather than IP-based access control lists.

Scenario 4: Multi-Cloud Site Connectivity. Organizations running workloads across AWS, Azure, and GCP face inter-cloud connectivity challenges that IPsec-based approaches handle awkwardly. Site-to-site Zero Trust patterns provide cloud-agnostic policy that operates consistently across AWS Transit Gateway, Azure Virtual WAN, GCP Cloud Interconnect, and direct cloud-to-cloud connectivity. The same workload identity model applies regardless of which cloud the workload runs on.

Scenario 5: IT-to-OT Site Connectivity. Industrial environments where OT/SCADA systems operate at separate sites from IT infrastructure require careful inter-site connectivity. Traditional approaches use data diodes or one-way connectivity that prevents IT-to-OT attacks but also prevents legitimate operational connectivity (firmware updates, vendor maintenance, operational telemetry). Site-to-site Zero Trust patterns enable bidirectional connectivity with content inspection and identity attribution – preserving the security properties that diodes provide while supporting operational connectivity requirements. The pattern of outbound-only HTTPS architecture for OT network connectivity provides the architectural foundation that extends across geographic boundaries for distributed OT operations.

Scenario 6: Coalition and Partner Site Connectivity. Defense, intelligence, and law enforcement organizations frequently need to establish temporary or semi-permanent connectivity with coalition partners, allied organizations, or trusted external entities. Traditional approaches require manual VPN configuration and shared credentials. Site-to-site Zero Trust patterns enable federated identity attestation that allows partner sites to establish connectivity with appropriate identity verification, time-bounded authorization, and audit attribution to specific partner personnel rather than shared site credentials.

Comparison: IPsec VPN vs SD-WAN vs Site-to-Site Zero Trust Connectivity

Network Security Engineers evaluating site-to-site approaches need clear understanding of how the alternatives compare. The table below examines the architectural and operational characteristics of each approach:

Characteristic	IPsec VPN	MPLS	SD-WAN	Site-to-Site Zero Trust
Trust model	Implicit between authenticated sites	Implicit between connected sites	Implicit between overlay members	Explicit per-flow identity verification
Identity primitive	Site identity (pre-shared key or cert)	Provider circuit assignment	Site identity in overlay	Workload identity propagated with traffic
Policy granularity	Subnet-to-subnet	Site-to-site	Application-aware in some implementations	Workload-to-workload at operation level
Encryption	IPsec ESP (typically AES-256)	None (provider isolation) or MACsec	Varies by transport	TLS 1.3 with mutual authentication
Lateral movement risk	High (tunnel-wide trust)	High (site-wide trust)	Medium (overlay policy)	Structurally prevented
Policy update mechanism	Manual tunnel reconfiguration	Provider service order	SD-WAN controller push	Immediate policy distribution
Audit attribution	Source IP and tunnel ID	Site identifier	Source IP and policy ID	Workload identity at source
Multi-cloud consistency	Per-cloud VPN configuration	Limited cloud integration	Cloud-aware overlays	Cloud-agnostic policy
Encryption performance	Hardware-accelerated typical	Provider-managed	Varies	TLS 1.3 efficient on modern hardware
Operational complexity	Mesh complexity at scale	Provider managed	Centralized overlay management	Centralized identity and policy
Failover characteristics	Manual reconfiguration	Provider SLA dependent	Automatic in mature SD-WAN	Continuous re-authorization handles failover
Suitable for hybrid cloud	Awkward at scale	Limited cloud connectivity	Strong cloud support	Cloud-native and on-premises consistent
Suitable for OT/critical infrastructure	Architecturally acceptable	Strong	Variable	Strong with content inspection
Migration from legacy	Drop-in replacement	Provider lock-in	Overlay coexists with legacy	Parallel deployment alongside legacy

The comparison reveals different patterns suit different organizational situations. Organizations with mature SD-WAN deployments may extend their SD-WAN with Zero Trust capabilities rather than replacing it. Organizations operating IPsec mesh networks at scale typically benefit from Zero Trust migration because mesh complexity has reached operational limits. Organizations building new architectures typically adopt site-to-site Zero Trust from the start rather than deploying legacy patterns they’ll need to migrate later.

Architectural Risks That Site-to-Site Zero Trust Specifically Addresses

The shift to site-to-site Zero Trust connectivity isn’t primarily about modernization – it’s about addressing specific risk patterns that traditional architectures structurally cannot prevent. Network Security Engineers evaluating the deployment should understand which risks the architectural shift addresses.

The lateral movement risk represents the most significant gain. Traditional IPsec tunnels and MPLS circuits enable lateral movement from one site to another by design – the tunnel exists specifically to allow traffic to flow between sites. When an attacker establishes a foothold at any site connected through traditional site-to-site infrastructure, the connectivity becomes an attack vector. Identity-attributed site-to-site Zero Trust changes this fundamental property – connectivity exists at the workload level rather than the site level, and the architectural pattern of preventing lateral movement through identity-based controls applies consistently across inter-site connections.

Beyond lateral movement, site-to-site Zero Trust addresses inbound attack surface reduction. Traditional site-to-site tunnels require inbound listeners on at least one side – typically both sides – for tunnel establishment. These listeners create attack surface that vulnerability scanners probe and that exploits target. Outbound-only Zero Trust patterns eliminate this listener category, removing the structural vulnerability that affected commercial site-to-site products throughout 2023-2025.

The architectural shift also addresses the operational risk of stale policy. Traditional site-to-site configurations require explicit re-deployment when policy changes – new firewall rules, modified ACLs, updated tunnel parameters. The reconfiguration window during which old policy continues to apply creates risk. Site-to-site Zero Trust patterns distribute policy continuously, making changes effective immediately across all site-to-site connections.

Implementation Approach for Network Security Engineers

The implementation pattern that produces successful site-to-site Zero Trust deployments follows a structured sequence. Network Security Engineers should expect 6-18 months total deployment time depending on environment complexity:

Phase 1: Architecture Design and Planning (4-8 weeks). Document the current site-to-site connectivity architecture. Identify all sites, the connectivity patterns between them, and the workloads at each site. Map the identity infrastructure that will provide site and workload identities. Design the policy framework that will replace network-based site-to-site policy. Identify the gateway components that will be deployed at each site.

Phase 2: Identity Infrastructure Preparation (4-12 weeks). Establish the cryptographic identity infrastructure that will support site and workload identities. This may involve deploying a certificate authority, integrating with existing PKI, configuring SPIFFE/SPIRE infrastructure for cloud-native workloads, or integrating with cloud-provider identity services. The identity infrastructure must be operational before site gateways can authenticate.

Phase 3: First Site Pair Deployment (6-12 weeks). Deploy site gateways at two sites and establish identity-attributed connectivity between them. This first deployment validates the architectural design with actual production-like traffic. Monitor performance characteristics, debug integration issues, refine policy expressions, and document operational procedures.

Phase 4: Expanded Site Deployment (12-24 weeks). Extend site-to-site Zero Trust to additional sites in phased expansion. Sites typically migrate in tranches based on operational priority, complexity, and dependencies on other sites. The existing IPsec or SD-WAN infrastructure remains operational throughout the migration, with each site cutting over from legacy connectivity to Zero Trust patterns on its own schedule.

Phase 5: Workload-Level Policy Refinement (8-16 weeks). Once the inter-site connectivity foundation is operational, refine policy from site-level toward workload-level granularity. Specific workload-to-workload flows that were previously aggregated under site-to-site rules become individually expressed and audited. This phase produces the operational benefit of Zero Trust patterns over traditional patterns.

Phase 6: Legacy Decommissioning (12-24 weeks). Once all sites have migrated to Zero Trust connectivity and workload-level policy is operational, the legacy IPsec or SD-WAN infrastructure can be decommissioned. The legacy decommissioning is typically the longest phase because organizations preserve legacy infrastructure as fallback for extended periods.

Network Engineering Considerations for Site-to-Site Zero Trust

Network Security Engineers planning site-to-site Zero Trust deployment encounter several engineering considerations that affect both design and operations:

Routing implications. Traditional site-to-site connectivity often integrates with internal routing protocols (BGP, OSPF, EIGRP) – advertised routes determine traffic paths. Site-to-site Zero Trust typically uses application-layer routing rather than network-layer routing. The routing implication: existing routing tables may not directly reflect the new connectivity patterns. Plan for either parallel routing tables during migration or routing redesign as part of the deployment.

MTU and fragmentation considerations. TLS 1.3 over TCP doesn’t have the MTU sensitivity that IPsec ESP often introduces. Path MTU discovery operates normally. The operational issue of IPsec fragmentation that traditional deployments often manage (DF-bit handling, MTU manual configuration on tunnel interfaces) typically doesn’t apply to TLS-based site-to-site connectivity.

Performance characteristics. TLS 1.3 with hardware acceleration on modern systems produces throughput comparable to IPsec on equivalent hardware. CPU overhead is similar. Latency characteristics depend more on the path between sites than on the encryption protocol. Network Security Engineers used to IPsec performance tuning will find similar concepts apply but with different specific tuning parameters.

Failover and resilience. Site-to-site Zero Trust supports active-active and active-passive failover patterns. The control plane distributes policy and identity state to multiple endpoints; the data plane uses the available endpoints based on policy and health. Failover characteristics typically improve compared to IPsec because the architectural pattern doesn’t depend on stateful tunnel re-establishment.

Monitoring and observability. Site-to-site Zero Trust generates richer telemetry than traditional IPsec or SD-WAN – identity attribution per flow, policy decisions per operation, performance metrics at the application layer. Integration with existing network monitoring tools (NMS, NetFlow collectors, SIEM) typically requires configuration to consume the richer telemetry. The operational benefit is meaningful visibility into inter-site traffic that traditional approaches couldn’t provide.

Troubleshooting workflows. When site-to-site issues arise, troubleshooting workflows shift from network-layer focus (tunnel state, encryption parameters, routing) toward application-layer focus (identity verification, policy decisions, application protocol issues). Network Security Engineers familiar with TLS troubleshooting typically adapt quickly. Engineers used to IPsec-only troubleshooting need to develop application-layer debugging skills.

How TerraZone truePass Implements Site-to-Site Zero Trust

The architectural patterns documented above are implemented in the TerraZone truePass platform with specific design decisions that simplify deployment for Network Security Engineers:

Reverse Access foundation for site connectivity. Site gateways establish outbound HTTPS connections to TerraZone gateway infrastructure rather than accepting inbound connections from peer sites. The architectural property eliminates the inbound listener attack surface that traditional site-to-site VPN concentrators present. Site-to-site connectivity operates without exposed services on either side.

Identity-based site and workload identities. Site gateways authenticate cryptographically using TerraZone’s identity framework. Workloads behind each gateway carry identities propagated through the connection. Policy evaluates both site identity and workload identity for each operation crossing the inter-site connection.

Unified policy across user access, workload access, and site connectivity. The same policy framework that governs user-to-application access (ZTNA) governs workload-to-workload access (microsegmentation) and site-to-site connectivity. Network Security Engineers managing the deployment work with one policy framework rather than three. The Zero Trust Access service that provides this unified policy framework is implemented through the truePass Zero Trust Access platform component, which extends consistently across all three access scopes.

Multi-site, multi-cloud, hybrid deployment patterns. The same architectural pattern applies whether sites are on-premises datacenters, cloud regions, branch offices, or partner sites. Network Security Engineers deploy one platform pattern across all site types rather than maintaining different products for cloud connectivity versus on-premises connectivity versus partner connectivity.

For Network Security Engineers evaluating the comprehensive platform capabilities and the specific site-to-site deployment patterns the platform supports, the truePass platform documentation provides the technical foundation that supports architecture discussions, control mapping exercises, and engineering planning conversations.

Implementation Checklist for Network Security Engineers

The checklist below organizes the deployment work that Network Security Engineers actually execute during site-to-site Zero Trust deployment:

Pre-Deployment Phase:

• Document all site-to-site connectivity in current architecture
• Identify all workloads at each site requiring inter-site connectivity
• Map identity infrastructure that will support site and workload identities
• Identify gateway deployment locations at each site (physical or virtual)
• Plan IP addressing and routing implications
• Develop initial policy framework expressing inter-site connectivity intent
• Coordinate with security team for policy review
• Coordinate with operations team for change management

Identity Infrastructure Phase:

• Establish or extend certificate authority for site identities
• Configure SPIFFE/SPIRE or equivalent for cloud-native workloads
• Integrate with cloud provider identity services (AWS Roles Anywhere, Azure Managed Identities)
• Configure identity propagation patterns from existing IdP
• Validate identity attestation flows in test environment
• Document identity rotation procedures

Gateway Deployment Phase:

• Deploy gateway infrastructure at primary sites
• Configure outbound connectivity to platform control plane
• Validate gateway-to-control-plane connectivity
• Establish first site pair Zero Trust connection
• Validate identity attestation between paired sites
• Test traffic flow through policy enforcement
• Measure performance characteristics versus baseline

Migration Phase:

• Run Zero Trust connectivity in parallel with existing IPsec/MPLS/SD-WAN
• Migrate specific workload flows to Zero Trust path
• Monitor for unexpected traffic patterns
• Iterate on policy expressions based on observed flows
• Cut over additional sites in planned tranches
• Validate failover behavior in controlled tests

Operations Phase:

• Integrate platform telemetry with existing SIEM/NMS
• Establish monitoring dashboards for site-to-site health
• Develop runbooks for common troubleshooting scenarios
• Train operations team on Zero Trust troubleshooting workflows
• Document incident response procedures for site-to-site issues
• Establish policy review cadence

Decommissioning Phase:

• Verify all required flows traverse Zero Trust path
• Reduce legacy infrastructure to standby
• Validate operational continuity over extended observation period
• Decommission legacy gateway infrastructure
• Update network documentation to reflect final architecture
• Close out related operational accounts and contracts

Frequently Asked Questions

What is site-to-site Zero Trust connectivity?

Site-to-site Zero Trust connectivity is a network architecture pattern that provides inter-site connectivity (branch-to-HQ, datacenter-to-datacenter, cloud-to-on-premises, etc.) with identity-attributed traffic, attribute-based policy enforcement, and continuous verification – rather than the implicit trust model that traditional IPsec VPN, MPLS, and SD-WAN approaches use. Each site authenticates cryptographically. Workloads behind each site propagate their identities through the connection. Policy operates on workload identities and attributes rather than network locations. The pattern produces dramatically different security properties than traditional site-to-site connectivity while supporting the same operational requirements.

How does site-to-site Zero Trust differ from IPsec VPN?

IPsec VPN authenticates at tunnel establishment and then trusts all traffic flowing through the established tunnel. Site-to-site Zero Trust authenticates per-flow and per-operation, with policy evaluation continuous rather than session-establishment-only. IPsec encrypts at the network layer (ESP); Zero Trust typically encrypts at the application layer (TLS 1.3). IPsec policy operates on subnets and ports; Zero Trust policy operates on workload identities and attributes. The architectural shift addresses the lateral movement risk that IPsec architecturally cannot prevent.

What is the difference between SD-WAN and site-to-site Zero Trust?

SD-WAN provides centralized policy management for site-to-site connectivity across multiple underlying transports. Site-to-site Zero Trust extends the architectural shift further: identity-attributed traffic, application-layer policy enforcement, workload-level (not just site-level) granularity, and continuous verification. SD-WAN and Zero Trust are not necessarily alternatives – mature SD-WAN deployments often extend with Zero Trust capabilities rather than replacing the SD-WAN entirely. The combination provides the operational consolidation that SD-WAN delivers plus the security properties that Zero Trust delivers.

Can site-to-site Zero Trust replace MPLS?

Site-to-site Zero Trust can replace MPLS for many use cases – particularly where the MPLS deployment exists primarily for site connectivity rather than for performance guarantees. Organizations using MPLS for guaranteed bandwidth and latency may continue using MPLS as the underlying transport while adding Zero Trust patterns at the application layer. Organizations using MPLS primarily for connectivity often achieve cost savings and improved security through Zero Trust migration off MPLS to internet-based connectivity with Zero Trust overlay.

How long does site-to-site Zero Trust deployment take?

Typical deployments run 6-18 months from initial architecture planning to legacy infrastructure decommissioning. The variation depends primarily on the number of sites (10 sites versus 1,000 sites makes a substantial difference), the complexity of existing connectivity patterns, and the operational continuity requirements during migration. Most deployments follow phased patterns: 4-8 weeks of planning, 4-12 weeks of identity infrastructure preparation, 12-24 weeks of expanding deployment, and 12-24 weeks of legacy decommissioning operating in parallel with continued operations.

What identity infrastructure is required for site-to-site Zero Trust?

Site-to-site Zero Trust requires identity infrastructure for both site gateways and workloads behind those gateways. Site identity typically uses certificates issued by an organizational certificate authority – either an existing PKI or new infrastructure deployed specifically for the Zero Trust deployment. Workload identity uses SPIFFE/SPIRE for cloud-native workloads, X.509 client certificates for legacy workloads, or cloud-provider identity attestation (AWS IAM Roles Anywhere, Azure Managed Identities, GCP Workload Identity) for cloud workloads. Most organizations integrate with existing identity providers (Okta, Microsoft Entra, Ping) for human user identity that flows through the deployment.

How does site-to-site Zero Trust handle failover?

Failover in site-to-site Zero Trust operates at the application layer rather than at the tunnel layer that IPsec uses. Control plane infrastructure distributes policy and identity state to multiple endpoints. Data plane uses available endpoints based on health and policy. When primary connectivity becomes unavailable, traffic shifts to alternate paths immediately because each flow re-authorizes continuously rather than depending on a stateful tunnel that requires re-establishment. The failover characteristics typically improve compared to IPsec-based architectures.

Does site-to-site Zero Trust support OT/industrial environments?

Yes. Site-to-site Zero Trust patterns specifically address IT-to-OT site connectivity requirements that traditional approaches handle awkwardly. The combination of identity-attributed traffic, content inspection for files crossing the boundary, and microsegmentation between IT and OT workloads provides security properties suitable for industrial environments while supporting the operational connectivity (vendor maintenance, firmware updates, operational telemetry) that distributed OT operations require.

Conclusion

Site-to-site Zero Trust connectivity replaces the implicit trust model that IPsec VPN, MPLS, and SD-WAN architectures depend on with identity-attributed, attribute-evaluated, continuously verified inter-site traffic. The architectural shift addresses the lateral movement risk that traditional site-to-site approaches structurally cannot prevent – the recurring pattern where attackers establish footholds at one site, then move laterally through site-to-site connectivity to access resources at other sites.

The implementation pattern documented in this guide produces successful deployments across the six common scenarios that Network Security Engineers encounter: branch-to-HQ, datacenter-to-datacenter, hybrid cloud, multi-cloud, IT-to-OT, and coalition/partner connectivity. The architectural patterns scale from small deployments (single site pair) to large deployments (hundreds or thousands of sites) without requiring fundamentally different approaches at scale.

For Network Security Engineers planning site-to-site Zero Trust deployment, the path forward starts with architecture design and identity infrastructure preparation. The phased implementation approach – first site pair, expanded deployment, workload-level policy refinement, legacy decommissioning – produces predictable progress while preserving operational continuity throughout the migration. The engineering considerations (routing, performance, monitoring, troubleshooting) require adaptation from IPsec-focused workflows but build on engineering skills that Network Security Engineers already possess.

The architectural decision that defines your organization’s site-to-site connectivity for the next decade benefits from the implementation framework this guide provides. Begin with architecture design, validate with controlled first deployments, expand in planned phases, and decommission legacy infrastructure as the new architecture reaches operational maturity. The pattern produces site-to-site connectivity that supports operational requirements while delivering the security properties that traditional approaches structurally cannot provide.