Why full tunnel VPN is an obsolete model
A remote access VPN does two things simultaneously, and that's exactly what complicates its migration. It carries access to internal resources — SMB shares, RDP, business applications, Domain Controllers — and, in virtually all audited configurations, it also backhauled remote workstation Internet traffic to the datacenter to route it through the corporate Proxy and Firewall. This backhaul explains why users have complained about Teams latency for years: every SaaS packet makes an unnecessary round trip to the central site.
Global Secure Access is Microsoft's SSE platform. This term covers two distinct products that must absolutely be separated before beginning:
- Entra Private Access: the ZTNA, which grants per-application access to private resources without ever exposing the underlying network. It, and only it, replaces the VPN.
- Entra Internet Access: the identity-aware Secure Web Gateway, which filters and inspects traffic to the Internet and SaaS. It replaces the outbound Proxy that your VPN was feeding with backhaul — not the VPN itself.
Both products rely on the same client and the same Microsoft global network, distributed across more than 70 regions and 190 edge points of presence. The fundamental difference with VPN can be summed up in one sentence: VPN grants network access, Private Access grants application access. You no longer publish a /24 subnet, you publish an FQDN, a port, and a protocol, to which you attach a Conditional Access.
Vocabulary to retain
Global Secure Access is the umbrella term and the name of the portal in the Entra administration center. Internet Access and Private Access are the two underlying products. Many projects confuse the three and deploy the SWG thinking they're replacing the VPN. You deploy both, but not for the same reason.
Prerequisites: licenses, roles, and infrastructure
Before executing any command, validate every point on this list. A missing prerequisite in production costs hours of diagnosis.
| Element | Detail |
|---|---|
| Licenses | Entra ID P1 or P2 mandatory. On top: Entra Private Access add-on alone, or Entra Suite (includes Private Access, Internet Access, ID Governance, ID Protection, Verified ID). Since May 1, 2026, Microsoft 365 E7 includes the Entra Suite. Check current pricing on the Microsoft pricing page. |
| Entra roles | Global Secure Access Administrator AND Application Administrator simultaneously. Just one of the two is not enough to activate profiles. |
| Connector server | Windows Server 2016 minimum (2022 or 2025 recommended), domain-joined, .NET 4.7.2 or higher, TLS 1.2 enabled. Outbound 80/TCP and 443/TCP to Microsoft endpoints. No inbound ports to open. |
| Client workstations | Windows 10 or 11 64-bit, Entra joined or Hybrid joined. A simply registered workstation doesn't work. |
| Internal DNS | DNS suffixes of each AD forest hosting synchronized users, documented and ready to be declared. |
| Remote Network Connectivity | Minimum 50 P1 and Internet Access combined licenses on the tenant for site-to-site connectivity. |
Step 1 — Map the flows actually carried by the VPN
No Azure commands in this step, yet it's what determines the success of the project. You cannot publish in per-app access what you have not identified. Extract the VPN concentrator configuration, list each rule, and translate it into an application triplet: FQDN or IP range, port, protocol.
Three categories emerge from this exercise:
- Identified application flows: one application, one port, one known usage → per-app access at step 4.
- Infrastructure flows: Domain Controllers, DNS, file servers, administration tools → processing at step 5.
- Orphaned flows: rules whose usage nobody knows → don't migrate by default. Instrument, observe actual traffic for two weeks, then decide.
Cross-reference declarative config and flow logs
In an audit of an industrial environment, the gap between the declared concentrator configuration and the traffic actually observed in Firewall logs represented 11 rules out of 19 — more than half of the broad network access was serving nothing anymore. Never trust configuration alone.
Validation deliverable: a table where each row carries an application name, one or more segments (FQDN or IP + port + protocol), a user population, and a category among application, infrastructure, or orphaned. No row without identified population. This table becomes your publication plan.
Step 2 — Enable Global Secure Access and traffic forwarding profiles
Head to the Entra administration center, Global Secure Access section. Activation happens profile by profile. Start with the Microsoft 365 profile: it's the least risky and serves as a canary to validate that traffic acquisition works before touching anything else.
Trap of default assignment
When you enable a traffic forwarding profile without specifying a scope, it applies by default to all users on the tenant. On a pilot, that's exactly what you don't want. Assign the profile to a pilot group BEFORE activating it, never after. This reversal of order is the #1 cause of incidents early in the project.
The Private Access profile is activated from Global Secure Access > Connect > Traffic forwarding. You can automate state reading via Microsoft Graph to integrate configuration into your IaC or compliance controls. The required module is Microsoft.Graph (version 2.x recommended).
1# Required module: Microsoft.Graph (Install-Module Microsoft.Graph)2Connect-MgGraph -Scopes "NetworkAccess.Read.All", "NetworkAccess.ReadWrite.All"3 4# Read the state of the three forwarding profiles5$uri = "https://graph.microsoft.com/beta/networkAccess/forwardingProfiles"6(Invoke-MgGraphRequest -Method GET -Uri $uri).value |7 Select-Object name, state, trafficForwardingTypeExpected output:
1name state trafficForwardingType2---- ----- ---------------------3Microsoft 365 enabled m3654Private access enabled private5Internet access disabled internetValidation: the Private access profile is in enabled, assigned to the pilot group only. The Internet access profile remains in disabled until step 7. Never enable both on the same day: you would lose any ability for differential diagnosis.
Step 3 — Deploy Private Network Connectors in high availability
The connector establishes an outbound connection from inside your network to the Microsoft service, then relays traffic to published resources. No inbound ports are opened on the Firewall — that's the decisive security argument against a VPN concentrator exposed on the Internet.
Download the connector from Global Secure Access > Connect > Connectors and sensors > Private Network Connectors. As of 2026, it's also available in preview on Azure, AWS, and GCP marketplaces as a Windows VM with the connector pre-installed.
Never a single connector
A Connector Group with a single connector constitutes an SPOF on your complete remote access. Always deploy two connectors per group, on two distinct hypervisors. Also consider extending the TCP and UDP ephemeral port range on the connector server: the default Windows configuration saturates on high-density user deployments.
Segment your Connector Groups by network zone, not by application: one group for the main datacenter, one for the secondary site, one for the industrial zone if it's isolated. This segmentation allows routing each application to the connectors that actually reach it.
1# On the connector server — both services must be Running2Get-Service -Name "WAPCSvc", "WAPCUpdaterSvc" |3 Select-Object Name, Status, StartType4 5# Check outbound connectivity 443 to Microsoft registration endpoints6Test-NetConnection -ComputerName "connectorregistration.msappproxy.net" -Port 4437Test-NetConnection -ComputerName "login.microsoftonline.com" -Port 443Validation: the WAPCSvc and WAPCUpdaterSvc services are Running on each server. In the Entra portal, each connector reports as Active with a recent timestamp. If a connector stays Inactive for more than five minutes after installation, check outbound 443 on the Firewall — that's the cause in 100% of production cases encountered.
Step 4 — Publish private applications in per-app access
Two publication mechanisms coexist. Quick Access groups a set of FQDNs and IP ranges into a single Enterprise Application. Per-app access creates one Enterprise Application per business application, with its own segments and its own Conditional Access.
Quick Access is presented as a natural entry point for a VPN replacement scenario, but it reproduces the exact flaw of VPN: a broad perimeter, a single policy, a single population. Reserve Quick Access for DNS and Kerberos infrastructure at the next step. Everything else goes straight to per-app access, creating one application per row in the table established at step 1.
Creation from Global Secure Access > Applications > Enterprise applications: name the application, choose the Connector Group that serves the relevant network zone, then add segments.
Nested groups are not supported
Users must be assigned directly to the application, or to a group itself directly assigned. A group nested in another assigned group doesn't work. If your AD entitlement model relies on cascading groups, plan flat groups dedicated to publication before pilot day.
For applications that rely on the connector's outbound IP address for authentication or ACLs, enable session persistence — typical case of legacy business applications filtering by source address.
Validation: from a pilot workstation with the client installed, access to the published application works. In Global Secure Access > Monitor > Traffic logs, you observe connections with the Allow action and the correct application name. Allow up to 20 minutes for logs to appear. Also verify that the Through Global Secure Access column shows Yes in Sign-in logs.
Step 5 — Configure Private DNS and Kerberos SSO
This is the step where projects derail. Publishing an application is useless if the remote workstation doesn't resolve its internal name. And without access to Domain Controllers, no Kerberos ticket — so no SSO on shares and AD-integrated applications.
Enable Private DNS
From Global Secure Access > Applications > Quick Access, Private DNS tab, enable the feature and declare at minimum the top-level suffixes of each AD forest hosting synchronized users.
Publish Domain Controllers via Quick Access
Create a dedicated application exposing AD authentication ports:
88/TCP— Kerberos389/TCP— LDAP445/TCP— SMB135/TCP— RPC endpoint mapper
If you deploy Private Access Sensors directly on DCs for hardened controller-side authentication, also open inbound port 1337/TCP in the Windows Firewall of DCs — it's a prerequisite specific to the sensor.
The NRPT trap that breaks everything, silently
The Windows client configures local NRPT rules on the workstation to redirect DNS queries to Private DNS. If NRPT rules are pushed by GPO, they overwrite the client's local rules and Private DNS simply doesn't work. No error, no alert: resolution fails silently. Audit your GPOs before launching the pilot. This was identified on 4 of 5 VPN decommissioning projects observed in production.
Another production subtlety: Kerberos negative caching. When the system requests a ticket for an SPN and fails, Windows caches that SPN negatively. You fix the Domain Controller publication, everything looks correct in the portal, but the workstation keeps failing. You must purge the cache with klist purge or restart the session.
1# 1. Active NRPT rules on the workstation (local AND from GPO)2Get-DnsClientNrptPolicy | Select-Object Namespace, NameServers3Get-DnsClientNrptRule | Select-Object Name, Namespace, NameServers4 5# 2. Resolve an internal name via Private DNS6Resolve-DnsName -Name "dc01.corp.local"7 8# 3. Purge Kerberos cache before any re-test (negative cache)9klist purge10klist get host/dc01.corp.localValidation: from a remote workstation outside the enterprise network, Resolve-DnsName resolves an internal name and klist shows a valid TGS ticket for the target SPN. Access to an SMB share via \\server\share opens without asking for credentials. If authentication falls back to NTLM instead of Kerberos, the Domain Controller publication is incomplete — check port 88/TCP.
Step 6 — Deploy the client and neutralize network conflicts
The client is deployed via Intune in silent mode on the pilot fleet. It embeds the necessary .NET runtime, but validate your baseline before a mass deployment. The main work of this step is not installation: it's neutralizing network mechanisms that conflict with traffic acquisition.
Four critical points to address:
- Secure DNS (DoH/DoT/DNSSEC): the client doesn't support any of these modes. You must disable them, or traffic acquisition won't happen.
- DNS over TCP: the client doesn't handle port 53 in TCP, yet modern browsers embed their own DNS client that uses it. Disable it by registry.
- IPv6: the client only tunnels IPv4 and lets IPv6 pass through directly. On a workstation where IPv6 is active and preferred, some traffic escapes your policy.
- Microsoft Tunnel: coexistence is not supported. Handle this point before starting migration, not during.
1# Disable the internal DNS client in Edge (machine)2New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge" `3 -Name "BuiltInDnsClientEnabled" -Value 0 -PropertyType DWord -Force4 5# Same for Chrome (current user)6New-ItemProperty -Path "HKCU:\Software\Policies\Google\Chrome" `7 -Name "BuiltInDnsClientEnabled" -Value 0 -PropertyType DWord -Force8 9# Prefer IPv4 without disabling IPv610# DisabledComponents = 0x20 : prefers IPv4 over IPv611# Microsoft advises against completely disabling IPv612New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" `13 -Name "DisabledComponents" -Value 0x20 -PropertyType DWord -ForceAny user can disable the client by default
Without additional configuration, a non-administrator user can disable the Global Secure Access client from the taskbar icon — which amounts to bypassing your Conditional Access with a right-click. A registry key prevents this for non-administrators. Push it during production, not during pilot phase when you need this emergency valve.
Validation: in the client's advanced diagnostic tool, the Connections tab shows acquired traffic and channel status. Specifically test the sleep-wake scenario: it, not first boot, reveals remaining DNS conflicts.
Step 7 — Enable Internet Access and web filtering
Private access is stabilized. Now enable the Internet Access profile to resume traffic that your VPN was backhauling to the datacenter Proxy.
The policy chain is read in this order:
- A web content filtering policy defines authorization or blocking rules by category, FQDN, or URL.
- These policies aggregate into a security profile.
- The security profile attaches to a Conditional Access targeting a population.
The baseline profile is a special case: it applies to all tunneled Internet traffic without going through a Conditional Access. Reserve it for non-negotiable protections at the organization scale.
Know your quotas before designing the policy model:
- 256 security profiles per tenant
- 1,000 policies
- 1,000 rules
- 8,000 destinations across all categories (IP, FQDN, URL, web category)
- TLS inspection: 100 policies, 1,000 rules, 8,000 destinations
Two behaviors to brief N1 support on
First: filtering by HTTP method requires TLS inspection for HTTPS traffic. Without inspection, only SNI-based rules apply — your fine-grained URL filtering is inoperative on HTTPS. Second: an HTTPS block presents to the user as a connection reset error, not an explicit block page. Without this brief to N1 support, you receive a flood of tickets "Internet is broken" on day one.
An additional gain accessible through this project: Universal Tenant Restrictions. This application mode of Tenant Restrictions v2 blocks the use of unauthorized external tenant identities on your managed workstations. It requires only Entra ID P1 or P2 and relies on the Microsoft 365 forwarding profile of the Global Secure Access client to tag traffic without any Proxy. It's your control against exfiltration to unauthorized tenants — a capability no VPN ever offered.
Validation: from a pilot workstation, a site in a blocked category is inaccessible and an authorized site opens normally. In Traffic logs filtered on Action = Block, you find the attempts with the correct User Principal Name. Especially verify that no legitimate business flow appears as Block: that's the categorization false positive that kills SWG deployments.
Step 8 — Lock down with Conditional Access and decommission the VPN
As long as no Conditional Access conditions access to private applications, you've just replaced one tunnel with another. Now is when you get the project's value.
Private Access integrates with Conditional Access by targeting the Enterprise Application as a resource. Build policies per application, with conditions matching the actual sensitivity level: device compliance, MFA strength, user risk, sign-in risk, named locations. The payroll application doesn't need the same controls as the intranet — and that's precisely what VPN couldn't do.
Non-negotiable switchover order
Never cut the VPN until the cohort is validated on Global Secure Access. Switchover happens in waves: IT pilot, then two business units, then expansion. On each wave, keep the VPN as fallback for two to three weeks. Only remove VPN rights for a user after a complete period without tickets. The concentrator only shuts down once the last user migrates. Not the other way around.
Decommissioning the concentrator is the opportunity to close the corresponding inbound ports on the perimeter Firewall. That's the most visible part of the project for the CISO: external attack surface that disappears. A VPN concentrator published on the Internet is a permanent target. After switchover, all flows are outbound — nothing to attack on that side.
Validation: every published application carries a named and tested Conditional Access, including its denial case — a non-compliant workstation must be blocked and you must verify it. Sign-in logs display policy evaluation on each access. Inbound rules on the VPN concentrator are closed on the Firewall, and the step 1 inventory is entirely covered or explicitly abandoned for orphaned flows.
Final validation checklist and watch points
Deployment is complete when a remote user works exactly as at the office, never tunneling, with finer controls than the VPN allowed.
Production validation checklist:
- Every flow from the VPN inventory is published in per-app access, or explicitly abandoned and documented
- Each Connector Group has at least two active connectors on distinct hypervisors
- Internal DNS resolution works from a remote workstation, with no NRPT rule pushed by GPO in conflict
- Kerberos SSO is effective: TGS ticket obtained, SMB access without re-authentication
- Secure DNS and browser internal DNS clients are disabled on the fleet
- IPv6 behavior is controlled, no business flow escapes the tunnel
- Internet Access profile is active, with a baseline profile and security profiles linked to Conditional Access
- No categorization false positive blocks legitimate business flow
- Each private application has a Conditional Access tested in both allow AND deny
- Client disabling is forbidden to non-administrator users
- Universal Tenant Restrictions are configured if the anti-exfiltration need exists
- Inbound ports on the VPN concentrator are closed on the perimeter Firewall
Intelligent Local Access lets the client detect, via DNS probes, that it's already on the internal network, and route traffic locally instead of sending it to the Microsoft edge. That's real latency gain on high-volume local-traffic sites, avoiding hairpinning. Constraint to know: in local access, the workstation must have direct network connectivity to the target resource. If internal routing doesn't allow it, local bypass fails. Validate segment by segment before generalizing — the feature is still in preview at the time of this article.
For remote sites, Remote Network Connectivity brings up an IPsec site-to-site tunnel from the branch gateway (router or CPE) to the Microsoft edge, without installing the client on every workstation. Structural limit: remote networks carry Internet and Microsoft 365 traffic, but not the Private Access profile. For private app access from a site, the full Global Secure Access client remains mandatory on workstations. Prerequisite: a combined total of at least 50 P1 and Internet Access licenses on the tenant.
Since early 2026, Private Access offers BYOD support in preview that grants access to private applications via a browser flow, without installing the full client. This addresses the scenario of the external contractor who previously required a guest VPN account. Reserve it for non-critical use while the feature remains in preview.
Two points merit formalization as accepted and temporary risks in your security documentation. The lack of IPv6 client support forces workarounds on fleets where IPv6 is deployed. Secure DNS support (DoH) isn't available yet: disabling DoH on a fleet in 2026 is a security regression to assume and document, not a best practice.
Final sequencing advice: don't try to migrate everything at once. Take the simplest applications from your inventory — those in HTTPS with no Kerberos dependency — publish them in per-app, validate the full chain on twenty or so users, then attack AD infrastructure. The project that fails is invariably the one that starts with Domain Controllers.
Useful references:
