PAWs and Global Secure Access: Build a Fail-Close Internet Backstop

A privileged access workstation (PAW) exists to perform sensitive administration from a hardened device. Its security posture is defined not only by normal operation, but by what happens when a protective control disappears.

In a September 14, 2026 post on the Microsoft Tech Community Core Infrastructure and Security blog, Microsoft consultants Christian Friedel-Jain and James Noyce describe a field-tested pattern for that failure mode. Microsoft Entra Internet Access, part of Global Secure Access, gives a PAW identity-centric web filtering. But in their words, the client's current default when it hits a problem is fail-open. Their design adds a fail-close backstop with Windows Firewall, Intune custom compliance and Conditional Access.

The lesson is architectural: keep GSA as the central policy and logging layer, but make the PAW stop trusting the internet the moment GSA is not protecting it. Treat the published scripts as examples, not a production package.

Why this matters for small and mid-sized businesses

Smaller IT teams often have a handful of people holding Global Administrator, Intune Administrator or Exchange Administrator rights, and those people usually admin from the same laptop they use for everything else. Moving them onto a PAW, or a locked-down admin profile, is one of the highest-value hardening steps available. If you then use Entra Internet Access to restrict that PAW, you need to know what happens when the client fails.

• Who is affected: any organization using GSA Internet Access as the only web restriction on admin devices.
• What breaks: if the client loses its tunnel, is disabled by a user, has its services stopped, or is never installed, the PAW can browse anywhere. Phishing pages and malicious downloads become reachable from the most trusted device you own.
• Cost of ignoring it: a compromised admin workstation is a tenant-wide incident. The backstop costs some engineering and testing time; recovering from a stolen admin session costs far more.

The control gap at a glance

How the fail-close pattern works

The design uses two independent layers. The network layer reacts quickly to client events. The identity layer catches the cases the firewall cannot see.

1. Network layer: switch Windows Firewall profiles

• Base policy: block all inbound and outbound traffic on the Domain, Private and Public profiles, then allow only what is listed.
• Private profile ("unrestricted" HTTP(S)): a "World Wide Web Services (HTTP & HTTPS Out)" rule allows TCP 80 and 443 to any address. GSA does the filtering.
• Public profile ("restricted" HTTP(S)): the same rule allows TCP 80 and 443 only to Dynamic Keyword FQDN groups: GSA edge endpoints, Microsoft 365 Common and Office Online, Microsoft 365 encryption chains, Windows 11, Intune and Autopilot, and Defender for Endpoint.
• Always-allowed rules (about 35): DHCP, DNS, time, NCSI, the GSA client executables, Defender services, the Intune Management Extension, Windows Update, LSASS, Company Portal and similar. The authors say this list is not complete.

When the GSA client establishes the Internet Access tunnel it writes Event ID 142 (channel Internet) to the GSA client operational log. A scheduled task runs Set-NetworkPrivate.ps1, which checks that all four GSA services are running and only then sets the network to Private. If not, it sets Public and triggers an Intune compliance sync.

A second task watches for failure events and runs Set-NetworkPublic.ps1:

• Event ID 141: Entra or Internet Access tunnel disconnected (logged roughly every 10 seconds while down)
• Event IDs 106, 206, 406, 705: GSA services stopped
• Event ID 638: no internet connectivity
• Event ID 701: services start initiated

These IDs come from the source post, not from a published Microsoft Learn event reference. Confirm them on the client version you deploy.

2. Identity layer: custom compliance plus Conditional Access

If the client is not installed, or its services never start, there may be no event to react to. An Intune custom compliance discovery script checks that the four services exist and are running:

• GlobalSecureAccessClientManagerService
• GlobalSecureAccessEngineService
• GlobalSecureAccessForwardingProfileService
• GlobalSecureAccessTunnelingService

The script returns GSAinstalled (Boolean) and GSArunning (count). The JSON rules require true and 4. A Conditional Access policy requiring a compliant device then blocks the PAW from Entra ID integrated resources. The sample script also flips the firewall to Public when it finds a problem.

Why not just use the old URL Lock Proxy?

