Thinking of clicking that intimidating “Activate” button for Microsoft’s Global Secure Access? Don’t panic—I’ll explain why it won’t instantly tank your network and how to roll it out without alerting the CISO.

The Big Red Button: Is It Safe to Activate Global Secure Access in Your Tenant?

I still wake up in a cold sweat thinking about the “Great DNS Outage of 2018” here at TechResolve. I thought I was making a minor route change to a non-prod environment. Turns out, prod-api-01 shared a routing table I hadn’t audited. Ten minutes later, the CTO was standing at my desk asking why the customer portal was showing a 503.

So, I get it. When you stare at the “Activate Global Secure Access” button in the Entra admin center, your PTSD kicks in. It sounds ominous. It sounds global. It sounds like something that will intercept every packet leaving your CEO’s laptop and drop it into a black hole.

But here is the good news: I clicked it, and the world didn’t end. Let’s break down exactly what happens, why you’re scared, and how to do it right.

The “Why”: It’s a Capability, Not a Switch

The confusion here stems from Microsoft’s UI design. We are trained to believe that “Activate” means “Execute.” In the context of Global Secure Access (GSA)—which is essentially Microsoft’s SSE solution covering Entra Internet Access and Private Access—activation is different.

The Root Cause of the Fear: You think enabling GSA immediately reroutes traffic through Microsoft’s edge network.

The Reality: Clicking “Activate” simply provisions the backend tenant services. It spins up the ability for your tenant to handle the traffic, but it does not change the flow of traffic on its own.

Think of it like paying the toll for a bridge but not actually driving your car onto it yet. Traffic flow only changes when you configure Traffic Forwarding Profiles and install the Global Secure Access Client on endpoints.

The Fixes: How to Enable It Without Getting Fired

If you are ready to modernize your network security but want to keep your job, here are the three ways I approach this rollout.

1. The “Dip Your Toe” Method (Zero Risk)

This is the validation step. You want to prove the feature is active without touching a single production packet.

The Strategy: Go ahead and click “Activate” in the Entra portal. Then, immediately verify that the Traffic Forwarding checkboxes are unchecked.

Pro Tip: After activation, wait 15 minutes. Microsoft’s backend propagation can be sluggish. Grab a coffee before you try to install your first connector.

2. The “Surgical Strike” (The Pilot)

This is the standard engineering approach. We are going to route traffic for exactly one device and one application.

The Strategy: Use the Traffic Forwarding rules to scope the rollout. Unlike the old VPN days where it was all-or-nothing, GSA allows granular control.

• Install the Private Network Connector on a bastion host (e.g., dmz-conn-01).
• Configure an Enterprise Application for a specific internal tool (e.g., your internal Jira or a dev dashboard).
• Deploy the GSA Client to your laptop only.

If things go sideways, you can kill the client service via PowerShell immediately:

# Stop the Global Secure Access Client service locally
Stop-Service -Name "GlobalSecureAccessClient" -Force

# Verify it's dead
Get-Service "GlobalSecureAccessClient"

3. The “Nuclear” Option (Emergency Rollback)

Let’s say you got confident. You deployed the client via Intune to the “All Staff” group (rookie mistake, but I’ve been there) and enabled the Microsoft 365 traffic profile. Suddenly, Teams is lagging, and Outlook is disconnecting.

You need a kill switch. Disabling the forwarding profile in the portal can take time to propagate to clients. The fastest way to restore sanity is to pause the client on the endpoints or force a registry override via GPO/Intune script.

Here is a quick “Break Glass” script to disable the forwarding handlers on a machine behaving badly:

$RegistryPath = "HKLM:\SOFTWARE\Microsoft\Global Secure Access Client"

# Create the registry key if it doesn't exist (it should)
if (!(Test-Path $RegistryPath)) {
    New-Item -Path $RegistryPath -Force | Out-Null
}

# 0 = Disabled, 1 = Enabled
# This effectively puts the client in a coma without uninstalling it
New-ItemProperty -Path $RegistryPath -Name "UiMode" -Value 0 -PropertyType DWORD -Force
New-ItemProperty -Path $RegistryPath -Name "ForwardingEnabled" -Value 0 -PropertyType DWORD -Force

Write-Host "GSA Client neutered on $(hostname). Network traffic returning to direct path."

My Verdict: It is safe to click Activate. The danger isn’t the button; it’s the forwarding profile configuration that comes after. Treat those profiles like firewall rules—deny all by default, and allow only what you have tested.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions