Microsoft Entra Global Secure Access

Microsoft Entra Global Secure Access is Microsoft's Security Service Edge (SSE) platform — an identity-aware network security tier that replaces legacy VPN, network firewalls, and standalone CASB / SWG for many scenarios. It has two main components: Entra Internet Access for protecting outbound internet traffic, and Entra Private Access for replacing VPN with zero-trust access to private apps.

Global Secure Access is sold in the Entra Suite and enforced through Conditional Access; its Private Access component is the answer to the VPN dependency called out in retiring on-premises Active Directory, and it competes with the SSE vendors discussed in Purview vs Netskope.

Entra Internet Access

Entra Internet Access is Microsoft's Secure Web Gateway (SWG) offering. Traffic from a user's endpoint is steered through Microsoft's global edge — via the Global Secure Access client on Windows / macOS / iOS / Android, or via tunnel connectors on the network. Once there, Microsoft applies:

• Web filtering by category (gambling, adult, malware, social media, etc.) and custom rules.
• TLS inspection for content visibility (with appropriate certificate trust).
• CASB-style controls for sanctioned and unsanctioned SaaS.
• Identity-aware policies — different rules per user, per group, per Conditional Access risk level.
• Microsoft 365 traffic optimisation — Microsoft 365 endpoints get fast paths to Microsoft's network without going through general inspection.

The pitch: replace a traditional on-prem proxy (Zscaler, Netskope, Palo Alto Prisma) for Microsoft 365 customers.

Entra Private Access

Entra Private Access publishes on-premises private applications to remote users through Entra ID with Conditional Access, without requiring a VPN. Connectors deployed in your network (similar to Entra Application Proxy) reverse-tunnel out to Microsoft's edge; users connect through the Global Secure Access client and reach the apps as if on the corporate network.

Use cases:

• Replace legacy VPN for remote-access to internal apps.
• Make on-prem apps available to BYOD and contractor scenarios with full Conditional Access.
• Protect lift-and-shifted IaaS apps hosted in Azure with the same identity-aware model.

Compared to old-school site-to-site VPN, Private Access is more granular (per-app, not network-wide), identity-aware, and audited.

Conditional Access integration

Both Internet Access and Private Access feed signals into and consume policies from Entra Conditional Access. Network conditions become a CA grant control:

• Require traffic to go through Global Secure Access before Microsoft 365 will accept the session.
• Block direct access to internal apps that bypass the Private Access tunnel.
• Apply different policies based on whether a user is connected via the Global Secure Access client.

What it replaces

• Traditional VPN concentrators.
• Standalone Secure Web Gateways (Zscaler ZIA, Netskope, Cloudflare WARP-for-business at enterprise scale).
• Some CASB capabilities (though Defender for Cloud Apps still has broader CASB coverage).
• On-prem Application Proxy for many scenarios.

What it doesn't replace

• Network firewalls for inbound traffic to on-prem services exposed to the internet.
• SD-WAN for branch-to-branch connectivity.
• Defender for Endpoint for endpoint-side protection.

Licensing

Global Secure Access is licensed per user — separate SKUs for Internet Access and Private Access, often bundled.

For Microsoft 365 customers heavily invested in Entra ID, Global Secure Access is increasingly part of the zero-trust toolkit. It's still maturing, but the direction is clear.

Rollout stages

Global Secure Access is not a one-weekend deployment. A realistic sequence:

1. Microsoft 365 traffic profile only. Enable the M365 profile in the Global Secure Access blade and push the client to a pilot ring. Traffic to Exchange, SharePoint, Teams gets Microsoft's optimised path. No policy change to Internet Access or Private Access yet — you are only validating the client, network path, and support process.
2. Compliant Network in Conditional Access. Once client coverage is broad enough, add a CA policy that requires the Compliant Network condition for Microsoft 365 sign-in. This is what stops users from bypassing Global Secure Access by turning the client off.
3. Internet Access baseline. Turn on category-based web filtering with a permissive baseline (block malware, phishing, illegal). Log everything. Tighten by category over subsequent months with a change-review process.
4. Private Access for one app. Publish a single low-risk internal web app through the connector to prove the pattern (connector deployment, DNS, CA per-app policy). VPN stays in place in parallel.
5. Private Access for more apps, then VPN retirement. Migrate apps to Private Access app by app. Retire the VPN only when the last user-facing dependency is gone; keep it for server-to-server or protocols the connector can't publish yet.

Ring one is usually IT and a friendly business team. Do not skip the M365 profile step and jump straight to filtering — every user-visible break in the first two weeks poisons the rollout.

TLS inspection: the hard choice

TLS inspection is the difference between a real SWG and a glorified DNS filter. It also breaks things and creates a privacy conversation. In practice:

• Enable TLS inspection with a broad exclusion list from day one: banking, health, payroll, and any legally protected category for the jurisdiction. Microsoft ships a starter list; add locally required entries.
• Some apps use certificate pinning and will fail with a proxied certificate — Microsoft Teams native (not the web app), banking desktop apps, some MDM agents. Add them to the bypass list rather than fighting them.
• The root certificate must reach every managed endpoint. On Windows this is trivial via Intune; on BYOD it is the reason BYOD often gets a lighter policy.
• Document that inspection is happening. In the EU, works councils and DPOs will ask, and a written scope with the exclusion list is what makes the answer defensible.

Common wrong turns

• Turning on Internet Access globally on day one. The blast radius when a category is misclassified is every user at once. Rollout by ring.
• Ignoring the Compliant Network control. Without it, Global Secure Access is opt-in; users who disable the client for any reason silently bypass filtering.
• Publishing every app through Private Access before checking latency. Some legacy client-server apps are chatty enough that the connector round-trip is noticeable. Pilot with real users before promising the VPN is going away.
• Assuming Defender for Cloud Apps is now redundant. Internet Access covers SWG-style controls. MDCA still owns broader SaaS discovery, session policies for reverse-proxy apps, and app-governance. They complement each other.
• Missing the licensing shape. Internet Access and Private Access are separate per-user add-ons; the Entra Suite bundles both with ID Governance, Identity Protection premium, and Verified ID. If you are already on the path to the Suite, buying components à la carte usually costs more.

Signals worth watching

• Global Secure Access → Monitor → Traffic logs — every request the client tunnels, with user, app, category, and verdict. Feed this to Sentinel for retention beyond the built-in window.
• Connector health for Private Access — connectors are the single point of failure for a published app. Run at least two per region.
• Sign-in logs → Network location — proves the Compliant Network claim is being emitted and CA policies are honouring it.
• User feedback loop — the number of "site blocked, I need it" tickets in the first month is a leading indicator of whether the filtering baseline is too aggressive.