Older PAW builds restricted browsing with a local allow-list enforced through Windows Firewall and a "URL Lock Proxy". The post lists its limits: no auditing, heavy use of wildcards, a registry-size cap on the rule set, and poor scale. GSA gives centrally managed, auditable policy and URL-level filtering through TLS inspection. The fail-close design keeps a small firewall allow-list only for the failure state.

Licensing and prerequisites

Step-by-step: build a fail-close PAW with GSA and Intune

Step 1: Baseline GSA for the PAW

1. Microsoft Entra admin center > Global Secure Access > Connect > Traffic forwarding. Enable the Internet access profile and the Microsoft traffic profile (Microsoft recommends enabling both). Scope them to the PAW users or devices.
2. Build the PAW security profile and web content filtering policy that allows only approved admin portals, Entra authentication, Intune and Defender, and link it through Conditional Access.
3. Microsoft Entra admin center > Global Secure Access > Connect > Client download. Package the client as a Win32 app in the Microsoft Intune admin center > Apps > All apps > Add > Windows app (Win32), following Microsoft's documented script, which also sets IPv4 preferred.
4. Stop users from switching the client off. Deploy the documented registry values with an Intune remediation (Microsoft Intune admin center > Devices > Scripts and remediations), run in 64-bit PowerShell.

# HKLM\SOFTWARE\Microsoft\Global Secure Access Client (documented on Microsoft Learn)
$gsaPath = "HKLM:\SOFTWARE\Microsoft\Global Secure Access Client"
if (-not (Test-Path $gsaPath)) { New-Item -Path $gsaPath -Force | Out-Null }
# 1 = non-admins get a UAC prompt to disable/enable the client
Set-ItemProperty -Path $gsaPath -Name RestrictNonPrivilegedUsers -Value 1 -Type DWord
# 1 = hide the Disable menu item
Set-ItemProperty -Path $gsaPath -Name HideDisableButton -Value 1 -Type DWord
# Keep these hidden (default)
Set-ItemProperty -Path $gsaPath -Name HideSignOutButton -Value 1 -Type DWord
Set-ItemProperty -Path $gsaPath -Name HideDisablePrivateAccessButton -Value 1 -Type DWord

Step 2: Inventory dependencies

1. List every portal, Entra endpoint, Intune service, Defender path, update source and recovery destination the PAW needs while restricted.
2. Start from Microsoft's published lists: GSA edge endpoints, Microsoft 365 URLs and IP ranges, Windows 11 Enterprise connection endpoints, Intune network endpoints and Defender for Endpoint streamlined connectivity URLs.
3. Record the GSA client version, service names, current firewall rules and Conditional Access assignments.

Step 3: Build Dynamic Keyword groups (reusable settings)

1. Microsoft Intune admin center > Endpoint security > Firewall > Reusable settings (preview) tab > Add.
2. Create one group per endpoint category using FQDN definitions with auto-resolution. Each group holds up to 100 instances, so split large categories.
3. Optional: bulk-create groups with Microsoft Graph. The source post uses the beta deviceManagement/reusablePolicySettings endpoint. A minimal read check:

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/beta/deviceManagement/reusablePolicySettings" |
  Select-Object -ExpandProperty value |
  Select-Object displayName, settingDefinitionId

Step 4: Build the firewall profiles

1. Microsoft Intune admin center > Endpoint security > Firewall > Create policy > Platform Windows > Profile Windows Firewall: enable all three profiles with default outbound and inbound action Block.
2. Create a Windows Firewall rules profile (up to 150 rules per profile; profiles merge on the device). Add the always-allowed program and service rules.
3. Add the Private "World Wide Web Services (HTTP & HTTPS Out)" rule: TCP 80, 443, any remote address.
4. Add the Public version of the same rule with action Allow, then Set reusable settings and select your Dynamic Keyword groups.

Step 5: Handle enrollment

1. Deploy a platform script (Microsoft Intune admin center > Devices > Scripts and remediations > Platform scripts) that updates Defender so the FQDN feature works: & "C:\Program Files\Windows Defender\MpCmdRun.exe" -SignatureUpdate -MMPC.
2. Deploy a second platform script that sets the network to Private during enrollment so the device is not stuck on the restricted profile before the tasks exist.

