How should teams replace VPN and MPLS dependencies without weakening access control in a global environment?

Why zero trust connectivity is the cleanest replacement for VPN and MPLS

The core shift is from network-level trust to path-level authorization. Instead of making a site, user, or workload broadly reachable once it joins the private network, teams should make each connection explicit, authenticated, and narrowly scoped. That matters in global environments because the replacement must preserve reachability without recreating the same wide trust zone in a different form.

A useful way to think about the change is to replace “connected to the network” with “allowed to reach this service for this purpose.” That means separating transport from privilege: the connectivity layer carries traffic, but the policy layer decides whether the request is allowed. In practice, this is where zero trust connectivity overlaps with NIST SP 800-207 Zero Trust Architecture, because the objective is to reduce implicit trust and enforce least-privilege access decisions at the boundary of each application interaction.

This is also why the design has to cover users, branches, cloud workloads, and third parties together. If one population still gets broad network reach, the environment inherits the same blast radius problem VPNs and MPLS often created. A strong migration design should therefore treat remote access, site-to-site access, and application access as one policy problem rather than three separate network projects. The Remote Access Identity Guide is useful here because it ties VPN replacement to MFA, ZTNA, device posture, and dormant access cleanup. In the same vein, Authorisation Models Guide helps teams reason about how policy should differ by role, attribute, relationship, or context instead of by network location alone.

What changes in access control when the network is no longer the control plane

When VPN or MPLS is the primary gate, the network often becomes a proxy for trust. That is convenient, but it is also coarse. Once a user or site is inside, segmentation and internal controls have to do the rest of the work. Zero trust connectivity inverts that model by making the access decision explicit before the connection is useful, then limiting the connection to the specific service or resource needed.

For practitioners, the important consequence is that identity, device posture, and policy evaluation become first-class enforcement points. A branch router, remote laptop, contractor endpoint, or cloud workload should not gain a general route table just because it is authenticated once. Instead, the system should evaluate who or what is connecting, what resource is being requested, and whether the context is acceptable at that moment. That is why access control design and connectivity design have to converge. The principle is consistent with OAuth 2.0 Authorization Framework style audience scoping and with RFC 8707, which constrains tokens to a specific resource rather than letting them roam across an entire trust domain.

For services and workloads, the same logic means replacing implicit network adjacency with explicit service authorization. That usually requires tighter inventory, clearer service ownership, and stronger entitlement boundaries than a traditional network team may have maintained. IAM and IGA Basics is relevant because the migration often fails when entitlement reviews, application ownership, and joiner-mover-leaver processes are not aligned with the new access model.

How to migrate without creating a hidden trust gap

The hardest part of the transition is not replacing the tunnel technology, it is avoiding a period where the old broad trust is gone but the new fine-grained policy is incomplete. That usually happens when teams cut over connectivity before they have mapped application dependencies, defined per-service authorization, or validated break-glass paths. In a global environment, those gaps can surface as intermittent access failures, overbroad exceptions, or a quiet return to “temporary” network-wide access that never gets removed.

• Start with a service inventory that identifies the minimum required source, destination, and user or workload context for each application path.
• Move the most sensitive systems first so policy testing proves the model before broad rollout.
• Keep legacy VPN or MPLS only where it is required for specific transitional use cases, then retire those paths with a dated exception process.
• Measure whether access is being granted by policy, not by fallback rules or inherited network reachability.

A migration is usually healthy when the default answer is “no” unless the request is explicitly permitted, and unhealthy when teams keep adding global routes because the policy model is not ready. If you need a practical governance reference for that stage, Privileged Access Management Guide is useful where admin paths, break-glass access, and standing privilege intersect with the new connectivity layer. For cloud and distributed estates, CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management both reinforce the need to control access, manage accounts, and keep privileged pathways tightly governed.

Practitioner Guidance

What to prioritise: Define the policy boundary before changing the transport. If the new model cannot clearly answer “who or what may reach which service, from where, under what conditions,” it is not yet a replacement for VPN or MPLS.

What to verify: Confirm that every critical application has a tested path for identity-based access, including remote users, branches, third parties, and cloud workloads. Also verify that failure modes are explicit, because “just route around it” is the old pattern you are trying to eliminate.

Common mistake: Teams often keep one broad fallback network path for convenience, then allow that exception to become the real control plane. The result is a modern front end wrapped around legacy trust.

Practitioner takeaway: The safest replacement is not a different tunnel, it is narrower authority, enforced per application path, with no hidden assumption that being connected means being trusted.

Related resources from NHI Mgmt Group

• How should security teams reduce MFA fatigue risk without weakening access control?
• How should security teams reduce user access review fatigue without weakening control?
• How do teams reduce support load without weakening access control?
• How should security teams replace VPN access for internal services without widening privilege?