sbd.org.uk
Back to blog
·9 min read·
securitymicrosoftentrazero-trustnetworking

Global Secure Access: Microsoft's SSE Play

A practical look at Microsoft's Global Secure Access — what it does, how it works, and where it fits in a zero-trust architecture.

Global Secure Access

Global Secure Access (GSA) is Microsoft's Security Service Edge (SSE) solution, built into the Entra platform. It bundles three capabilities under one roof: Microsoft Entra Internet Access, Microsoft Entra Private Access, and integration with Microsoft Defender for Cloud Apps (CASB). Together, they provide identity-aware network security that converges zero-trust network access (ZTNA), secure web gateway (SWG), and cloud access security broker (CASB) controls into the Microsoft ecosystem.

The pitch is straightforward: rather than bolting on third-party SSE products that have no awareness of your identity platform, GSA pulls network security into the same control plane as Entra ID, Conditional Access, and endpoint management. Whether that trade-off — tighter integration vs. best-of-breed flexibility — works for a given organisation depends entirely on context.

Why SSE, Why Now

Traditional network security was built around the assumption that users and resources sit behind a perimeter. VPNs extend that perimeter to remote users. The problem is well understood: VPNs grant broad network access, create bottlenecks, and don't adapt to context. A compromised credential on a VPN is a lateral movement opportunity.

SSE solutions move security controls to the cloud edge. Instead of routing all traffic through a central firewall, policies are applied at the point of access — closer to both the user and the resource. GSA specifically leans on the Microsoft global network backbone and regional Points of Presence (PoPs) to minimise latency while applying policy.

The business case for SSE boils down to:

  • Consistent policy enforcement regardless of user location
  • Reduced attack surface — no broad network access, no exposed VPN endpoints
  • Lower operational complexity — one policy engine instead of several disconnected tools
  • Better user experience — traffic takes the shortest path, not the longest

The Three Pillars

Entra Internet Access

Internet Access is the SWG component. It sits between users and the public internet, applying identity-aware security policies to all outbound web traffic. The core capabilities include:

  • Web content filtering — category-based and FQDN-based blocking, tied to Conditional Access policies via security profiles
  • Threat protection — blocks known malicious destinations
  • Token theft protection — prevents access token exfiltration by binding tokens to the network context
  • TLS inspection (public preview) — decrypts HTTPS traffic at the edge for deeper inspection, including malware detection and data loss prevention
  • Cloud firewall — network-level filtering beyond just HTTP/S

The filtering model is layered. You create web filtering policies (allow/block specific categories or FQDNs), group them into security profiles with priority ordering, and then link those profiles to Conditional Access policies. This means filtering decisions are identity-aware — different users or groups can have different internet access policies based on their role, risk level, device compliance, or location.

For example, to block all social media except LinkedIn for a specific team, you'd create two filtering policies (allow LinkedIn at a higher priority, block social media at a lower priority), bundle them into a security profile, and assign it via Conditional Access to the relevant group.

Entra Internet Access for Microsoft 365

This is a more targeted profile specifically for Microsoft 365 traffic (SharePoint, Exchange, Microsoft 365 apps). It provides:

  • Tenant restrictions v2 — prevents data exfiltration by blocking access to unauthorised tenants, enforced at the network level rather than relying on client-side configuration
  • Compliant network checks — Conditional Access can require that M365 traffic originates from the GSA tunnel, preventing bypass
  • Source IP restoration — preserves the original client IP in security logs rather than showing the tunnel egress, maintaining compatibility with named locations and risk detections

This profile is often the starting point for GSA deployments because it addresses tangible security gaps (tenant restrictions and token protection) with relatively low deployment risk.

Entra Private Access

Private Access is the ZTNA replacement for traditional VPN. It provides secure access to internal applications without exposing them to the internet or granting broad network access. Key characteristics:

  • Per-app access control — users get access to specific applications, not network segments
  • No inbound connections required — connectors make outbound connections to the Microsoft cloud, so no firewall ports need to be opened
  • Conditional Access integration — the same identity-driven policies that protect cloud apps now protect on-premises resources
  • App discovery — helps identify private applications in use across the environment
  • Intelligent Local Access — detects when a user is on a trusted network and routes traffic directly to the resource, bypassing the cloud gateway for better performance while still enforcing authentication

Applications are published either through Quick Access (broad access to ranges of IPs/FQDNs for general resources like intranet sites) or as individual Enterprise Applications (granular per-app access with dedicated security group membership).

The GSA Client

The client is the enforcement point on the endpoint. It intercepts network traffic and routes it through the appropriate GSA tunnel based on the configured traffic forwarding profiles.

How It Works

Unlike many SSE solutions that register as a VPN adapter, the GSA client uses a lightweight filter (LWF) driver. This means it can coexist with existing VPN solutions — useful during migration periods or in environments where a VPN is still needed for specific use cases.

Traffic is evaluated in priority order: Microsoft 365 profile → Private Access profile → Internet Access profile. Anything that doesn't match these profiles passes through untouched.

Platform Support

PlatformStatusNotes
WindowsGAPrimary platform. Deployed via Intune as a required app. Supports ARM64 since June 2025.
AndroidGABuilt into Microsoft Defender for Endpoint. Requires both Company Portal and Defender.
macOSGA (July 2025)Requires macOS 13+. Intel and Apple Silicon supported. Device must be Entra-registered via Company Portal.
iOSPreviewBuilt into Defender for Endpoint, similar to the Android model. Not yet generally available.

