Global Secure Access: Microsoft's SSE Play

Global Secure Access

Global Secure Access (GSA) is the umbrella name for Microsoft Entra Internet Access and Microsoft Entra Private Access, built into the Entra platform. Microsoft pairs these two with Microsoft Defender for Cloud Apps, its cloud access security broker (CASB), to complete its Security Service Edge (SSE) solution. Together, the three converge into one identity-aware control plane covering zero-trust network access (ZTNA), secure web gateway (SWG) and CASB controls.

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. That trade-off, tighter integration versus best-of-breed flexibility, is the question this post answers.

Why SSE, why now

Traditional network security assumed that users and resources sat behind a perimeter, and VPNs extended that perimeter to remote users. VPNs grant broad network access, create bottlenecks, and don't adapt to context, so a compromised credential becomes a lateral movement opportunity.

SSE solutions move security controls to the cloud edge. Instead of routing all traffic through a central firewall, they apply policy at the point of access, closer to the user and the resource. GSA leans on Microsoft's global network backbone and regional Points of Presence (PoPs) to minimise latency while it applies policy.

The business case for SSE comes down to four things:

• Policy enforcement stays consistent regardless of where the user connects.
• The attack surface shrinks: no broad network access and no exposed VPN endpoints.
• Operational complexity drops: one policy engine replaces several disconnected tools.
• The user experience improves: traffic takes the shortest path, not the longest.

Entra Internet Access and Entra Private Access

Entra Internet Access

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

• Web content filtering, which blocks by category or FQDN and ties to Conditional Access through security profiles.
• Threat protection, which blocks known malicious destinations.
• Token theft protection, which prevents access token exfiltration by binding tokens to the network context.
• TLS inspection, which decrypts HTTPS traffic at the edge for deeper inspection, including malware detection and data loss prevention.
• Cloud firewall, which filters internet traffic from branch offices connected through remote networks. It isn't yet available for traffic from the GSA client itself.

GSA's filtering model is layered. Each security profile holds exactly one web filtering policy. That policy contains rules, and GSA evaluates the rules in priority order, falling back to the policy's default action for anything that matches none of them. Security profiles then link to Conditional Access policies, so filtering decisions are identity-aware: users and groups can get different internet access depending on their role, risk level, device compliance or location.

For example, to block social media except LinkedIn for one team, you write two rules in a single web filtering policy: allow LinkedIn at a higher priority, then block social media at a lower priority. You bundle that policy into a security profile and assign it through Conditional Access to the relevant group.

The Microsoft traffic profile

The Microsoft traffic profile is a more targeted part of Internet Access, scoped to Microsoft's own traffic: SharePoint, Exchange and the Microsoft 365 apps. It gives you:

• Universal Tenant Restrictions, which extend tenant restrictions v2. They block access to unauthorised tenants and apply to any device running the GSA client, or connected through a GSA remote network, without routing traffic through a company proxy.
• Compliant network checks, so Conditional Access can require that Microsoft traffic originates from the GSA tunnel, blocking any bypass.
• Source IP restoration, which preserves the client's original IP address in security logs instead of the tunnel's egress address, so named locations and risk detections keep working.

This profile is often the starting point for a GSA deployment. It closes real security gaps, tenant restrictions and token protection, with 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. Its key characteristics are:

• Per-app access control, which gives users access to specific applications, not whole network segments.
• No inbound connections: connectors make outbound connections to the Microsoft cloud, so you open no firewall ports.
• Conditional Access integration: the same identity-driven policies that protect cloud apps now protect on-premises resources too.
• App discovery, which helps you find the private applications already in use across the environment.
• Intelligent Local Access, which detects when a user is on a trusted network and routes traffic straight to the resource, bypassing the cloud gateway for better performance while it still enforces authentication.

You publish applications either through Quick Access, which gives broad access to a range of IPs or FQDNs for general resources such as intranet sites, or as individual enterprise applications, which give granular per-app access with their own 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, which register as a VPN adapter, the GSA client uses a lightweight filter (LWF) driver. That design lets it coexist with an existing VPN, useful during a migration or wherever a VPN is still needed for specific cases.

GSA evaluates traffic in priority order: the Microsoft traffic profile first, then the Private Access profile, then the Internet Access profile. Anything that matches none of them passes through untouched.

Platform support

