Every time we talk about identity‑driven access, someone eventually says:
“So networking won’t need to worry about user access anymore, right?”
That question alone tells you where most hybrid designs go wrong.
Global Secure Access (GSA) doesn’t remove the network from user access.
It changes where decisions are made, not who carries the pager.
If you design hybrid user access assuming identity ownership replaces network ownership, you’re setting yourself up for confused outages and slower recovery not better security.
The Mental Model
The common assumption
“Identity‑based access replaces network‑based access.”
This frames identity and networking as competing models.
Why this breaks down
In real hybrid estates:
- Packets still traverse networks you own and operate
- Latency, path asymmetry, DNS, and MTU still matter
- When users can’t connect, the networking team still gets called first
Identity doesn’t replace networking.
It moves the access decision upstream, before transport is exercised.
That distinction matters operationally.
How It Really Works
Identity is the control plane, not the data plane
With GSA, identity determines:
- Who is allowed
- Under what conditions
- To which class of resource
What it does not do:
- Eliminate routing complexity
- Remove dependency on underlying connectivity
- Magically simplify incident response
Once access is approved, traffic still flows via:
- Microsoft’s global edge (for SaaS and some private access), or
- Existing enterprise paths (VPNs, ExpressRoute, on‑prem routing)
The decision logic is centralised.
The transport remains distributed.
That separation is the architectural shift.
Real‑World Impact
How this changes what you design, deploy, and operate
Design
- You stop designing networks around “trusted locations”
- You start designing around decision boundaries:
- Identity boundary (who is allowed)
- Application boundary (what they’re accessing)
- Transport boundary (how traffic moves)
Operations
- Incidents still land with networking — and that’s correct
- Identity becomes a diagnostic input, not the owner of resolution
- Faster isolation when teams share a common mental model
Reliability
- Identity failures and transport failures decouple slightly, not fully
- Clearer blast radius when access logic is centralised
- Fewer cascading failures caused by duplicated controls
Conceptual Architecture: Hybrid, Not Replaced
Key point:
Identity determines whether traffic is allowed.
Networking determines whether it actually flows.
Decision Boundaries That Matter in Practice
SaaS vs Private Applications
This is where most organisations draw the first clean line.
SaaS
- Identity‑first access is natural
- Transport complexity is largely abstracted
- Networking impact is minimal and predictable
Private applications
- Identity gates access
- Networking still owns reachability, performance, and failure modes
- Coexistence with VPNs and fixed paths is normal — often long‑term
The mistake is assuming both categories behave the same operationally.
Transitional States Are the Architecture
Hybrid user access is not a phase — it’s a sustained state.
Common patterns that actually work:
- Dual paths by design
- Identity‑driven access for modern apps
- Legacy paths retained for brittle workloads
- Identity consistency first
- Centralise access decisions before touching transport
- Application‑level intent
- Each app declares identity requirements independently of network paths
If your architecture diagram doesn’t show coexistence, it’s lying.
Operational Reality: Who Owns the Incident?
This is the uncomfortable part.
When a user can’t reach an internal app:
- The ticket goes to networking
- The networking team must diagnose:
- Identity decision outcome
- Edge routing behaviour
- Underlying path health
Identity‑driven routing does not remove networking ownership.
It raises the bar on what networking teams need to understand and observe.
The success metric isn’t fewer tickets.
It’s faster, more confident diagnosis.
That only happens when:
- Networking teams understand identity‑driven access models
- They have visibility into identity decisions
- Identity and network tooling are treated as part of the same system
Why There’s No Implementation Section Here
This post intentionally avoids configuration snippets.
At this stage of design:
- Implementation details create false confidence
- Feature‑level controls distract from architectural intent
- The real risk is misaligned ownership, not misconfigured policies
Concrete implementation belongs later, once the decision boundaries are agreed.
Gotchas & Edge Cases
- Identity success ≠ connectivity success
Approval does not guarantee reachability. - Ambiguous routing during coexistence
Multiple valid paths confuse users and operators alike. - Team silos become incident amplifiers
If identity and networking operate independently, outages last longer.
Best Practices
- Treat identity as a shared dependency, not a handoff
- Design hybrid states explicitly — document them
- Assume networking owns the outage, then design to help them
- Invest in diagnostics before optimisation
- Resist the urge to “finish” the migration too early
If your networking team isn’t fluent in the identity model, you haven’t simplified anything.