Global Secure Access Troubleshooting (2026): Fix GSA Client, PRT & Private Access Errors

Updated: July 6, 2026

Global Secure Access (GSA) troubleshooting in 2026 boils down to three checks: does the client see a valid Primary Refresh Token, is the user assigned to a traffic forwarding profile, and can the tunneling service reach Microsoft's Secure Service Edge (SSE)? If any of those fail, the client either silently disables itself, shows an empty policy, or forwards traffic to a black hole. This guide walks a helpdesk-first flow through the GSA client Health Check, log collection, Entra Private Access connector faults, and the June 2026 v2.31.125 changes, with the exact cmdlets, log paths, and correlation IDs I use on tickets.

• The GSA Windows client only supports Entra joined and Entra hybrid joined devices. Entra registered devices are not supported and will silently disable the client.
• A missing Primary Refresh Token (AzureAdPrt: NO) is the single most common root cause of "empty policy" tickets and must be fixed at the identity layer before anything else.
• Traffic forwarding profiles ignore nested Entra ID group membership. Assignments must be direct or via dynamic groups.
• Client v2.31.125 (released June 2, 2026) adds Intelligent Local Access (ILA), agentic-connection tunneling, and better local-network detection.
• Every GSA traffic log carries a correlation vector ID that lets you pivot from a user complaint to a specific policy match in under a minute.
• Bytes-sent greater than zero with bytes-received equal to zero on a Private Access flow almost always indicates a Private Network Connector or backend application fault, not a client issue.

What Global Secure Access is and why it replaces your VPN

Microsoft Global Secure Access is Microsoft's Security Service Edge (SSE) offering, delivered through two license SKUs: Entra Internet Access (which protects outbound traffic to internet apps) and Entra Private Access (which replaces point-to-site VPN for internal apps). Instead of a full-tunnel connection to a VPN concentrator, the GSA Windows client uses a lightweight tunneling service to send only the traffic that matches a policy profile up to the nearest Microsoft SSE edge point of presence. Everything else stays on the local network, which is where a lot of the tickets I get actually originate.

Where classic VPN failures look like "phase 2 timeout" or "IKE proposal mismatch" (still worth reading my VPN troubleshooting guide for those), GSA failures look completely different. There are no shared secrets, no IPsec SAs, no split-tunnel routes to argue about. The client is essentially an identity-driven policy enforcer: it authenticates as the signed-in user, downloads a forwarding profile from Entra ID, and then decides on a per-flow basis whether to tunnel a connection.

That shift moves the failure modes up the stack. Instead of "the tunnel is down," you get "the client thinks I don't have permission," "the profile is empty," or "the flow left the client but nothing came back." Almost every one of those maps to an identity, group assignment, or connector-health problem, not a network problem. Anchor your mental model there and 80% of the tickets solve themselves.

GSA client requirements and supported join states

Before you spend an hour tracing packets, verify the device is even eligible to run the GSA client. Per Microsoft's supported configuration matrix, only Entra joined and Microsoft Entra hybrid joined devices are supported. Entra registered devices (typical BYOD scenario) are not, and the client will refuse to load its policy. Honestly, that single fact catches roughly a quarter of the "it worked yesterday" tickets I've triaged since GSA rolled out.

Check join state before anything else with the built-in tool:

dsregcmd /status

In the output, look for the Device State block. You want:

• AzureAdJoined: YES (or DomainJoined: YES plus AzureAdJoined: YES for hybrid)
• WorkplaceJoined: NO (if this is YES and AzureAdJoined is NO, the device is Entra registered, a common misconfiguration on personal laptops)
• DeviceAuthStatus: SUCCESS

OS requirements as of mid-2026: Windows 10 22H2 or later, Windows 11 22H2 or later, and Windows Server 2019 or later for server workloads. macOS 13+ has a public preview client, Android/iOS have GA clients, and there is no client for Linux desktops yet. GSA on Linux is only supported through the Private Network Connector, not as an endpoint.

Also confirm the GlobalSecureAccessTunnelingService Windows service is present and running before you look at anything else:

sc query GlobalSecureAccessTunnelingService

# Expected output:
# SERVICE_NAME: GlobalSecureAccessTunnelingService
#         STATE              : 4  RUNNING
#         WIN32_EXIT_CODE    : 0  (0x0)

How do I collect Advanced Diagnostics logs from the GSA client?

Every GSA ticket I open with Microsoft support starts with the Advanced Diagnostics bundle, so let's make that the default first step. Right-click the GSA system tray icon, then Advanced Diagnostics. You get a tabbed window with Health Check, Forwarding Profile, Hostname Acquisition, and Advanced Log Collection. The Health Check tab alone answers most first-tier questions in about ten seconds.