The Windows client authenticates via Web Account Manager (WAM), which integrates with Windows Hello for Business. This means GSA authentication benefits from phishing-resistant, hardware-bound MFA credentials — a meaningful security improvement over solutions that rely on separate authentication flows.

Remote Networks

For locations where installing clients on every device isn't practical — branch offices with shared desktops, Linux endpoints, IoT devices, or guest users — GSA supports remote network connectivity via IPSec tunnels. An on-premises device (router, firewall, or SD-WAN appliance) establishes an IPSec tunnel to the nearest GSA PoP, and all traffic from that network is routed through GSA without requiring per-device client installation.

This is particularly relevant for:

  • Fixed-location endpoints where client deployment isn't feasible
  • Guest or contractor access from managed network locations
  • Devices that don't support the GSA client (Linux, network cameras, OT equipment)

Connectors and Private Network Architecture

Private Access relies on connectors — lightweight agents installed on Windows Servers within the private network. These connectors make outbound connections to the Microsoft cloud, creating a secure channel for traffic to reach internal applications. No inbound firewall rules are needed.

Connectors are organised into connector groups. Each group handles traffic to specific applications or resources. This architecture provides:

  • Geographic optimisation — connector groups per location ensure traffic takes the shortest path to the application
  • Segmentation — sensitive applications (infrastructure management, financial systems) can have dedicated connector groups with tighter access controls
  • High availability — multiple connectors per group provide redundancy and load balancing
  • Automatic updates — connectors self-update with rolling deployments to avoid downtime

Connectors are functionally the same technology as Entra Application Proxy, so organisations already using App Proxy will find the architecture familiar.

Conditional Access: The Glue

What makes GSA different from a standalone SSE product is its deep integration with Conditional Access. Every traffic forwarding profile can have Conditional Access policies applied, which means network access decisions can factor in:

  • User identity and group membership
  • Device compliance state
  • Sign-in risk level (Identity Protection)
  • Location (named locations, compliant network)
  • Application sensitivity
  • Authentication strength requirements

This is what Microsoft calls universal Conditional Access — the same policy engine that gates access to cloud applications now gates access to the network itself. Applications that don't support modern authentication can be protected behind a traffic profile, inheriting the Conditional Access controls that would otherwise only apply to Entra-integrated apps.

Monitoring and Logging

GSA provides several logging surfaces, each serving different operational needs.

Dashboard

The GSA dashboard in the Entra admin centre shows deployment health: active users, devices, and applications over the last 24 hours, along with cross-tenant access patterns and device activity summaries.

Traffic Logs

Traffic logs record network connections and transactions flowing through GSA. Each entry captures who accessed what, from where, to where, and the result. The log hierarchy is:

  • Session — identified by the initial URL, can contain multiple connections
  • Connection — the 5-tuple (source IP, destination IP, source port, destination port, FQDN)
  • Transaction — individual request/response pairs within a connection

These logs are retained for 30 days within the service.

Audit Logs

Audit logs track configuration changes to the GSA environment — who changed what, and when. Useful for troubleshooting breaking changes and maintaining a change history. Retention depends on the Entra ID licence tier:

LicenceRetention
Entra ID Free7 days
Entra ID P1/P230 days

Enriched Microsoft 365 Logs

These provide enhanced telemetry for M365 workloads, adding device ID, operating system, and original IP information to standard Office audit logs. Enriched SharePoint logs include file operation details (downloads, uploads, deletions, modifications). These logs require streaming to a Log Analytics workspace or SIEM, which carries additional cost — so the value proposition should be weighed against the specific monitoring requirements.

Remote Network Health Logs

For organisations using IPSec remote network connectivity, health logs monitor tunnel status and BGP route advertisements. Available through the Entra admin centre or the Microsoft Graph API, retained for 30 days.

Log Export

All log types can be exported via diagnostic settings to Log Analytics, Event Hubs, or storage accounts for longer-term retention and integration with SIEM platforms like Microsoft Sentinel.

Permissions Model

GSA follows the principle of least privilege with dedicated roles:

RolePurpose
Global AdministratorInitial setup only — not needed for ongoing administration
Global Secure Access AdministratorFull management of Internet Access and Private Access configuration
Security Reader / Reports ReaderRead-only access to logs and dashboards

The Global Secure Access Administrator role includes Reports Reader permissions, so administrators don't need additional role assignments for monitoring.

Where It Fits

GSA is most compelling for organisations that are already deep in the Microsoft ecosystem — Entra ID for identity, Intune for endpoint management, Defender for security operations. The integration points create genuine value: Conditional Access policies that span identity and network, device compliance checks that gate network access, risk signals that flow between Identity Protection and traffic filtering.

For organisations running a multi-vendor identity stack, or those with mature SSE deployments from Zscaler, Netskope, or Palo Alto, the calculus is different. GSA can coexist with other SSE solutions (the LWF driver design enables this), so a phased approach — starting with the M365 traffic profile alongside an existing SSE — is a viable adoption path.

The product has matured considerably since its general availability in mid-2024. Client support now covers Windows, macOS, and Android at GA, with iOS in preview. Features like TLS inspection and cloud firewall are progressing through preview. The recent additions of Intelligent Local Access and B2B guest access show the platform continuing to evolve toward feature parity with established SSE vendors.

Whether GSA replaces or complements an existing SSE stack depends on the specifics: current vendor contracts, platform coverage requirements, existing Conditional Access maturity, and the operational team's familiarity with the Microsoft security ecosystem. The tightest integration story is for organisations going all-in on Microsoft security — and that's clearly the bet Microsoft is making.