Every few years, user access gets “simplified”.
First it was VPN consolidation.
Then it was Private Endpoints everywhere.
Now it’s Global Secure Access (GSA).
The pitch changes, but the mistake stays the same: treating all user access technologies as if they compete in the same layer.
They don’t.
This post is about why GSA doesn’t replace VPNs, Private Endpoints, or ExpressRoute and why trying to make it do so usually weakens your architecture.
The Mental Model
The common assumption
“Global Secure Access is the modern answer to user connectivity. Over time, everything should move to it.”
Why this breaks
That assumption collapses trust, transport, and control into a single decision.
In reality:
- VPNs trust reachability
- Private Endpoints trust network placement
- ExpressRoute trusts physical transport
- Global Secure Access trusts identity context
Once you blur those boundaries, you stop designing access, you start accumulating risk.
How It Really Works
The cleanest way to compare these technologies isn’t features.
It’s where decisions are made and what must be trusted to make them.
Global Secure Access (GSA)
- Control plane: Microsoft Entra ID (identity, device, session context)
- Data plane: Microsoft‑managed global edge
- Enforcement point: Per‑user, per‑session, per‑application
GSA makes a deliberate trade‑off:
- You gain fine‑grained, identity‑driven access
- You accept a hard dependency on the identity control plane
That trade‑off is powerful and non‑negotiable.
VPN (Client / Point‑to‑Site)
- Control plane: Network authentication (certs, tokens, sometimes Entra ID)
- Data plane: Encrypted tunnel into a network
- Enforcement point: Subnets, routes, firewalls
VPNs don’t understand applications.
They grant presence, then rely on network controls to contain it.
This is a blunt tool but sometimes blunt is exactly what you want.
Private Endpoints
- Control plane: Azure Resource Manager
- Data plane: Private IP inside a VNet
- Enforcement point: Network isolation
Private Endpoints don’t solve user access at all.
They solve service exposure.
They assume:
“Whatever reaches this VNet is already trusted enough.”
How that trust is established is someone else’s problem.
ExpressRoute
- Control plane: Circuit provisioning and Azure configuration
- Data plane: Private, predictable transport
- Enforcement point: Network boundaries and upstream controls
ExpressRoute optimises how traffic moves, not who should be allowed.
Treating it as a Zero Trust mechanism is a category error and a common one.
Same user, four trust anchors
Nothing here replaces anything else.
Each path exists because a different thing is being trusted.
Real‑World Impact
Design decisions
- GSA is excellent for user‑to‑app access
- VPNs remain necessary for operator and infrastructure access
- Private Endpoints harden services, not users
- ExpressRoute belongs in transport conversations, not access debates
Trying to standardise on one tool across all four roles is how complexity leaks.
Operational reality (Day‑2)
- GSA inherits Entra ID’s availability and failure modes
- VPN access can be deliberately isolated from identity outages
- Private Endpoint sprawl becomes a DNS and lifecycle problem
- ExpressRoute incidents are rare, and brutally visible when they happen
These aren’t theoretical differences.
They show up during incidents and audits.
Two Scenarios Where GSA Should Not Be the Primary Control
1. Privileged and Emergency Operator Access
Examples:
- Break‑glass access to IaaS hosts
- Network appliance management planes
- Recovery access during identity incidents
GSA assumes:
- Entra ID is healthy
- Policy evaluation is reachable
- Microsoft’s edge is available
For operator access, those assumptions are unacceptable.
Human operators managing infrastructure should not depend on the same identity edge that protects end‑user applications.
This is where a tightly scoped admin VPN isn’t legacy, it’s deliberate risk separation.
2. Environments With Hard Regulatory or Sovereignty Constraints
Examples:
- Defence or restricted government workloads
- Sovereign environments with constrained control planes
- Architectures where identity plane dependency must be minimised
GSA requires:
- Continuous Entra ID control plane access
- Microsoft‑managed enforcement infrastructure
In some environments, that alone disqualifies it.
Gotchas & Edge Cases
- GSA does not eliminate the need for Private Endpoints
- Identity outages become access outages if you over‑centralise
- ExpressRoute is often misused as a security boundary, it isn’t one
- DNS design becomes more critical as access models diverge
Misunderstanding these boundaries is how architectures become fragile.
Best Practices
- Start every access discussion by naming what is being trusted
- Use GSA where identity context genuinely adds value
- Keep operator access isolated from user access paths
- Treat Private Endpoints as service hardening, not authorisation
- Evaluate ExpressRoute on transport requirements alone
Coexistence is not compromise.
It’s architectural clarity.
Global Secure Access doesn’t replace your network.
It replaces your default assumption that users must join it, and nothing more.
Knowing where that boundary ends is what separates mature designs from fashionable ones.