Run through the tabs in this order (the order matters because each depends on the previous):

1. Health Check. Every row must be green. Pay attention to AzureAdPrt, Client Connectivity, and Tunneling Service Status. A red PRT row means nothing else will work; fix that first (see the PRT section below).
2. Forwarding Profile. Shows the currently loaded traffic forwarding profile and which app rules match. If this is empty, the policy has not been assigned to the user, or the user has no valid session.
3. Hostname Acquisition. A real-time list of every DNS name the client has intercepted and its match decision. Use this to prove whether the client actually saw a hostname you expected it to tunnel.
4. Advanced Log Collection. Starts an ETW trace. Reproduce the failure, then click Stop. It packages a ZIP with the tunneling ETL, service log, and configuration snapshot.

For the raw install and boot log (needed when the client fails to start at all), open:

C:\Users\%USERNAME%\AppData\Local\Temp\Global_Secure_Access_Client_%n%.log

where %n% is the install session number. That file captures MSI phase output plus service registration errors, and I have never seen a client install failure that wasn't already spelled out there in plain English by the third page.

Why is my Global Secure Access client "Disabled by your organization"?

This is the message the tray icon shows when the client believes the tenant, user, or device is not permitted to use GSA. There are five distinct causes, and they need to be checked in this exact order (checking them out of order wastes time, because a downstream fix cannot succeed if an upstream check is failing).

1. The tenant hasn't enabled the relevant traffic-forwarding profile. In the Entra admin center, go to Global Secure Access, then Connect, then Traffic forwarding. Confirm at least one of Microsoft 365, Internet Access, or Private Access is enabled (toggled on) at the tenant level.
2. The user isn't in the profile's assignment scope. On the same page, open the profile's Users and groups blade. As I'll cover in the profiles section, nested groups don't count.
3. The device is not Entra joined or hybrid joined. Confirmed via dsregcmd /status above.
4. A Conditional Access policy is blocking sign-in for the GSA client apps. Filter the Sign-in logs in Entra ID for application "Global Secure Access Client" and look for a failure with Conditional Access reason. Whitelisting is done through the standard CA UI. See my Entra Conditional Access troubleshooting guide for how to add exclusions.
5. The Microsoft 365 forwarding profile conflicts with a proxy. If the user's browser is configured to send all traffic to an on-premises proxy for M365 endpoints, the GSA client detects the collision and refuses to enable to prevent a loop.

Once you know which cause you're dealing with, the fix is usually a two-click change in the admin center or a single line in a group membership file. Don't skip the ordering. I've watched engineers rebuild a Conditional Access policy from scratch to fix a ticket whose real cause was a nested group assignment. Painful hour to watch.

How do I fix "No PRT" in the GSA client Health Check?

So, the Primary Refresh Token is the credential the GSA client uses to prove the user's identity to Microsoft SSE. When Health Check shows AzureAdPrt: NO, the client can authenticate the user but can't get a valid PRT, meaning no policy will ever load. This is the same PRT used by Windows Hello for Business, so fixes overlap.

Run dsregcmd /status and look at the SSO State block:

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+
             AzureAdPrt : NO
    AzureAdPrtUpdateTime : n/a
    AzureAdPrtExpiryTime : n/a
       AzureAdPrtAuthority : https://login.microsoftonline.com/<tenantid>
             EnterprisePrt : NO
      EnterprisePrtAuthority :

The four causes I see most often, in order of frequency:

• Kerberos tickets are stale. Sign out fully and sign back in. Don't just lock the screen. On a hybrid joined machine, disconnect from the corporate network first if the DC is unreachable to avoid a long timeout, then reconnect after login.
• Time skew. The client clock and the domain/tenant clock must be within five minutes. Force a resync: w32tm /resync /rediscover.
• WAM plugin missing or corrupted. Reregister the Windows Account Manager plugin by running dsregcmd /leave then dsregcmd /join, but only on Entra joined devices. On hybrid joined devices this needs a domain admin's approval and typically requires an Autopilot reset.
• The user is disabled, or the password was reset without the device online. Check the user object in Entra ID for accountEnabled: true and the last password change timestamp.

