Most enterprise Azure architectures still draw a clean picture: management groups, landing zones, hubs, spokes, firewalls and somewhere off to the side, user access.
Global Secure Access (GSA) refuses to stay in that box.
If you try to drop it into your hub as “the new VPN”, you’ll spend months fighting the platform and each other. This post is about placing GSA where it actually belongs in Azure‑centric enterprise architectures, and why getting that placement wrong causes more organisational pain than technical failure.
The Mental Model
Common assumption:
Global Secure Access is a networking service that should sit alongside Azure Firewall, VPN Gateway, or ExpressRoute.
Why that breaks:
GSA doesn’t participate in your virtual network topology. It doesn’t understand subnets, routes, or east‑west flows. It never becomes part of your Azure data plane.
The correct mental model is:
Global Secure Access lives in the identity and access plane not the network plane.
Once traffic passes GSA, Azure networking starts. Before that, it’s an identity problem.
How It Really Works
At a behavioural level, Global Secure Access:
- Anchors user traffic to Microsoft’s edge
- Evaluates identity, device posture, and context through Microsoft Entra
- Forwards authorised traffic to Microsoft‑managed service endpoints
What it deliberately does not do:
- Terminate inside your VNets
- Participate in routing decisions
- Enforce segmentation inside Azure
- Replace firewalls, NSGs, or platform controls
From Azure’s point of view, GSA‑sourced traffic simply arrives pre‑authorised. Everything after that remains a platform responsibility.
Architectural Placement in Enterprise Azure
Above subscriptions, not inside them
Because GSA is Entra‑scoped:
- It fronts all subscriptions and environments
- It ignores management group boundaries
- It doesn’t care about landing zone topology
That makes it a pre‑network control layer, not a shared service VNet.
This also explains why it scales cleanly across dev, test, and prod without duplicating access infrastructure.
Responsibility Boundaries (This Is Where Teams Trip)
Global Secure Access forces a line most enterprises haven’t clearly drawn:
| Concern | GSA | Azure Platform |
|---|---|---|
| User identity | ✅ | ❌ |
| Device posture | ✅ | ❌ |
| Access decision | ✅ | ❌ |
| Blast radius control | ❌ | ✅ |
| Network segmentation | ❌ | ✅ |
| East‑west traffic | ❌ | ✅ |
A hard‑earned lesson from the field:
GSA fails fastest in organisations that haven’t agreed who owns access decisions versus blast‑radius control.
If network teams try to “own” GSA, they’ll look for IPs and routes that don’t exist.
If identity teams ignore platform constraints, Conditional Access quietly becomes a segmentation substitute.
Neither ends well.
Preview Reality: Not a Tier‑0 Dependency
GSA is evolving quickly which makes it powerful, but also unsuitable as a tier‑0 dependency today.
Architectural implications:
- Losing GSA must not lock you out of Azure administration or identity recovery
- Critical break‑glass paths should not depend on GSA availability
- Early adoption should focus on learning placement, not removing fallback access paths
This isn’t caution for caution’s sake it’s about respecting change velocity in identity‑driven services.
Where It Fits and Common Anti‑Patterns
Where it fits well
- Azure‑hosted private applications with Entra integration
- Microsoft 365 and SaaS consolidation
- Identity‑first Zero Trust strategies
- Enterprises reducing IP‑based allow‑listing
Anti‑patterns to avoid
Invisible network means no network responsibility
When user ingress becomes identity‑anchored, platform teams sometimes disengage entirely. The result is unclear failure domains and slower incident response.
GSA as a private endpoint replacement
Identity‑based access does not remove the need for network isolation. East‑west containment still matters.
One access layer to rule them all
Forcing GSA to front service‑to‑service or automation traffic creates brittle designs and breaks non‑interactive workloads.
Signals That Change (And What Replaces Them)
Introducing GSA quietly invalidates a set of assumptions many platform teams rely on.
Signals you should stop expecting
- Source IP addresses as identity
- Packet captures at the VNet edge for user traffic
- Firewall rule hit counts as access evidence
- Network logs answering “who accessed what”
Signals you need to replace them with
- Entra sign‑in and audit logs as the primary access record
- Application‑level telemetry for success and failure
- Policy evaluation outcomes instead of rule matches
- Clear escalation paths between identity, platform, and app teams
Put simply:
Access becomes an identity event first, and a network event second.
Your operational model needs to follow that order.
Conceptual Placement Diagram
GSA gates entry.
Azure networking governs everything after.
Best Practices
- Treat GSA as an identity capability, not a network service
- Keep Azure network segmentation intact
- Align GSA ownership with identity governance teams
- Document responsibility boundaries explicitly
- Avoid turning Conditional Access into a proxy for segmentation
That only works if your organisation is ready to change how it thinks about access, visibility, and responsibility.