Azure Architecture Security

Securing SaaS and Private Apps with Global Secure Access

What really changes when access decisions move from networks to user sessions.

For a long time, securing applications has followed a comfortable sequence:

  1. Make the app reachable
  2. Authenticate the user
  3. Hope nothing changes mid‑session

Global Secure Access (GSA) challenges that order. It assumes that change is the default users roam, devices drift out of compliance, risk signals evolve and asks whether access should still exist right now.

That framing matters when you’re securing both SaaS and private applications, because it moves the problem away from network exposure and toward session‑level trust.

The Mental Model

Common assumption:
SaaS applications are secured with identity. Private applications are secured with networks.

Why it breaks:
Attackers don’t differentiate. They exploit authorised sessions, not architectural categories.

Global Secure Access treats SaaS and private apps the same way: as destinations that require an explicit, continuously justified decision to access. The control plane doesn’t care where the app lives only who is accessing it, from what, and under what conditions.

The real shift isn’t SaaS versus private.
It’s implicit reachability versus evaluated access.

How It Really Works

Global Secure Access inserts a user‑aware enforcement layer in front of application traffic.

In practice:

  • Users authenticate with Microsoft Entra ID.
  • Traffic is associated with an authenticated user session, not an IP address.
  • Conditional Access (CA) policies are evaluated based on identity, device state, and risk.
  • Access is granted or denied before traffic reaches the application.

An important boundary to be explicit about:

Global Secure Access evaluates access to the session, not authorisation inside the application.

If an application accepts a bearer token indefinitely, GSA won’t save you from that design choice. It can revoke or deny future access, but it cannot fix weak application‑level trust models.

That distinction is where a lot of confusion and overconfidence creeps in.

Real‑World Impact

SaaS applications

With GSA in place, SaaS access stops being a one‑time decision at sign‑in.

You gain:

  • Consistent Conditional Access enforcement across SaaS providers
  • Explicit session lifetime controls
  • The ability to react to changing risk signals

Operationally, this means:

  • A user’s access can be revoked without touching the app.
  • Unmanaged or risky devices don’t quietly retain access.
  • Location and corporate networks stop being trusted signals by default.

Private applications

For private apps, the impact is more structural.

Access no longer requires:

  • Broad network reachability
  • IP allow‑listing gymnastics
  • Assuming “on the network” equals “trusted”

Instead:

  • Users are authorised per application, not per subnet.
  • Reachability follows identity, not topology.
  • Lateral movement opportunities are significantly reduced.

This doesn’t modernise legacy applications but it does contain their blast radius far more effectively than network‑centric controls.

Implementation Examples

Conceptual access flow

flowchart LR User[User + Device] GSA[Global Secure Access] CA[Conditional Access] SaaS[SaaS Application] Private[Private Application] User --> GSA GSA --> CA CA -->|Allowed| SaaS CA -->|Allowed| Private CA -->|Blocked| User

The application never sees the request unless identity and session policy say it should.

Conditional Access policy (illustrative)

Below is a simplified Conditional Access policy targeting a private application accessed via Global Secure Access.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "displayName": "GSA - Private App - Require Compliant Device",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "applications": {
      "includeApplications": ["<private-app-enterprise-app-id>"]
    },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": [
      "mfa",
      "compliantDevice"
    ]
  },
  "sessionControls": {
    "signInFrequency": {
      "value": 8,
      "type": "hours"
    }
  }
}

Why this matters in production:

  • Access can be withdrawn centrally without redeploying the app.
  • Device posture becomes a hard requirement, not guidance.
  • Session lifetime is an explicit decision, not an accident.

Gotchas & Edge Cases

  • Authorised misuse still exists
    Global Secure Access is excellent at preventing unauthorised access. It is far less effective at containing authorised abuse.

  • Legacy token behaviour matters
    Long‑lived or non‑expiring tokens undermine session‑based controls. Identity enforcement can only be as strong as the app’s trust model.

  • Policy confidence depends on signal quality
    Device compliance and risk signals must be reliable. Weak inputs lead to confident but wrong decisions.

  • Feature maturity varies
    Parts of Global Secure Access are still evolving. Always confirm GA status before relying on specific behaviours in production designs.

Best Practices

  • Treat SaaS and private apps identically in access policy language.
  • Be explicit about session lifetime this is a business decision, not a technical default.
  • Use device compliance as a baseline requirement, not a conditional add‑on.
  • Design access policies around user intent, not network location.
  • Document where GSA enforcement ends and application responsibility begins.
🍺
Brewed Insight:

Global Secure Access materially reduces attacks that rely on unauthorised reachability stolen credentials, unmanaged devices, and accidental exposure. It does very little to stop attacks that occur after legitimate access is granted.

In other words: GSA is very good at deciding who gets to knock on the door and mostly irrelevant once you’ve let the wrong person inside.

Learn More