Most engineers approach Global Secure Access (GSA) the same way they approached VPNs.

They look for the tunnel.
They look for the IP range.
They ask where the packets go.

That instinct isn’t wrong, it’s just anchored to the wrong problem.

Global Secure Access isn’t trying to improve connectivity.
It’s trying to reduce the risk created by long‑lived trust decisions.

Once you see that, the rest of the architecture snaps into focus.

The Mental Model

The common assumption

The prevailing assumption is that GSA is:

• A cloud‑hosted VPN replacement
• A proxy with identity layered on
• Another option for getting users “inside” the environment

Even well‑run VPNs reinforce this idea: authenticate strongly up front, then rely on the network to carry trust forward.

Why this breaks down

VPNs, even modern ones with MFA, make a single, high‑impact decision:

“This user and device are trusted. Keep them connected.”

What they’re bad at is withdrawing that trust when conditions change.

• Device posture degrades
• Risk signals increase
• Credentials are abused mid‑session

The network stays up anyway.

GSA exists to collapse that decision latency.

How It Really Works

At its core, Global Secure Access is an identity‑centric access broker.

Its primary job is not to move traffic efficiently, but to continuously evaluate whether a session should still exist.

That evaluation is driven by:

• Identity — Entra ID users, groups, and claims
• Session context — device compliance, location, risk signals
• Policy — Conditional Access and security profiles

If and only if, policy allows, GSA facilitates connectivity via Microsoft’s global edge.

Transport happens, but it’s not the point.

Access brokering vs network transport

This distinction is where most designs go wrong.

GSA does not replace:

• Application authentication
• Network routing design
• Your underlying connectivity primitives

It replaces the assumption that connectivity equals trust.

Real‑World Impact

The business risk it actually reduces

Even a “good” VPN leaves one major risk intact:

A compromised user session remains powerful for too long.

Once connected, VPN users often gain:

• Broad network reachability
• Stable access that outlives changing risk conditions
• Trust that is hard to revoke without full disconnection

GSA changes this by making access:

• Explicit — scoped to apps, not networks
• Session‑aware — continuously evaluated
• Revocable — policy changes take effect mid‑flight

This reduces blast radius and shortens the window between something becoming unsafe and access being removed.

How this changes what you design and operate

You stop designing around “who gets on the network” and start designing around:

• Which sessions are allowed right now
• Under what conditions access should terminate
• How quickly policy reacts to signal changes

Operationally, day‑2 effort shifts from network stability to decision quality.

Implementation Examples

GSA configuration is anchored in identity and policy, not routing tables.

Conceptual access flow

The key observation:
The decision loop is short, and it repeats.

Policy as a control surface (illustrative)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "conditions": {
    "users": {
      "includeGroups": ["Engineering"]
    },
    "signInRiskLevels": ["low"],
    "devices": {
      "filter": "device.isCompliant -eq true"
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["compliantDevice"]
  }
}

This isn’t special because it’s Conditional Access.
It’s important because GSA enforces these decisions continuously, not just at sign‑in.

Gotchas & Edge Cases

• GSA will not save a weak identity posture
  Poor device compliance or noisy risk signals will cause real outages, fast.
• Protocols that assume broad network reach struggle
  GSA rewards explicit app exposure, not ambient access.
• Mis‑scoped policy fails hard
  Identity‑driven systems don’t degrade gracefully; they deny decisively.
• Preview behaviour matters
  GSA is still evolving, assumptions must be validated against current service behaviour.

Best Practices

• Treat GSA as a control plane, not a data plane
• Design policies around revocation speed, not just access grants
• Keep access scopes narrow and explicit
• Assume sessions will be re‑evaluated and interrupted
• Instrument and review access decisions as a security signal

Learn More

• Global Secure Access Overview
• Conditional Access Overview
• Zero Trust Overview