A single-carrier design creates more than a pricing problem. It ties your site reachability, failover options, service changes, and security controls to one provider’s commercial and technical decisions. If that carrier has an outage, changes its terms, or cannot serve a new location, every site in the same dependency chain feels the impact.
The safer pattern is to separate the underlay, which is the transport you buy, from the overlay, which defines who can reach which service. Run the overlay across commodity broadband, cellular 5G, private circuits, and cloud backbones. Then you can change carriers without rebuilding identity, policy, or application reachability.
What are the risks of a single-carrier WAN?
The main risks are concentrated failure, slow change, weak negotiating position, and an architecture that is hard to move. These risks compound when the carrier also supplies the edge hardware, routing policy, security service, and monitoring platform.
1. One commercial decision becomes a technical dependency
A carrier contract can shape your access circuits, CPE, addressing model, support process, and renewal schedule. Replacing one part may require replacing the rest because the services were designed as one bundle.
That dependency makes ordinary decisions expensive. Opening a new branch, adding a cloud region, changing an egress path, or introducing a second provider becomes a carrier project instead of an infrastructure change.
2. An outage can have a larger blast radius
Carrier diversity is not the same as having two circuits from the same carrier. Those circuits can share a last-mile contractor, duct, building entry, metro route, backhaul, or operational process.
Ask what actually fails together. A second access line helps only when it has independent physical and operational dependencies. A second carrier helps more, but only if your routing and security design can use it without manual reconfiguration.
3. Provisioning delays become business delays
New circuits often involve site surveys, construction, installation windows, carrier equipment, and acceptance testing. If every location follows the same path, the slowest provider sets the pace for expansion.
That is different from the question answered in SD-WAN vs MPLS: Faster Site and Cloud Connectivity. This article is about preserving architectural independence after you choose an underlay, not about selecting one WAN technology over another.
4. Price increases are harder to resist
Lock-in weakens your ability to move traffic or services when pricing changes. The cost is not limited to the monthly circuit. It includes migration labor, new edge devices, new support contracts, policy translation, testing, and the risk of service interruption.
5. Security policy can become tied to the transport
Traditional site-to-site designs often express trust through routes, subnets, and firewall zones. If those controls live inside a carrier-managed WAN, moving the transport can also mean redesigning access policy.
That is a poor fit for zero trust. NIST’s Zero Trust Architecture guidance treats network location as an insufficient basis for trust. A portable design should authenticate identities and authorize services independently of the carrier carrying the packets.
What does carrier-independent connectivity mean?
Carrier-independent connectivity means the transport can change without changing the logical access model. The underlay carries encrypted traffic, while an identity-aware overlay decides which endpoints and services can communicate.
The model has four layers:
| Layer | Responsibility | What should remain portable |
|---|---|---|
| Underlay | Internet, 5G, private circuit, or cloud backbone | Provider, access type, and route |
| Edge | Connects a site or workload to the overlay | Device image, enrollment, and policy attachment |
| Overlay | Creates private paths between authorized endpoints | Service names, identity, and reachability rules |
| Policy | Grants least-privilege access | User, device, workload, and service relationships |
The key boundary is between underlay and overlay. A broadband line can replace a private circuit. A 5G connection can provide temporary or backup access. A cloud backbone can carry traffic between workloads. The policy does not need to know which carrier delivered the packet.
The underlay-agnostic zero trust blueprint
An underlay-agnostic design keeps identity and policy above the transport layer, then gives each site a controlled way to join the overlay.
1. Give each endpoint a cryptographic identity
Identify the site router, workload, device, or application endpoint instead of trusting its IP range. Cryptographic identity lets the control plane distinguish two endpoints even when they use overlapping private address space or move between networks.
For workloads, use a workload identity system rather than a shared tunnel credential. For users, connect the access decision to the identity provider and group membership. For unmanaged devices, use an edge connector or gateway that applies policy on the device’s behalf.
The identity should survive a carrier change. If replacing a circuit forces you to re-enroll every workload and rewrite every rule, the design has only moved the lock-in to another layer.
2. Make connections outbound by default
Sites and workloads should establish outbound sessions to the overlay rather than waiting for inbound connections from the public internet. This reduces the need for inbound firewall exceptions and makes the design easier to deploy across customer networks, broadband, and cellular links.
The zero inbound ports architecture guide covers the security pattern in more detail. Here, the important point is portability: an outbound session works across many underlays, while a carrier-specific inbound design often requires a new public address, route, or firewall rule when the transport changes.
3. Publish services, not subnets
Expose a named application service to an authorized identity instead of advertising an entire site’s address space. This limits blast radius and keeps the access decision independent from the carrier’s routing domain.
For example, a warehouse application may need to reach an inventory API in a cloud account. It does not need general access to the cloud VPC, the branch subnet, or every host at the data center. The overlay should express that narrow relationship directly.
This is also why overlay networking for CIDR conflicts is a related but separate concern. Overlays can avoid forcing an immediate readdressing project, but carrier independence still requires identity, policy, and operational ownership above the underlay.
4. Use multiple transports deliberately
Commodity broadband, cellular 5G, private circuits, and cloud-native connectivity each have a place. The goal is not to pretend they have identical performance. The goal is to make the application path resilient when one transport is unavailable or unsuitable.
| Transport | Useful role | Design caution |
|---|---|---|
| Commodity broadband | Primary access for many offices and branches | Performance and repair times vary by location |
| Cellular 5G | Backup, temporary sites, vehicles, and hard-to-wire locations | Coverage, data plans, and indoor signal need validation |
| Private circuit | Predictable capacity for selected workloads | Provisioning and route diversity need verification |
| Cloud backbone | Workload-to-workload paths across cloud regions | Cloud-specific routing can recreate lock-in |
Let the overlay select or accept the available path, but keep the policy stable. A failover test should confirm more than link recovery. It should prove that the same identities can still reach the same approved services through the alternate underlay.
How do you avoid vendor lock-in in network architecture?
Avoiding lock-in requires portability tests, explicit ownership boundaries, and a migration path that works before an emergency. A contract clause alone cannot fix an architecture that depends on proprietary routing or policy objects.
Use this checklist during design and renewal reviews:
- Separate contracts from control. Document which provider supplies transport and which system owns identity, service publication, authorization, telemetry, and configuration.
- Test a second underlay. Connect one site through a different carrier or 5G network. Test normal traffic, failover, enrollment, policy enforcement, and recovery.
- Keep service names stable. Applications should target logical service names, not carrier-specific IP addresses or routes.
- Export policy and identity data. Know how to retrieve configuration, certificates, service definitions, logs, and audit records in usable formats.
- Measure exit work. Estimate the people, time, equipment, and change windows needed to replace the carrier for one site and for the whole estate.
- Check shared dependencies. Review last-mile providers, buildings, ducts, cloud regions, DNS, identity services, and support escalation paths.
- Run a failure exercise. Simulate a carrier outage and a contract termination. The exercise should produce an ordered runbook, not a list of assumptions.
The strongest test is a live migration of a small, non-critical site. If the team can move that site while keeping application names and access policy unchanged, the architecture has a credible exit path.
What should you ask a carrier and overlay provider?
Ask the carrier about physical route independence, repair commitments, CPE ownership, change lead times, data egress, and termination assistance. Ask the overlay provider whether identities, policies, service definitions, and logs remain usable when the underlay changes.
You should also ask where policy is enforced. If it is enforced only in a carrier’s proprietary edge, a new carrier may require a full policy migration. If it is attached to identities and services in an independent overlay, transport changes are less disruptive.
NetFoundry’s OpenZiti project is one example of an identity-based overlay approach. The relevant evaluation is not the brand name. It is whether the architecture can run across the transports you actually use, whether you can operate or replace its components, and whether policy remains independent of carrier routes.
FAQ
What is vendor lock-in in networking?
Vendor lock-in in networking happens when changing a provider requires replacing connected hardware, routing, security policy, management systems, or application addressing at the same time. The practical test is how much of the design must change when one transport provider is removed.
What is carrier diversity?
Carrier diversity means using independent connectivity providers or paths so one provider failure does not remove all access. It only improves resilience when the paths do not share critical physical, cloud, or operational dependencies.
Is multi-carrier WAN enough to avoid lock-in?
No. Multi-carrier WAN improves transport resilience, but it does not by itself make identity, policy, routing, or management portable. You also need an overlay and operating model that can use the alternate carrier without rebuilding access rules.
What is redundant internet connectivity?
Redundant internet connectivity uses two or more independent paths to maintain access when one path fails. Test the complete service path, including overlay enrollment, identity checks, DNS, policy enforcement, and application reachability, rather than testing link status alone.
Can 5G replace a private circuit for every site?
No. 5G can work well for backup, temporary locations, mobile deployments, and sites where wired service is difficult. Capacity, coverage, latency, data limits, and indoor signal determine whether it fits a particular workload.
How does zero trust reduce carrier dependence?
Zero trust moves the access decision from network location to verified identity, device or workload context, and explicit service policy. That lets the transport change while the authorized relationship stays the same, provided the overlay supports both paths.
What is the first step toward carrier independence?
Map every dependency that the current carrier controls, then connect one low-risk site to a second underlay. Keep the same service names and access policies during the test. The results will show whether your architecture is actually portable.
Related articles
- SD-WAN vs MPLS: Faster Site and Cloud Connectivity
- How to Achieve Zero Inbound Ports
- Overlay Networking for CIDR Conflicts
- How to Replace a Site-to-Site VPN Without Network Changes
Sources & References
- NIST SP 800-207: Zero Trust Architecture – identity and policy principles
- NIST SP 800-207A: Cloud-Native Zero Trust Architecture – multi-cloud access model
- CISA Zero Trust Microsegmentation Guidance – segmentation and blast-radius guidance
- AWS Hybrid and Multi-Cloud Networking Best Practices – multi-cloud connectivity considerations
- OpenZiti – identity-based overlay project