8.3 Global Secure Access

Global Secure Access on the SC-300 map

By now you can authenticate users, evaluate risk, require MFA, and write Conditional Access. Microsoft Entra Global Secure Access (GSA) answers a different question: once identity is verified, how does the endpoint reach private applications and the internet under Zero Trust, without a flat VPN that overshares the network?

Microsoft positions Global Secure Access as its Security Service Edge (SSE) solution—converging Zero Trust Network Access (ZTNA), secure web gateway-style internet controls, and optimized Microsoft 365 connectivity under the Entra identity control plane.

SC-300 depth is identity-admin oriented:

• What GSA is and why it exists
• Client deployment concept
• Private Access versus Internet Access versus Internet Access for Microsoft 365
• How GSA relates to Conditional Access and Zero Trust
• What problems GSA solves versus classic VPN

You are not expected to design every BGP route or replace a full network engineer role. You are expected to choose GSA components correctly in scenario stems.

Related practice: /practice/azure-sc-300. Guide hub: /study-guides/azure-sc-300.

Zero Trust network access in one paragraph

Zero Trust for networks rejects “inside corporate IP = trusted.” Instead:

1. Verify explicitly — strong identity, device health, risk, location.
2. Least privilege access — grant per application/segment, not whole subnet.
3. Assume breach — continuous evaluation; minimize lateral movement.

Classic VPN often fails least privilege: once connected, users may route to broad internal ranges. ZTNA / Private Access publishes specific apps and evaluates identity + CA before connectivity, aligning network access with the same Entra identity you already govern.

Global Secure Access architecture (exam mental model)

Identity admins coordinate with networking and endpoint teams, but policy intent (who gets Private Access to HR web app; whether M365 profile is enabled; CA grants) sits squarely in SC-300 territory.

Deploy Global Secure Access clients

Endpoints need the Global Secure Access client (Windows is the primary SC-300 focus; Microsoft continues expanding platform support—know the concept of client-based traffic acquisition).

Deployment pattern:

1. Prerequisites — appropriate licenses/SKU for GSA capabilities; Entra tenant prep; admin roles for GSA configuration.
2. Enable the service / traffic profiles in the Microsoft Entra admin center under Global Secure Access experiences.
3. Deploy the client via Intune (common), other MDM, or managed install—identity exam emphasizes managed deployment, not manual one-off installs for enterprises.
4. User signs in to the client with Entra identity so traffic is tied to the user/device.
5. Validate that selected traffic profiles forward and that CA policies still apply as designed.
6. Pilot a group before org-wide rollout; monitor connection health and user friction.

Exam cue: “Users need ZTNA without full VPN; Windows laptops are Intune managed.” → Deploy GSA client + Private Access, not “open RDP to the world.”

Microsoft Entra Private Access

Private Access is the ZTNA product under GSA for private applications—internal web apps, RDP/SSH style access patterns, and line-of-business systems that should not be exposed on the public internet.

How it differs from VPN

Identity admin tasks (conceptual)

1. Install/configure Private Network Connectors in networks that can reach the private apps (connector groups for capacity/regions).
2. Define Quick Access or per-app private access applications (product UX names evolve; concept is publish private resources).
3. Assign users/groups who may access those apps.
4. Protect with Conditional Access (require MFA, compliant device, authentication strength, risk levels).
5. Replace or reduce always-on full-tunnel VPN for those app scenarios.

Connectors are critical: they are the private-side bridge. Without healthy connectors, Private Access cannot reach internal hosts—even if CA would allow the user.

SC-300 scenario mapping

Microsoft Entra Internet Access

Internet Access is the secure web / internet egress leg of SSE. Instead of users browsing the open internet with only endpoint antivirus, traffic can flow through Microsoft’s edge for:

• Web content filtering / category-based controls
• Threat intelligence informed blocking
• Consistent policy for remote and on-site users (when client + profile enabled)
• Logging for internet activity relevant to security investigations

Identity admins care because internet policy can complement CA session controls and Defender for Cloud Apps (other chapters): different layers, related Zero Trust story.

Internet Access for Microsoft 365

Internet Access for Microsoft 365 (Microsoft 365 traffic forwarding profile / related GSA capabilities) optimizes and secures connectivity specifically for Microsoft 365 workloads—Exchange Online, SharePoint/OneDrive, Teams, and related Microsoft endpoints.

Why Microsoft calls this out separately:

• M365 traffic is high volume and sensitive.
• Customers historically bypassed proxies incorrectly or broke Teams media.
• GSA provides identity-aware, Microsoft-aligned handling of M365 traffic profiles with security and performance considerations.
• You can apply protections relevant to M365 egress while following Microsoft connectivity principles (as docs evolve).

Exam trap: Do not answer “Private Access” when the requirement is secure/optimized Microsoft 365 connectivity for remote workers—that is the M365 GSA path. Do not answer “Internet Access for Microsoft 365” when the app is a datacenter HR portal—that is Private Access.

How GSA relates to Conditional Access and ID Protection

GSA does not replace Conditional Access. It extends the enforcement path:

User + device
    → Entra authentication (methods, risk, CA)
    → Global Secure Access client / traffic profile
    → Private Access app or Internet/M365 path
    → Resource

You can require MFA + compliant device before Private Access to a sensitive app—the same mental model as requiring those grants for Exchange Online, now applied to network access products.

Zero Trust checklist for identity admins adopting GSA

1. Strong identity: phishing-resistant methods for privileged; broad MFA registered (campaigns from 8.2).
2. Risk-based CA from ID Protection (section 8.1) still on.
3. Deploy GSA client via modern management.
4. Publish private apps with least privilege assignments.
5. Enable M365 profile thoughtfully for remote productivity.
6. Apply Internet Access policies aligned with corporate web acceptable use.
7. Monitor GSA logs alongside Entra sign-in logs for investigations.
8. Reduce broad VPN over time as Private Access coverage grows.
9. Keep break-glass and support channels for client outages (identity + network co-ownership).

Common SC-300 traps

• Equating GSA with “just another VPN SKU” and granting whole-network access by design.
• Choosing Private Access for public SaaS web filtering needs (use Internet Access).
• Choosing Internet Access when the resource is an internal app (use Private Access).
• Forgetting the client requirement in remote ZTNA scenarios.
• Claiming GSA eliminates the need for Conditional Access or MFA.
• Ignoring connectors when Private Access fails to reach on-premises apps.

Chapter close

In this chapter you learned to score and remediate user and sign-in risk, drive MFA registration while securing risky workloads, and place Global Secure Access in the Zero Trust SSE architecture for identity administrators. Domain 2 continues to reward candidates who connect identity proof, risk, registration readiness, and access path design into one coherent story.

Keep practicing at /practice/azure-sc-300 and explore adjacent security depth in /practice/azure-az-500 when network and defender controls expand beyond pure identity administration.