If your organization is still running a traditional VPN, you’ve likely felt the strain: split tunneling debates, always-on configuration headaches, latency complaints from remote workers hitting a hub site before reaching the internet. Microsoft Entra Private Access offers a different model, one that’s worth a serious look for any shop already deep in the Microsoft stack.
This guide cuts through the marketing and focuses on what desktop and endpoint engineers actually need to know: how the architecture works, what you need to stand it up, and where it will bite you if you go in unprepared.
What Entra Private Access Actually Is
Entra Private Access is Microsoft’s Zero Trust Network Access (ZTNA) product, part of the Global Secure Access (GSA) framework alongside Microsoft Entra Internet Access. Together they form Microsoft’s Security Service Edge (SSE) solution.
The core idea: instead of routing all traffic through a VPN tunnel into your network perimeter, the GSA client on each device establishes a connection to Microsoft’s global network. From there, identity-aware policies determine what each user can reach. Your on-premises resources don’t need public IP addresses. Users don’t connect to “the network” — they connect to specific applications or subnets, with Conditional Access enforcing MFA, device compliance, and risk signals at each connection.
Microsoft has already deployed this internally. Over 158,000 employees are on the GSA client, with Private Access handling on-premises connectivity that previously ran through traditional VPN infrastructure.
There are two modes worth understanding: Quick Access and Per-App Access. Quick Access is the fastest path to VPN replacement, covering entire IP ranges and FQDNs the same way a VPN tunnel would. Per-App Access is more granular, giving you application-level segmentation. Most organizations start with Quick Access and layer Per-App policies on top over time.
Licensing and Prerequisites
You need one of the following:
- Microsoft Entra Suite (the all-in-one bundle that includes Entra ID P2, Entra Internet Access, Entra Private Access, and Entra ID Governance)
- Microsoft Entra Private Access as a standalone add-on (requires Entra ID P1 at minimum)
The Global Secure Access client runs on Windows 10 21H2 or later and Windows 11. macOS, iOS, and Android support exists but is in varying states of maturity. If you’re managing a Windows fleet through Intune, client deployment is straightforward.
On the infrastructure side, you need at least one server (Windows Server 2019 or later, or a supported Linux distribution) on-premises or in your hosted environment to run the Private Network Connector. This is the component that handles outbound connectivity from your network to Microsoft’s cloud. Think of it as the bridge between your internal resources and the GSA routing layer. It makes outbound connections only — no inbound firewall rules required, which removes a significant barrier for organizations with strict ingress policies.
Entra ID P1 is required for Conditional Access integration, which is the whole point of the architecture. If you’re on Entra ID Free, you can deploy Private Access but lose the policy enforcement layer that makes it meaningfully better than a VPN.
Architecture Before You Touch the Portal
Getting the architecture clear before you start clicking things will save you from misconfigurations that are annoying to untangle.
The traffic flow looks like this: the GSA client on the endpoint establishes a mutual TLS tunnel to the nearest Microsoft Global Secure Access point of presence. When the user tries to reach a private resource covered by your Quick Access policy, the request routes through that tunnel to the Private Network Connector running in your environment, which then reaches the internal resource on behalf of the user.
This has an important implication: your Private Network Connector must be able to reach the resources you’re trying to proxy. If you’re trying to reach resources on subnet 10.10.0.0/24, the server running the connector needs a route to that subnet. This sounds obvious but becomes a problem when connectors are placed in a DMZ without full internal routing.
Plan for redundancy early. You can deploy multiple connectors and group them into Connector Groups. Traffic to a given Quick Access segment routes only through the connectors in its assigned group. If all connectors in a group go offline, access to that segment fails. Two connectors per group minimum is the right starting point for production.
Setting Up Quick Access: Step by Step
This walkthrough assumes you have the licensing in place and at least one Windows Server ready for the connector.
Step 1: Enable Global Secure Access in the Entra Portal
Sign into entra.microsoft.com with a Global Administrator or Security Administrator account. Navigate to Global Secure Access in the left sidebar. If this is your first time, you’ll see a prompt to activate the service for your tenant. Activate it.
Step 2: Deploy the Private Network Connector
Under Global Secure Access > Connect > Connectors, download the connector installer. Run it on your on-premises server. The installer will prompt you to authenticate with an Entra admin account. This registration ties the connector to your tenant.
After installation, the connector should appear in the portal as Active. If it shows as inactive, check that outbound HTTPS (port 443) is allowed to *.msappproxy.net and *.servicebus.windows.net. These are the endpoints the connector uses to reach the Microsoft network.
Create a Connector Group (under Connector Groups) and assign your connector to it. Name it something meaningful, like the datacenter or site it serves.
Step 3: Configure Quick Access
Navigate to Global Secure Access > Applications > Quick Access. This is where you define what IP ranges and FQDNs the Private Access service will route.
Select your Connector Group. Then add the IP ranges or FQDNs of your internal resources. You can use CIDR notation for subnets (e.g., 10.10.0.0/16) or specific FQDNs. If you’re replacing a VPN that routes all RFC 1918 space, you can add all three private ranges here, though scoping more tightly is better for performance and troubleshooting.
Step 4: Deploy the Global Secure Access Client
The GSA client can be deployed via Intune as a Win32 app. Download the installer from the portal (under Global Secure Access > Connect > Client Download). Package it as a Win32 app using the standard Intune packaging workflow. The client requires no user interaction once deployed and runs as a service, authenticating using the device’s existing Entra ID session.
A silent install command looks like:
GlobalSecureAccessClient.exe /quiet /norestartDetection rule: check for the presence of C:\Program Files\Microsoft\Global Secure Access Client\GlobalSecureAccessClient.exe.
Step 5: Assign Users and Apply Conditional Access
Back in the portal, assign your Quick Access application to the appropriate user groups. Then create a Conditional Access policy that targets the All Private Access applications cloud app. Configure it to require MFA, compliant device, or whatever risk posture makes sense for your environment.
This is where the model pays off. Every connection to a private resource now goes through identity-aware policy evaluation. A user who gets flagged as high risk, or whose device falls out of compliance, loses private resource access automatically — no VPN config changes required.
Kerberos and NTLM: The Part That Will Surprise You
Modern cloud apps use token-based authentication and don’t care how the user got to the network. Your legacy on-premises systems almost certainly use Kerberos or NTLM, and this is where Private Access gets complicated.
When a user connects through the GSA client, their device is still Entra-joined (or hybrid-joined). Kerberos tickets for on-premises resources require a domain controller to issue them and the DC must validate the user’s identity before it will hand one over. With a traditional VPN, this is invisible: the machine is “on the network” and Kerberos just works.
With Private Access, you have two paths. The first is to make sure your Quick Access policy covers your domain controller subnets and that name resolution works through the connector (which usually requires setting up DNS suffixes in the Quick Access configuration). If the machine can reach a DC via Private Access, Kerberos will work, but it’s slower than a LAN connection and requires careful DNS setup.
The second path is to deploy the Private Access sensor on your domain controllers. This component, installed separately, redirects Kerberos pre-authentication through Microsoft Entra, enabling Conditional Access policy enforcement at the point of DC authentication. It’s more complex to set up but gives you far stronger security posture. For most migrations, you start with the first path and evaluate the sensor approach for high-security resources.
What This Doesn’t Replace
Entra Private Access handles remote access to on-premises resources cleanly. It does not replace:
Site-to-site connectivity. If you have branch offices that need connectivity to a central data center, you still need SD-WAN or traditional site-to-site VPN for that. Private Access is user-to-resource, not site-to-site.
Thick client VPN scenarios on non-Windows platforms. macOS support is available but lags Windows in feature parity. Linux and older Windows versions (pre-21H2) need alternative solutions.
Resources requiring inbound IP allowlisting. Some legacy systems or SaaS products only accept connections from specific IPs. Since users don’t egress from a predictable IP through Private Access, you’ll need to handle these cases separately or route specific traffic through a NAT gateway.
Migrating Off an Existing VPN
The cleanest migration path is to run Private Access alongside your existing VPN in parallel. Deploy the GSA client to a pilot group, cover the same IP ranges in Quick Access, and have users test connectivity. Compare support tickets, latency, and authentication experience. Extend the pilot before cutting over.
Don’t decommission VPN infrastructure until you’ve validated Kerberos authentication, DNS resolution, and your most-used on-premises applications. The applications that break first are usually ones with hard-coded IP dependencies or that rely on broad network access patterns rather than specific ports and services.
Plan for the fact that some users will notice the change — the GSA client is a persistent service that authenticates passively, but on first login after deployment, users may see an authentication prompt. Communicate what’s changing before it changes.
The payoff is real: per-app conditional access policies, identity-aware risk enforcement, and no VPN infrastructure to maintain. For organizations already invested in Entra ID and Microsoft security tooling, Private Access removes a significant architectural debt.