Designing Hybrid User Access with Identity‑Driven Routing

Why identity decides access but networking still owns the outage.

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

flowchart LR User[User Device] IdP[Microsoft Entra ID] GSA[Global Secure Access Edge] SaaS[SaaS Applications] PrivateApp[Private Applications] CorpNet[Enterprise Network] OnPrem[On‑Prem Resources] User --> IdP IdP -->|Access Decision| GSA GSA --> SaaS GSA --> PrivateApp GSA --> CorpNet CorpNet --> OnPrem

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
🍺
Brewed Insight: Identity‑driven routing doesn’t change who gets paged — it changes how quickly they understand the problem.
If your networking team isn’t fluent in the identity model, you haven’t simplified anything.

Learn More