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 therefore has to be defined not only by normal operation, but by what happens when a protective control disappears.

In a September 14, 2026 Microsoft Security post, Christian Friedel-Jain and James Noyce describe a field-tested pattern for that exact failure mode: Microsoft Entra Global Secure Access (GSA) can provide identity-centric web filtering for a PAW, but the current client behavior is fail-open when the client cannot connect, is suspended, or is not installed. Their design adds a fail-close backstop with Windows Defender Firewall, Intune custom compliance, and Conditional Access.

The important lesson for Microsoft 365 and security teams is architectural. Keep GSA as the central policy and visibility layer, but make the PAW lose internet trust the instant GSA is unavailable. Treat the source scripts as implementation examples, not a copy-and-paste production package.

The control gap at a glance

Why fail-open is the wrong default for a PAW

Global Secure Access is Microsoft’s umbrella for Entra Internet Access and Entra Private Access. For a PAW, the relevant component is Entra Internet Access: an identity-centric secure web gateway that can apply a fine-grained destination policy, web content filtering, TLS inspection, and threat intelligence.

That model assumes the GSA client is installed, running, and connected to the GSA edge. If the client loses its tunnel, its services stop, it is suspended, or it is removed from the device, the current default is fail-open: traffic is no longer filtered by GSA. On an ordinary endpoint that may preserve usability. On a workstation holding privileged sessions, it creates the worst possible sequence—protection disappears and exposure expands at the same time.

Do not frame this as a GSA product failure. It is a design decision about what a privileged endpoint should do under uncertainty. A PAW should preserve only the connections needed to recover and manage the device until the trusted control plane is healthy again.

The two-layer fail-close pattern

Microsoft’s example uses two independent enforcement layers, both delivered through Intune. The separation matters: the network layer reacts quickly to client events, while the identity layer catches cases the firewall cannot observe.

1. Network layer: switch Defender Firewall profiles

Use two Windows Defender Firewall network profiles as operating modes:

• Private profile: the firewall does not constrain HTTP(S) destinations; GSA Internet Access performs the filtering.
• Public profile: outbound web traffic is restricted to a mandatory set of FQDNs through Defender Dynamic Keywords and selected system processes.

When the GSA client establishes the Internet Access tunnel, it writes a successful connection event (Microsoft’s example uses Event ID 142). An event-triggered scheduled task can validate the local services and move the device to the Private profile. When GSA disconnects or a service stops, a second task moves the device to the Public profile, where only the approved recovery and management paths remain reachable.

The source example watches for tunnel disconnects and service or connectivity changes including Event IDs 141, 106, 206, 406, 638, 701, and 705 in the Microsoft-Windows-Global Secure Access Client-Operational log. Confirm the event names and channels in the client version you deploy before writing production triggers.

2. Identity layer: custom compliance plus Conditional Access

A network event cannot help if the GSA client is missing entirely or its services never start. Add an Intune custom compliance check that verifies the client is installed and that all required GSA services are running. Pair the compliance result with a Conditional Access policy that denies protected administration when the PAW is not compliant.

This layer turns an invisible absence into an explicit identity signal. It also gives the security team a place to require remediation and provide a documented link for the operator. Keep the policy scoped to the privileged access path, test it in report-only mode, and preserve a carefully controlled break-glass route for recovery.

Why the old URL Lock Proxy approach is not enough

Many PAW designs began with a local URL allow-list enforced by Windows Defender Firewall. That pattern can block everything except approved portals, Entra authentication, Intune, and Defender for Endpoint, but it becomes difficult to operate as the destination set grows. Microsoft’s post calls out the lack of auditing, brittle wildcard rules, registry size limits, and poor scalability.

GSA improves the steady-state experience with centralized policy, auditable decisions, and URL-level filtering through TLS inspection. The right migration is not to abandon the allow-list principle; it is to move normal filtering to GSA and retain a smaller, maintainable firewall allow-list for the failure state.

A practical implementation sequence

1. Establish the dependency baseline

• List every administration portal, Entra endpoint, Intune service, Defender for Endpoint path, update source, monitoring channel, and recovery destination the PAW requires.
• Record the GSA client version, service names, event log channel, network profiles, current firewall rules, and Conditional Access assignments.
• Identify enrollment, reset, patching, and break-glass scenarios that must continue working while the device is restricted.

2. Build the restricted firewall state

Create the Public-profile outbound rule set with Defender Dynamic Keywords and explicit process exemptions for mandatory services. Keep the FQDN list intentionally small. Every exemption should have an owner, a business reason, and a review date.

3. Automate profile transitions

Deploy the event-triggered tasks and scripts as an Intune Win32 app or equivalent managed package. The normal-state script should validate GSA services before selecting the unrestricted profile; the failure-state script should make the restricted profile the safe default. Sign and version the scripts, log each transition, and make the profile change idempotent.

4. Add the compliance backstop

Use a custom compliance script to return a small, auditable result such as whether GSA is installed and how many required services are running. Define the compliance policy so a missing client or incomplete service set is non-compliant, then connect that state to Conditional Access for privileged portals.

5. Test failure, not just deployment

Monitor the restricted state as an operating mode

Fail-close is a security control, but it is also an operational signal. Microsoft recommends using the local security event log to understand profile transitions and Microsoft Defender advanced hunting to review blocked connections while the PAW is restricted.

A simple starting query from the source post is:

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

Use the results to separate two conditions: an expected denial of an unapproved destination, and a legitimate management dependency that the restricted rule set forgot to allow. Feed the second condition into a controlled exception process rather than broadly opening the PAW.

Guardrails before production

• Keep the restricted path usable: Intune, Defender for Endpoint, authentication, patching, and monitoring must remain available or the device may be secure but unrecoverable.
• Design for enrollment: the firewall profile and Defender platform prerequisites may need a temporary bootstrap sequence before the normal fail-close controls can take over.
• Scope Conditional Access carefully: protect privileged portals and sessions without creating a tenant-wide lockout during a GSA incident.
• Document exceptions: every FQDN, process, and break-glass path should have an owner, expiry or review date, and evidence of testing.
• Use change control: Microsoft states that the sample scripts are unsupported and provided as-is. Review, test, sign, and version your own implementation.

Frequently asked questions

Is Global Secure Access still useful if it fails open? Yes. GSA provides the central policy, filtering, and audit layer in normal operation. The firewall and compliance controls close the failure gap for a privileged endpoint.

Why use both a firewall profile and Conditional Access? They catch different failure modes. The firewall reacts to tunnel and service events, while custom compliance catches a missing client or services that never start.

Should every workstation use this pattern? Start with PAWs and other devices that hold privileged sessions. The tighter restricted state and operational overhead should match the sensitivity of the device.

What if the Public profile blocks a required service? Treat it as a test failure. Identify the exact dependency, add the narrowest reviewed exemption, and re-run enrollment, management, patching, and recovery tests.

What is the first step? Inventory the PAW’s required destinations and failure signals, then prove that a disconnected or missing GSA client cannot leave the device with unrestricted internet access.