Step 6: Deploy the event-triggered tasks

1. Package GSA-Connected.xml, GSA-Disconnected.xml, Set-NetworkPrivate.ps1 and Set-NetworkPublic.ps1 as a required Win32 app.
2. Make it depend on the GSA client app. Microsoft's authors note an event-triggered task can only be created once the event log exists.
3. Register the tasks to run as SYSTEM:

Register-ScheduledTask -Xml (Get-Content "$PSScriptRoot\GSA-Connected.xml" | Out-String) -TaskName 'GSA-Connected'
Register-ScheduledTask -Xml (Get-Content "$PSScriptRoot\GSA-Disconnected.xml" | Out-String) -TaskName 'GSA-Disconnected'

The core of the published failure script:

$NetworkName = (Get-NetConnectionProfile).Name
Set-NetConnectionProfile -Name $NetworkName -NetworkCategory Public
Start-Process -FilePath "C:\Program Files (x86)\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe" `
  -ArgumentList "intunemanagementextension://synccompliance"

Step 7: Add the compliance backstop

1. Microsoft Intune admin center > Endpoint security > Device compliance > Scripts > Add > Windows 10 and later. Paste the discovery script, run it in the System context and set Run script in 64 bit PowerShell Host to Yes. The last line must be return $hash | ConvertTo-Json -Compress.
2. Microsoft Intune admin center > Devices > Manage devices > Compliance > Create policy > Windows 10 and later. Under Custom Compliance set Require, select the script and upload the JSON rules (GSAinstalled equals true, GSArunning equals 4). Assign it to the PAW device group.
3. Microsoft Entra admin center > Entra ID > Conditional Access > Policies > New policy. Target your admin accounts, exclude break-glass accounts, grant Require device to be marked as compliant, and start in Report-only.

Gotchas

• The client's own fallback isn't something you can count on. Learn says fallback to direct or block is decided by each forwarding rule's hardening value. The portal does not document a setting for it, and it does not help when the client is disabled, stopped or removed.
• IPv6 bypasses GSA. The client tunnels only IPv4 and sends IPv6 straight to the network. Set IPv4 preferred, as Microsoft's install script does.
• QUIC and secure DNS. Internet Access does not tunnel QUIC (UDP 80/443) and the client does not support DoH, DoT or DNSSEC. Dynamic Keyword FQDN rules also need DoH off. Disable both in Edge and Chrome through the Intune settings catalog.
• Dynamic Keywords resolve lazily. FQDN rules only learn IPs after a DNS query is observed, resolved IPs are flushed on restart, and a fast app can be blocked on the first try. A rule with only unresolved AutoResolve objects isn't enforced.
• Reusable settings groups are in public preview and hold up to 100 instances each.
• Custom compliance is slow by default. Discovery scripts run every eight hours, and push notifications cannot trigger them. That is why the sample scripts call the Intune Management Extension synccompliance handler directly.
• The local admin path still exists. RestrictNonPrivilegedUsers only adds a UAC prompt. PAW users should not be local admins.
• Hyper-V and WSL. The client is not supported on a host with a Hyper-V external virtual switch, and WSL 2 traffic may be blocked unless DNS tunneling is turned off.
• Unsupported samples. Microsoft states the sample scripts are not covered by any standard support program. The firewall and FQDN lists are also shared as-is and are incomplete.

How to verify it worked

Portal checks

1. Microsoft Intune admin center > Reports > Device compliance > Reports tab > Noncompliant devices and settings: confirm the PAW reports the custom settings and goes non-compliant when you stop a GSA service.
2. Microsoft Intune admin center > Reports > Firewall > MDM Firewall status for Windows: confirm the firewall is Enabled.
3. Microsoft Entra admin center > Entra ID > Monitoring & health > Sign-in logs: check the report-only result for the compliant-device policy.
4. On the PAW, open the GSA client Advanced diagnostics and confirm Internet traffic is acquired under the Internet channel.

On the device (PowerShell, run as admin)

# GSA services and current network category
Get-Service -Name GlobalSecureAccess* | Select-Object Name, Status
Get-NetConnectionProfile | Select-Object Name, NetworkCategory

# Client lock-down values
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Global Secure Access Client" |
  Select-Object RestrictNonPrivilegedUsers, HideDisableButton

# Dynamic Keyword FQDNs and what they have resolved to so far
Get-NetFirewallDynamicKeywordAddress -AllAutoResolve

# Find the GSA log, then read connect/disconnect events
$log = (Get-WinEvent -ListLog "*Global Secure Access*" | Select-Object -First 1).LogName
Get-WinEvent -FilterHashtable @{ LogName = $log; Id = 141, 142 } -MaxEvents 20

Then stop a GSA service (as admin) and confirm the category flips to Public, a non-approved site fails, and Intune, Defender and sign-in keep working.

Compliance state from Microsoft Graph

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -Filter "startswith(deviceName,'PAW')" |
  Select-Object DeviceName, ComplianceState, LastSyncDateTime

Blocked connections in Defender advanced hunting

The source post's starting query (Microsoft Defender portal > Investigation & response > Hunting > Advanced hunting):

DeviceNetworkEvents
| where DeviceName == "paw"
| where LocalIPType == "Private" and RemoteIPType == "Public"
| where ActionType == "ConnectionFailed"
| sort by Timestamp desc

All columns are in the DeviceNetworkEvents schema. DeviceName holds the device FQDN, so in practice use startswith or has on your PAW naming prefix, and add RemoteUrl, RemotePort and InitiatingProcessFileName to see what was blocked. Sort the results into expected denials and real dependencies, and handle the second group through a reviewed exception, not by opening the profile.

Testing matrix

Frequently asked questions

Why is Global Secure Access fail-open behavior a problem on a PAW?

A privileged access workstation is trusted to administer sensitive systems. The source post says that, by default today, the GSA client falls back to fail-open when it cannot reach the GSA edge, is suspended, has its services disabled, or is not installed. On a PAW that means the device has unfiltered internet access at the moment its main web control has failed.

Doesn't the GSA client already have a block-on-failure option?

Microsoft Learn says that on a connection error to the cloud service, the Windows client falls back to either a direct connection or blocking, based on the hardening value of the matching rule in the forwarding profile. Learn does not document an admin setting to choose that value, and it does not cover a client that is disabled, stopped, or missing. Treat the firewall and compliance layers as the control you own.

What is the fail-close design Microsoft's consultants describe?

Two layers, both deployed with Intune. A network layer uses Windows Firewall network profiles: Private allows normal HTTP(S) so GSA does the filtering, and Public limits HTTP(S) to Dynamic Keyword FQDNs. Event-triggered scheduled tasks switch profiles. An identity layer uses an Intune custom compliance check plus a Conditional Access policy requiring a compliant device, so a missing or stopped client blocks access to Entra ID integrated resources.

Which GSA events trigger the profile switch?

In the source example, Event ID 142 with channel Internet (Internet Access tunnel connected) moves the device to Private after a service check. Event ID 141 (Entra or Internet tunnel disconnected), 106, 206, 406 and 705 (services stopped), 638 (no internet connectivity) and 701 (services start initiated) move it to Public. Confirm the IDs on the client version you deploy.

What licenses do we need?

Microsoft Entra ID P1 or P2 as the prerequisite, plus Microsoft Entra Internet Access or Microsoft Entra Suite for the Internet Access profile. You also need Intune for the firewall, scripts and compliance policy, and Microsoft Defender Antivirus on platform 4.18.2209.7 or later for FQDN-based Dynamic Keywords. The DeviceNetworkEvents hunting table is populated only by Microsoft Defender for Endpoint.

Can we copy Microsoft's sample scripts straight into production?

No. The post states the sample scripts are not supported under any Microsoft standard support program and are provided as-is, and the authors say their list of mandatory programs and services is not complete. Use them as a design reference, test in a pilot ring, sign and version your own scripts, and put the final build through change control.