The Windows client authenticates through Web Account Manager (WAM), which integrates with Windows Hello for Business. That gives GSA authentication phishing-resistant, hardware-bound MFA credentials, a real security improvement over solutions that rely on separate authentication flows.

Remote networks

For locations where installing a client on every device isn't practical, shared desktops in a branch office, Linux endpoints, IoT devices or guest users, GSA supports remote network connectivity over IPSec tunnels. An on-premises router, firewall or SD-WAN appliance establishes an IPSec tunnel to the nearest GSA point of presence, and GSA then routes all traffic from that network without installing a client on every device.

Remote networks work well 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, such as Linux hosts, network cameras or OT equipment.

Connectors and private network architecture

Private Access relies on connectors, lightweight agents installed on Windows Server inside the private network. Connectors make outbound connections to the Microsoft cloud, creating a secure channel for traffic to reach internal applications, so you need no inbound firewall rules.

Connectors are organised into connector groups, and each group handles traffic to specific applications or resources. This gives you:

• Geographic optimisation: a connector group per location keeps traffic on the shortest path to the application.
• Segmentation: sensitive applications, such as infrastructure management or financial systems, can sit behind dedicated connector groups with tighter access controls.
• High availability: multiple connectors in a group give you redundancy and load balancing.
• Automatic updates: connectors update themselves in rolling deployments that 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

GSA's real differentiator against a standalone SSE product is its integration with Conditional Access. You can apply Conditional Access policies to any traffic forwarding profile, so 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

Microsoft calls this universal Conditional Access. The same policy engine that gates cloud applications now gates the network itself. An application that doesn't support modern authentication can sit behind a traffic profile and inherit Conditional Access controls that would otherwise apply only to Entra-integrated apps.

Monitoring and logging

GSA provides several logging surfaces, each for a different operational need.

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. Microsoft still labels traffic logs preview. The log hierarchy is:

• The initial URL identifies a session, which can contain multiple connections.
• A connection is the 5-tuple: source IP, destination IP, source port, destination port and FQDN.
• A transaction is an individual request/response pair within a connection.

GSA retains these logs for 30 days within the service.

Audit logs

Audit logs track configuration changes to the GSA environment: who changed what, and when. They help you troubleshoot a breaking change and keep a change history. Microsoft's how-to page for accessing them is still marked preview, and retention depends on your Entra ID licence tier:

Enriched Microsoft 365 logs

These add device ID, operating system and original IP information to standard Office audit logs for Microsoft 365 workloads. Enriched SharePoint logs also record file downloads, uploads, deletions and modifications. You need to stream them to a Log Analytics workspace or a SIEM, which carries additional cost, so weigh that against what you actually need to monitor.

Remote network health logs

If you use IPSec remote network connectivity, health logs monitor tunnel status and BGP route advertisements. You can reach them through the Entra admin centre or the Microsoft Graph API, and GSA retains them for 30 days.

Log export

You can export every log type through diagnostic settings, to Log Analytics, Event Hubs or storage accounts, for longer retention and integration with SIEM platforms such as Microsoft Sentinel.

Permissions model

GSA follows least privilege, with a dedicated role for each job:

The Global Secure Access Administrator role already covers viewing traffic logs and alerts as part of its own scope. Global Secure Access Log Reader exists for people who need that visibility without the rest of the role's configuration rights.

Where it fits

GSA earns its strongest case for organisations that already run deep on Microsoft: Entra ID for identity, Intune for endpoint management, Defender for security operations. The integration points are real: Conditional Access policies that span identity and network, device compliance checks that gate network access, and risk signals that flow between Identity Protection and traffic filtering.

For organisations running a multi-vendor identity stack, or with a mature SSE deployment already from Zscaler, Netskope or Palo Alto, the calculation is different. GSA's LWF driver design lets it coexist with another SSE solution, so a phased approach, starting with the Microsoft traffic profile alongside your existing SSE, is a real adoption path.

The product has matured since its general availability in mid-2024: Client support now covers Windows, macOS and Android at general availability, and Microsoft's feature table no longer tags iOS as preview, though no page yet states that it is generally available. The feature table no longer tags TLS inspection as preview either. Cloud firewall is scoped to branch office traffic over remote networks, and the client doesn't support it yet. 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 how familiar your operational team already is with Microsoft security. The tightest integration story is for an organisation going all-in on Microsoft security, and that is clearly the bet Microsoft is making.