After any of these fixes, close the GSA client, wait 60 seconds, reopen it, and re-run Health Check. The tunneling service caches the PRT state for about a minute, so hitting refresh instantly will show stale data. (I've been caught by that more than once.)

Empty traffic forwarding profile: group assignment and CAE gotchas

An empty Forwarding Profile tab in Advanced Diagnostics is what shows up in tickets as "GSA is on but nothing is being tunneled." The tunneling service is running, PRT is green, the client is signed in, but no rules match. In every case I've triaged, one of three things is true.

Nested group assignment. This is documented but easily missed. If a traffic forwarding profile is assigned to Group A, and User X is a member of Group B, and Group B is a member of Group A, User X is not considered in scope. The engine does not expand nested membership for GSA profile assignments. Fix: assign to the innermost group that directly contains the users, or use a dynamic membership rule.

Assignment change hasn't propagated. After you add a user to an assigned group, expect 15 to 30 minutes before the client picks up the new profile, plus one client restart if the user was already signed in. To force it faster:

# Restart the tunneling service to force a fresh policy pull
Restart-Service GlobalSecureAccessTunnelingService

# Then trigger a full client reconnect
Stop-Process -Name "GlobalSecureAccessClient" -Force
Start-Process "C:\Program Files\Global Secure Access Client\GlobalSecureAccessClient.exe"

Continuous Access Evaluation revoked the session. GSA participates in CAE, so a risk event or IP change can revoke the client session and effectively empty the profile mid-flight. The Sign-in logs will show a "CAE token revoke" event. Have the user sign out and back in; if it recurs, review the Conditional Access risk policies that are triggering.

Entra Private Access: bytes sent greater than zero, bytes received zero

Entra Private Access replaces point-to-site VPN for reaching internal apps through a Private Network Connector. When you look at the Traffic logs in the admin center and see a flow with a nonzero bytesSent value but bytesReceived: 0, the client and the SSE edge are working correctly. The problem is downstream, either the connector or the backend app itself.

Work through the connector layer in this order:

1. Connector health. Global Secure Access, then Connect, then Connectors. Every connector should show a green status and a recent last-heartbeat timestamp (within the last 10 minutes). A yellow or red state means the connector cannot reach Microsoft's cloud, usually a proxy or firewall egress issue on the connector host.
2. Connector groups and app segment mapping. Confirm the app segment (FQDN or IP range) is assigned to a connector group that actually contains a healthy connector. This is a common mistake right after adding a new segment.
3. Synthetic IP / DNS resolution on the client. Private Access assigns each FQDN a synthetic IP in the 6.6.0.0/16 range. On the client, nslookup app.corp.example.com should return an IP in that range once the app segment is loaded. If it returns a real internal IP, the client is going out the local interface and bypassing GSA. Check for local DNS overrides or a hosts file entry.
4. Backend service. From the connector host itself, Test-NetConnection app.corp.example.com -Port 443. If that fails from the connector, GSA is doing exactly what it should. The app is genuinely unreachable from your network.

The recurring theme: bytes-received of zero is almost never the client's fault. Look downstream of the SSE edge first.

Traffic log investigation with the correlation vector ID

Every network flow that traverses GSA carries a correlation vector ID that appears in both the client-side diagnostics and the Traffic logs in the Entra admin center. Using it well is the single fastest way to close user tickets, and it's the workflow I train helpdesk staff on first.

The user-side flow:

1. User reports "I can't reach app X."
2. Have them reproduce while Advanced Log Collection is running.
3. Stop the collection. Open the resulting ZIP and locate the network_flows.json file. Search for the destination hostname.
4. Copy the correlationVector value for that flow.
5. In the Entra admin center, go to Global Secure Access, then Monitor, then Traffic logs, and filter by Correlation Vector equals your value.

The matching log entry tells you the policy that matched (or didn't), the destination, action taken (allow/block), transaction time, connector used, and byte counters. Ninety percent of tickets can be closed at this point:

• Action: Block. A policy is intentionally blocking; check the profile.
• Action: Allow, bytesSent > 0, bytesReceived = 0. Downstream connector or app issue (see previous section).
• No matching log entry. The client never tunneled the traffic; check Hostname Acquisition and confirm the destination matches an app rule.

The connector ID in the log also lets you correlate against connector-side logs on the Windows Server hosting the Private Network Connector, which live at %ProgramData%\Microsoft\Entra Private Access Connector\Logs. If the flow reached the connector but was rejected, you'll find the rejection reason (DNS failure, TCP RST from the app, TLS handshake failure) in ConnectorTrace.log.

What's new in GSA client v2.31.125 (June 2026)

Microsoft released Windows client v2.31.125 on June 2, 2026, and it's meaningfully better on flaky-network scenarios that helpdesk teams see all the time. If you're still on any 2.30.x build, upgrade. The diagnostics alone are worth the roll. The full Windows client release history is worth bookmarking.

The three changes that matter for troubleshooting:

• Intelligent Local Access (ILA). The client now maintains a trusted-private-network profile per site. When it detects it's on a known internal network (matching a configured egress IP or connectivity probe), it skips tunneling for certain traffic classes that would otherwise round-trip through SSE. This dramatically reduces "why is Teams slow at HQ" tickets, but it also changes what you see in Hostname Acquisition. Hostnames that used to be tunneled will now show as "local access" when on-site.
• Agentic-connection tunneling. New support for long-lived, server-initiated connections (used by remote assistance agents and some management tools). Previous builds would silently drop these after a keepalive window.
• Granular network-state detection. The tunneling service now distinguishes between "no internet," "internet but no SSE connectivity," and "SSE reachable but authentication failing." The tray icon color and Health Check text now reflect this, greatly reducing "the client says something is wrong but I don't know what" complaints.

Rollout considerations: v2.31.125 is a signed MSI, so Intune Win32 app deployment is straightforward. Pilot on 50 to 100 devices for a week before broad rollout, and watch the Hostname Acquisition tab for ILA reclassifications you didn't expect. Anything that used to tunnel and now doesn't should be intentional. Richard Hicks' deep-dive on v2.31.125 covers the ILA policy engine in more depth than Microsoft's release notes.

A repeatable GSA troubleshooting runbook

When a ticket comes in, work through this checklist. It's the runbook we use on my team, and following it in order handles about 95% of GSA cases in under 15 minutes. Print it, laminate it, whatever, but don't freelance the order.

1. Confirm client version. Tray icon, then About. If below v2.31.125, upgrade first. You may fix the ticket for free.
2. Run dsregcmd /status. Verify AzureAdJoined: YES or hybrid, and AzureAdPrt: YES. If either is wrong, fix identity first.
3. Open Advanced Diagnostics → Health Check. All rows green. If a row is red, that's the ticket.
4. Check the Forwarding Profile tab. Empty? Verify tenant profile enablement and direct (non-nested) user or group assignment.
5. Run Advanced Log Collection during a reproduction. Capture the correlation vector for the failing flow.
6. Search Traffic logs in the admin center by correlation vector. Read the action, byte counters, and connector fields.
7. If Private Access: check connector health and connector-side ConnectorTrace.log.
8. If still stuck: Attach the Advanced Log Collection ZIP, the install log, and the correlation vector ID to a Microsoft support ticket. Reference the official GSA client Health Check reference for the exact row names.

Frequently Asked Questions

Does Global Secure Access work on Microsoft Entra registered (not joined) devices?

No. The Windows GSA client only supports Microsoft Entra joined and Microsoft Entra hybrid joined devices. Entra registered devices, typical for BYOD scenarios, cannot load the GSA policy and the client will show as disabled. To use GSA on BYOD, either fully Entra join the device or provision a corporate-managed device.

How long does it take for a Global Secure Access policy assignment to reach a client?

Between 15 and 30 minutes for new group assignments, and often faster after a client restart. To force an immediate refresh, restart the GlobalSecureAccessTunnelingService service and then relaunch the GSA client process. If it still doesn't apply, verify the user isn't sitting behind a nested group assignment, which isn't honored.

Can I run Global Secure Access alongside a traditional VPN client?

Yes, but only carefully. Route conflicts on the same destinations will confuse both stacks. Best practice is to disable overlapping VPN forwarding rules (or the whole VPN connection) when a GSA profile covers the same apps. For phased migrations, use split-scope: keep VPN for legacy protocols, migrate HTTPS-based apps to Entra Private Access first.

Why does the GSA client sometimes show "SSE reachable but authentication failing"?

That state (introduced in v2.31.125) means the tunneling service can reach a Microsoft SSE edge but the user's PRT or session token is not accepted. Usual causes: expired PRT, Conditional Access revocation via CAE, or a disabled user object. Run dsregcmd /status to inspect PRT state and check the Entra sign-in logs for the "Global Secure Access Client" application.

Where are the Global Secure Access client logs stored on Windows?

Installer and boot logs live at C:\Users\%USERNAME%\AppData\Local\Temp\Global_Secure_Access_Client_%n%.log. Runtime ETW traces are collected on demand via Advanced Diagnostics, then Advanced Log Collection, which packages them into a ZIP suitable for Microsoft support. Private Network Connector-side logs live under %ProgramData%\Microsoft\Entra Private Access Connector\Logs on the connector host.