Why Global Secure Access should replace your VPN

Most VPN problems we see in customer environments are not caused by the VPN itself. They are caused by what happens after the tunnel comes up.

A VPN authenticates the user once and assigns an IP address on the corporate network. From that point on, the network is trusted, not the individual request. Once inside, a user typically has access to far more than the one application they actually need. That’s exactly the kind of implicit trust Zero Trust is meant to get rid of, and it’s the main reason we’ve been moving customers off VPN and onto Microsoft Entra Global Secure Access wherever the licensing allows it.

VPN trusts the network. GSA trusts the request.

Encryption was never the weak point of a VPN. Standing network access was. A traditional VPN makes a network-layer decision once, at connection time. After that, firewall rules and internal segmentation are what actually limit access, and in customer environments those rules are frequently out of date. Every remote session also backhauls through a VPN concentrator, adding latency, often for traffic that is heading straight back out to Microsoft 365.

Global Secure Access works differently. It is Microsoft’s Security Service Edge (SSE) solution, built from two components inside Entra ID:

• Microsoft Entra Private Access replaces VPN reachability with per-app access. Instead of landing on a subnet, a user connects to a specific FQDN, IP address or port range, evaluated against Conditional Access on every request, not only at sign-in.
• Microsoft Entra Internet Access is an identity-aware secure web gateway for internet and SaaS traffic. It includes a Microsoft traffic profile that routes Microsoft 365 traffic through Microsoft’s own network edge instead of the VPN, with source IP restoration so sign-in logs still show the user’s real location.

Both are managed from the same Global Secure Access area in the Entra admin center, and both follow the same principle: verify explicitly, use least privilege, assume breach. In our experience, the practical result is straightforward: users simply have less standing access than before, and that access is checked continuously instead of once.

What this changes in practice

• Per-app instead of per-subnet access. A contractor who needs one internal application gets access to that FQDN and port, not the subnet it happens to sit on. In most environments we review, VPN split-tunnel configurations have grown well beyond what is actually required.
• Continuous evaluation instead of one-time authentication. Universal Continuous Access Evaluation reacts to a revoked token or a change in risk score within minutes, rather than waiting for the VPN session to expire.
• No VPN concentrator to patch, size or fail over. This is infrastructure that no longer needs to be maintained, and it is usually the point that gets a migration approved internally.
• Conditional Access applies to network access, not just sign-in. Compliant device, MFA, location and risk signals apply to the private connection itself.
• Better performance for cloud-first traffic. Microsoft 365 traffic runs over Microsoft’s backbone (70+ regions, 190+ edge locations) instead of routing through the VPN gateway first.

Licensing

Microsoft Entra Internet Access and Private Access are generally available, sold standalone or as part of the Microsoft Entra Suite. The Microsoft traffic profile, which secures and accelerates access to Microsoft 365 specifically, is already included in Entra ID P1 or P2. In our experience, many customers already have this available and simply are not using it. Full Internet Access and Private Access, including Quick Access and per-app segmentation, require the dedicated GSA licenses or the Entra Suite. It is worth checking existing P1/P2 coverage before assuming a new purchase is needed.

Migration approach

The migration itself is rarely the difficult part. What usually takes time is validating coverage before the VPN is switched off. Microsoft’s documented path uses Quick Access as a transition state, then narrows down to per-app segments once coverage is confirmed:

1. Create a private network connector group with at least one active connector that can reach the internal resources. This takes over the role previously played by the VPN gateway. If you’ve got an old connector sitting around from an earlier proof of concept, reinstall it rather than trying to reuse it. Anything below version 1.5.3417.0 won’t work with Private Access, and the upgrade path isn’t always clean.
2. Configure a Quick Access app under Global Secure Access > Applications, and add the FQDNs, IP ranges and ports currently reached over VPN. Up to 500 segments are supported, and ports accept ranges such as 400-500, 80, 443.
3. Assign users and groups to the Quick Access app, the same way as any other enterprise application.
4. Link a Conditional Access policy to the app so compliant device and MFA requirements apply to the private connection, not only to sign-in.
5. Enable the Private Access traffic forwarding profile so the Global Secure Access client starts routing that traffic.

In customer environments, we usually run this in parallel with the existing VPN for a pilot group first. After a few weeks of traffic logs without missing access, the broad Quick Access segments get split into individual per-app segments. That is where the actual reduction in access happens compared to the VPN’s original subnet-level reach.

The biggest challenge is rarely technical. It is deciding when the last edge cases, such as unsupported operating systems or non-standard protocols, are covered well enough to decommission the VPN gateway. Migrated in stages, with monitoring at each step, Global Secure Access consistently ends up covering more use cases than the VPN it replaced, with less ongoing maintenance.