Entra Private Access Deployment Guide: Replace Legacy VPN

The target outcome is access to approved applications from approved users and devices, with less broad network exposure. Retire remote-access VPN paths only after their applications, authentication dependencies and recovery requirements have passed validation. ^{[1, 2]}

Managed endpoint and signed-in userGlobal Secure Access client
Microsoft Entra identity and access policyApplication assignment and Conditional Access
Global Secure Access cloud serviceAuthorized private application traffic
Private network connector groupTwo connectors near the application
Private application and its own permissionsHTTPS, SMB, RDP, SSH or other validated TCP and UDP

Deployment baseline

Commercial Microsoft Entra tenant; managed Windows 11 clients; two dedicated Windows Server 2022 or 2025 connector hosts per production group; a small internal HTTPS application as the first pilot. This is a recommended example architecture, not a tenant configuration discovered or deployed for you.

1Scope and reading map

Sections	Outcome
2 to 4	Architecture, licensing and application inventory
5 to 7	Network preparation and resilient connector deployment
8 to 10	Quick Access, private DNS and traffic forwarding
11 to 13	Client rollout, per-app access and Conditional Access
14 to 16	Authentication, testing and diagnostics
17 to 20	Monitoring, VPN migration, operations and signoff
21	Official references and screenshot attribution

What Private Access changes

Design concern	Common legacy VPN approach	Target Private Access approach
Access scope	Routes to networks and subnets	Named destinations, ports and protocols
Identity	Gateway sign-in and VPN groups	App assignment plus identity policy
Device trust	Varies by VPN deployment	Compliant-device requirement where configured
Application permissions	Backend authorization still applies	Backend authorization still applies
Exposure	Internet-facing VPN infrastructure	Connector initiates outbound cloud connections
Migration unit	Network or gateway	User cohort and application dependency set

Global Secure Access is the shared administration area for Entra Internet Access and Entra Private Access. This guide focuses on private applications. Enabling Private Access does not automatically deploy Internet filtering or protect all Microsoft 365 traffic. ^[1]

Treat this as a remote user-to-application migration. Site-to-site routing, device tunnels before user sign-in, server-to-server automation, unsupported platforms and specialist protocols require separate assessment. A successful browser test is not proof that every former VPN use case is covered.

2Architecture and trust boundaries

USER NETWORKEndpoint authenticates and acquires matching application traffic
MICROSOFT CLOUDIdentity policy authorizes access to the published application
OUTBOUND CONNECTOR CHANNELEstablished from the private network to Microsoft
APPLICATION NETWORKConnector initiates the permitted backend connection
APPLICATION AUTHORIZATIONThe server still checks its user, role and data permissions

Arrows represent logical request flow. The connector-to-cloud channel is established outbound; you do not open an inbound Internet port on the connector to accept users. Connectors in the selected group need both cloud connectivity and access to the published backend. ^[3]

Separate the three decisions

Traffic acquisition: does the client have a rule for this destination, port and protocol? Access policy: is the user assigned and does Conditional Access permit access? Backend authorization: does the application allow the requested action? Troubleshoot each independently.

Continue using HTTPS, SSH, SMB encryption and other application-level protections as appropriate. A cloud access tunnel does not justify plaintext everywhere inside the application network. Keep host firewalls and segmentation between connector groups and backends.

Use separate groups for production and nonproduction or for distinct application trust zones. All connectors within a group must be able to reach every backend assigned to that group. Two machines behind the same failed firewall or DNS service are not independent failure domains.

3Licensing and administration readiness

Private Access requires its standalone license or Microsoft Entra Suite, together with Entra ID P1 or P2 for users. P1/P2 alone does not grant the full Private Access service. Confirm purchased entitlements, assignment and supported cloud environment before starting. ^[1]

Responsibility	Role or entitlement to verify	Owner
GSA configuration	Global Secure Access Administrator	________
Apps and connectors	Application Administrator	________
Conditional Access	Conditional Access Administrator	________
Device compliance	Intune entitlement and appropriate Intune role	________
Identity risk controls	Entra ID P2 where risk-based policy is used	________
Log export and SIEM	Security and Azure workspace permissions	________

Use separate privileged accounts and time-limited role activation where available. Confirm emergency administrative access before enforcing new policies. Emergency access to the Entra portal and emergency access to a private backend are different recovery requirements. ^{[7, 13]}

Baseline choices for this guide

Use Entra joined or hybrid joined Windows 11 devices to keep the initial rollout on an established managed-device path. Microsoft also documents macOS and mobile clients; assess each platform separately. Entra registered Windows support is identified as preview, and Windows AVD multi-session is not supported in the current Windows client documentation. ^[10]

Use current connector packages on patched Windows Server hosts with .NET 4.7.2 or later and TLS 1.2 enabled. The documented minimum server release is Windows Server 2016; selecting a newer supported release reduces lifecycle work. ^[4]

Stop conditions before a pilot

Do not proceed to user rollout if license assignment, app ownership, emergency administration, connector egress or backend DNS remains unresolved. Record the specific missing dependency and owner rather than testing with broad administrator privileges or unrestricted network access.

4Inventory applications and dependencies

Example application	Destination	Protocol and port	Access group
HR portal	hr.corp.example.com	TCP 443	GSA-HR-Users
File share	files.corp.example.com	TCP 445	GSA-Files-Users
Admin desktop	admin01.corp.example.com	TCP 3389; assess UDP	GSA-Admin-RDP
Linux administration	linux01.corp.example.com	TCP 22	GSA-Linux-Admins
Identity dependencies	Named DCs and resolvers	Validate required services	GSA-Identity-Users

Record more than the first connection

For each app, record business owner, criticality, user groups, backend addresses, aliases, redirects, load balancer names, ports, TCP/UDP use, identity provider, certificate names and recovery path. Include file-server referrals, database listeners, license servers and authentication dependencies.

Observe representative work rather than only logon: upload and download, printing, reporting, reconnecting and long-running sessions. Application discovery can help identify destinations used through Quick Access, but observations need owner review before becoming a permission set. ^[12]

Map the existing access route

Document VPN split-tunnel rules, DNS suffixes, NRPT policies, endpoint security agents and route precedence. Separate apps that can migrate now from those that require remediation or a retained alternative. Record who will approve removing the old route.

Planning field	Value to record
Pilot cohort	Named users and directly assigned security groups
Connector group	Location, trust zone and at least two hosts
DNS ownership	Suffix, resolver path and authoritative zone
Success criteria	Task completion, latency, denied-access tests
Rollback trigger	Error threshold, affected users and decision owner

5Prepare network connectivity

Traffic leg	Required preparation
Client to Microsoft	Allow the current GSA client endpoints and sign-in services
Connector to Microsoft	Outbound TCP 443 plus documented certificate-validation HTTP endpoints
Connector to application	Only required destination ports and protocols
Connector to internal DNS	Reach the resolvers configured on the connector OS
Connector to identity services	Permit only dependencies required by the chosen authentication design
Internet to connector	No inbound Internet publishing required

Microsoft lists connector service domains such as *.msappproxy.net and *.servicebus.windows.net, identity endpoints and certificate-validation endpoints. Implement the complete current list from ^[4]; those examples are not a complete allowlist. Exempt connector cloud TLS from inline interception or termination. ^[4]

Test from each connector candidate

Resolve-DnsName hr.corp.example.com
Test-NetConnection hr.corp.example.com -Port 443
Resolve-DnsName files.corp.example.com
Test-NetConnection files.corp.example.com -Port 445
Get-DnsClientServerAddress -AddressFamily IPv4
netsh winhttp show proxy
w32tm /query /status

These are read-only checks run on your future connector hosts. A TCP test does not validate UDP, cloud authentication or the complete application transaction. Test cloud destinations against your approved endpoint list and verify access for the service context, not only an administrator browser.

Preserve network boundaries

Allow backend traffic from the connector hosts using host and network firewalls, then validate the source the backend actually observes. Do not rely on the end-user workstation source IP surviving the proxied path. Network access from a connector should not imply backend administrator rights.

For the pilot, avoid IP targets that overlap the user home or office local subnet. Microsoft documents restrictions on acquiring IP destinations within the client local subnet. Prefer validated FQDN access where appropriate and test each user network condition. ^[11]

6Install and register connectors

Prepare two dedicated patched servers with DNS and application reachability. Use a tested server build and record its OS, connector version, location and maintenance owner.
In Entra admin center, open Global Secure Access, Connect, Connectors. Download the connector service. Review the terms and run the Microsoft installer on each server.
Register each installation to the correct tenant using an Application Administrator account. Confirm registration and running connector/updater services. ^[4]

Screenshot in the PDF edition Microsoft connector status example. Check tenant, host, group and active status. Source [4].

Screenshot in the PDF edition Microsoft connector and updater services example. Source [4].

A green status is one health signal. Complete a backend transaction through each connector before approving the group. Avoid copying a registered machine image to create the second connector; install and register each instance independently.

7Build resilient connector groups

Under Global Secure Access, Connect, Connectors, create a named group such as CG-HQ-Production and select both hosts. Assign the group to the application during publishing. Use at least two healthy connectors for production. ^[3]

Global Secure Access applicationAssigned to CG-HQ-Production
CONNECTOR A + CONNECTOR BSame backend reachability and policy
Application servers and internal DNSRedundant dependencies where required

Placement and capacity

Place connectors near the applications they serve. Start capacity planning from Microsoft current guidance of at least four cores and 8 GiB memory per connector, then measure your actual protocol mix and concurrency. Keep sufficient capacity for one host to be unavailable. ^[3]

For the pilot, collect CPU, memory, network throughput, connection counts, application latency and failure rate during normal and peak work. A throughput number from a synthetic test is not a service-level guarantee for interactive SMB or RDP.

Maintenance procedure

Use a dedicated maintenance group with a test app to move one connector out of production routing. Allow sessions time to complete, patch and validate it, then return it before servicing the other host. Long-lived sessions and failures can still cause reconnects; test this behavior with your applications. ^[4]

Keep DNS, network egress and authentication dependencies redundant too. Back up configuration records, not just VMs. A replacement host should be provisioned and registered through a repeatable process with the same required network reachability.

8Configure Quick Access for transition

Open Global Secure Access, Applications, Quick access. Name the app, select the intended connector group and add a deliberately limited application segment. For the first pilot, use a test HTTPS hostname and TCP 443 rather than an entire private address space. Save the configuration. ^[5]

Screenshot in the PDF edition Microsoft segment editor. The pictured ranges are examples; enter only required destinations and ports. Source [6].

Use Edit application settings to open the enterprise application and assign the pilot users or security group under Users and groups. Direct membership is required; nested group membership is not supported. Configure Conditional Access for this application using section 13. ^[5]

Screenshot in the PDF edition Microsoft Quick Access application settings link. Source [5].

Quick Access is a transition tool. Give every broad segment a business owner, an expiration review date and a plan for replacement by smaller applications. If only a few apps need access, you can begin with per-app publishing instead.

9Configure private DNS

Enable Private DNS in Quick Access and add only the internal DNS suffixes you need, for example corp.example.com. The selected Quick Access connector group must resolve those names using its Windows DNS configuration. Matching suffixes also support names used by per-app applications. ^[8]

Application requests hr.corp.example.com
GSA client matches the configured private DNS suffixWindows local name-resolution policy steers the query
Microsoft DNS proxy uses cache or asks the connector
Connector uses its OS-configured internal resolver
GSA client returns a synthetic address to the applicationApplication traffic is steered through GSA

A synthetic address on the client is expected and is not the backend server address to place in firewall rules. Use FQDNs for Kerberos applications; synthetic single-label suffixes can interfere with service principal names. ^[8]

Validate both ends

# On each connector
Resolve-DnsName hr.corp.example.com
# On the managed pilot endpoint
Get-DnsClientNrptPolicy
Resolve-DnsName hr.corp.example.com

Compare with client diagnostics and the actual app connection. Avoid treating nslookup alone as a complete test of the application DNS path. Check aliases, split DNS and suffix behavior using the real application.

10Enable Private Access traffic forwarding

Open Global Secure Access, Connect, Traffic forwarding. Enable the Private Access profile. Use its user/group assignment controls to scope the pilot. The pilot users must also be assigned to the Quick Access or per-app enterprise application. ^[9]

Screenshot in the PDF edition Microsoft Private Access forwarding profile example. Use View to review published policies. Source [9].

Keep the pilot focused

For a Private Access pilot, change only the forwarding profile required by the approved design. If Internet or Microsoft profiles already exist, document them and their assignments so a troubleshooting change does not affect unrelated users.

Check the effective client policy

After installing the client, open Advanced Diagnostics, Forwarding profile. Verify the intended destination, protocol, port and application ID. Use Policy tester for the exact target and review rule priority. Save a screenshot of the effective rule as pilot evidence. ^[16]

Allow time for configuration propagation; Microsoft instructs allowing 15 minutes for per-app changes to synchronize. Verify the client profile timestamp rather than repeatedly editing a rule that has not arrived yet. ^[6]

Do not confuse assignment failures

If the app is absent, check profile scope first. If its rule exists but access is denied, check enterprise-app assignment and Conditional Access results. If the service permits access but the transaction fails, check connector reachability and backend authentication.

11Deploy the Windows client

Download the client from Global Secure Access, Connect, Client download. Use the installer for the device architecture, install with local administrative rights and complete sign-in to the intended tenant. Pilot on managed Windows 11 devices before using wider deployment. ^[10]

Screenshot in the PDF edition Microsoft Windows client download example. Source [10].

Validate installation and device identity

dsregcmd /status
Get-Service | Where-Object {
  $_.DisplayName -like '*Global Secure Access*'
} | Select-Object DisplayName, Status

Record the tenant and device identity, installed version, client sign-in and connection state. A successfully installed package is not the same as a successfully acquired Private Access flow.

Screenshot in the PDF edition Microsoft client Connections view. Validate the relevant Private Access status. Source [10].

For Intune rollout, package the approved installer, use version-aware detection, architecture requirements and a restart grace period. Test install, upgrade, reboot and recovery in a small ring. Microsoft supplies detailed packaging guidance in ^[10]; adapt it to your change controls rather than copying every optional setting.

12Publish an application with narrow access

In Global Secure Access, Applications, Enterprise applications, choose New application. Create GSA-HR-Portal, select CG-HQ-Production and add hr.corp.example.com with TCP 443. Save, then assign GSA-HR-Users under Users and groups. ^[6]

Screenshot in the PDF edition Microsoft enterprise application creation entry point. Source [6].

Define the whole permitted task

Publish only dependencies the user device actually needs. An app redirect to another hostname requires review; a web server database connection does not automatically mean the user needs database access. Keep administrative and ordinary user access in different apps and groups.

Migrate from a Quick Access segment

Create the per-app definition and assign its users explicitly. Assignments do not transfer from Quick Access. Microsoft gives a per-app segment precedence over an overlapping Quick Access segment, so users missing the new assignment can lose access. Avoid overlap between per-app applications and remove obsolete Quick Access coverage after validation. ^[6]

Verify least privilege

Test an authorized user, an unassigned user and an authorized user targeting an unpublished port. Repeat from a remote network without VPN connectivity. Verify the actual app rule using Policy tester and inspect Conditional Access and traffic evidence.

Design review	Expected result
HR users	Reach only approved HR application segments
IT admin group	Separate privileged application definitions
Unassigned users	No GSA access to the application
Backend user permissions	Still enforced by the application
Alternative direct routes	Reviewed and restricted where required

13Apply Conditional Access

Open the Private Access enterprise application, select Conditional Access and create a policy. Confirm that the selected app is the target resource. Scope a pilot group, exclude designated emergency administrative accounts as designed, and start in Report-only. Inspect results before enabling enforcement. ^[7]

Screenshot in the PDF edition Microsoft application details example used to navigate to Conditional Access. Source [7].

Policy field	Suggested managed-device pilot
Name	CA-GSA-HR-Managed-MFA
Users	Pilot group; documented emergency exclusions
Target resource	GSA-HR-Portal enterprise application
Grant controls	Require MFA and require compliant device
Multiple controls	Require all selected controls
Initial mode	Report-only, then On after validation
Risk and session controls	Add only when licensed and separately tested

This is a proposed policy, not a universal template. Device compliance requires a configured compliance service and functioning enrollment. Choosing Require one of selected controls would weaken a design that intends both MFA and compliance. Hybrid joined alone is not the same as compliant.

Private Access uses application-targeted Conditional Access. Do not target a Private Access traffic profile as though it were the Internet Access Universal Conditional Access policy model, or use the compliant-network check as a substitute for device compliance. ^[11]

Test sign-in and app use with a compliant user, a noncompliant test device and failed MFA. Existing authentication claims can satisfy MFA without a fresh prompt; check policy results, not just whether a prompt appeared. ^[12]

14Preserve application authentication

Private Access governs reaching the app. It does not create an account inside the app, grant an SMB share permission, authorize sudo or make every legacy application single sign-on. Validate the backend identity separately from the Entra sign-in.

Start with an internal HTTPS application

Use a valid certificate for the hostname, test certificate trust on the client, and confirm the existing login method still works. Test a user who can reach the app but has no application role: the app should deny the protected action.

SMB and Kerberos

For Kerberos SSO, validate synchronized identity, domain-controller discovery, reachable published DCs, correct DNS names and service principal names. Microsoft documents publishing the relevant site domain controllers and configuring Windows Hello for Business cloud Kerberos trust when required. Follow ^[14] for the full port and identity design before expanding access.

# On the pilot endpoint after attempting file access
klist
Test-NetConnection files.corp.example.com -Port 445
# Open a permitted test share in File Explorer
explorer.exe \\files.corp.example.com\PilotShare

These commands show ticket state, TCP reachability and a real share attempt. They do not by themselves prove Kerberos was used successfully. Confirm server-side authentication and share permissions. Avoid broad domain-controller port exposure merely to make an incomplete pilot pass.

RDP and SSH

RDP may require both TCP and UDP for the desired experience. Test the protocol mix rather than assuming a TCP connection proves full functionality. SSH still needs host-key verification and authorized credentials. Keep privileged targets and administrators separate from general user access. ^[15]

Use the specific Private Access SSO workflow. Application Proxy constrained delegation instructions concern a different application publishing pattern and should not be applied without confirming they fit your selected architecture.

15Validate access and rejection

Test	Expected evidence
Approved user and compliant device	Real task completes; correct app and policy in logs
Unassigned user	No authorized GSA app access
Noncompliant test device	Enforced policy blocks access
Unpublished host or port	Not reachable through GSA
Backend role denied	Network can connect; app denies the action
Remote network with VPN off	Traffic is acquired by GSA; app works
One connector unavailable	New connections recover through healthy host
Both connectors unavailable	App unavailable through GSA; incident alert fires
User access removed	Observed denial within documented/tested timing
GSA disabled or disconnected	No unintended alternate direct path
Reboot and client upgrade	Identity, profile and application access recover

Run the real business operation

Resolve-DnsName hr.corp.example.com
Test-NetConnection hr.corp.example.com -Port 443
Test-NetConnection files.corp.example.com -Port 445
Test-NetConnection admin01.corp.example.com -Port 3389

Use approved test accounts and destinations. For HTTPS, open the portal and complete a harmless task. For SMB, read and write a disposable pilot file. For RDP, connect to a test server and check reconnect behavior. For UDP, use the application and traffic diagnostics; Test-NetConnection tests TCP.

Evidence to retain

Record UTC time, user, device ID, application ID, destination, protocol, port, effective forwarding rule, Conditional Access result and backend result. Include screenshots from your tenant and client diagnostics. Redact identifiers and content according to your support policy.

Report-only policy does not block. Run denial tests after the specific pilot policy is set to On. Do not interpret a failed ping as failure of the TCP/UDP application service, or a working VPN route as proof of GSA access.

16Diagnose by traffic stage

CLIENT HEALTHCorrect tenant, signed-in user and Private Access connection
FORWARDING AND DNSTarget matches current rule and expected name-resolution path
IDENTITY DECISIONProfile scope, app assignment and Conditional Access results
CONNECTOR PATHHealthy group and backend reachability from every host
APPLICATION RESULTTLS, credentials, roles and dependent services

Open client Troubleshooting, then the Advanced diagnostics tool. Review Overview, Health check, Forwarding profile and Traffic. Start a short capture, reproduce one attempt, filter by destination or process, then stop collection. Policy tester identifies the effective rule. ^[16]

Screenshot in the PDF edition Microsoft client Troubleshooting view. Use a short, controlled capture. Source [10, 16].

If the client shows Tunnel but the app fails, examine missing secondary connections and backend authentication. If it shows Bypass, inspect destination matching, DNS and profile state before changing Conditional Access. A connector health indicator cannot prove the backend is listening. ^[15]

Symptom	Check	Likely corrective action
No Private Access channel	Tenant, license, profile assignment	Correct enrollment and user scope
App absent from rules	App enabled, profile timestamp	Fix assignment or wait for synchronization
Works by IP but not name	Suffix, connector resolver, NRPT	Repair managed DNS path
DNS differs from server IP	Synthetic addressing in diagnostics	Validate expected acquisition; do not hard-code synthetic IP
Per-app migration blocks user	New enterprise-app assignment	Assign the new app explicitly
MFA or compliance denial	Sign-in log policy result	Correct intended device/user state
TCP connects but login fails	SPN, identity dependencies, app roles	Repair backend authentication separately
Intermittent access	Every connector backend path	Fix inconsistent DNS or firewall reachability
Only fails with VPN active	Route and DNS ownership	Apply tested vendor coexistence design
Works locally but not remotely	Direct LAN path versus GSA path	Test acquisition away from local subnet
Unexpected access without GSA	VPN, LAN or alternate published route	Close unintended bypass paths

Escalation package

Collect one reproducible attempt with timestamp, user/device/app IDs, client and connector versions, current rule details, sign-in correlation data and the connector event error. State whether the connector can reach the backend directly and whether the issue affects one user, app, location or all traffic.

Share diagnostic archives only through an approved support channel. Avoid collecting unrelated browsing or application content. Remove temporary verbose logging when the issue is resolved and record the permanent change.

17Monitoring and security operations

Review Global Secure Access, Monitor, Traffic logs alongside Entra sign-in logs and audit logs. Traffic evidence shows connection behavior; sign-in logs explain identity policy; audit logs show configuration changes. These views answer different questions. ^[17]

Export and retain evidence

In Entra ID, Monitoring and health, Diagnostic settings, configure approved export destinations. Select NetworkAccessTrafficLogs for traffic data; its Log Analytics table is NetworkAccessTraffic. Include required identity and audit categories in your logging design. Verify records arrive before treating export as complete. ^[18]

// Log Analytics: inspect recent records and available columns
NetworkAccessTraffic
| where TimeGenerated > ago(1h)
| take 50

// Basic volume view; refine after confirming the tenant schema
NetworkAccessTraffic
| where TimeGenerated > ago(24h)
| summarize Events=count() by bin(TimeGenerated, 15m)

The query is a starting point, not a complete detection rule. Validate schema, ingestion delay and available fields before filtering for a particular app. Budget for ingestion and retention. Some GSA logging capabilities are documented as preview; verify tenant availability and avoid making a preview-only dashboard your sole recovery signal. ^{[17, 18]}

Signal	Suggested response
Connector unavailable	Check remaining capacity and backend reachability
Spike in denied access	Correlate with policy changes and identity risk
New broad app segment	Review owner, scope and approval
Unexpected privileged app use	Validate membership and backend audit
Logs stop arriving	Test ingestion and independent service monitoring
Latency or failures increase	Compare cloud path, connector and app performance

Assign one incident coordinator across identity, endpoint, network and app teams. Monitor the application itself through a separately controlled synthetic check; a healthy cloud dashboard is not a guarantee that every business task works.

18Migrate from the existing VPN

DISCOVERInventory users, apps, routes, DNS and authentication dependencies
PILOTLimited cohort, narrow app set and tested recovery route
SEGMENTPublish per-app access and remove broad Quick Access coverage
MIGRATE IN WAVESValidate business tasks and eliminate duplicate routing
RETIRE APPROVED VPN SCOPERemove old permissions after evidence and owner signoff

Coexistence requires a routing design

Decide which client owns each application destination and DNS suffix during migration. Protect access to sign-in, device management and VPN/GSA control endpoints. Test both clients active, each individually active and the transition after reboot.

Microsoft publishes product-specific coexistence guidance, including Cisco examples with split-include and synthetic-address handling. Do not apply one vendor example universally or assume every VPN works unchanged because both clients install. Use the exact supported combination for your VPN, platform and versions. ^[19]

Suggested migration gates

Wave 1: IT volunteers and a low-risk HTTPS app. Wave 2: a business cohort and its complete dependencies. Wave 3: file access and privileged workflows after identity testing. Advance only when access, denial, performance, support and recovery tests pass.

Set a retirement date for every exception. Keep an explicit register for site-to-site traffic, pre-logon dependencies and unsupported clients. Retiring user VPN access does not automatically authorize deleting a gateway that still serves another function.

19Operate and recover the service

Routine operations

Review user and group assignments, app segments and emergency exclusions on a schedule. Remove stale access when roles change. Stage client updates in rings and patch connectors one at a time. Retain app IDs, group names, network rules, DNS settings, versions and owners in a recovery inventory.

Check connector service and updater health. The connector Admin event log is the starting point for server failures; enable detailed Session logging only when needed. Monitor release guidance because not every connector release is automatically deployed. ^[3]

Rollback a failed migration wave

Pause the wave and identify whether the failure is identity, traffic acquisition or backend connectivity. Preserve logs and current settings before changing them.
Restore the affected cohort or app to its previously validated VPN route. Coordinate GSA profile/app scope with VPN routes and DNS so the same destination is not handled ambiguously. Allow policy propagation and verify the active path on the endpoint.
Keep successful cohorts on the working design where possible. Restore a policy from its recorded prior state only when it is the cause; do not disable Conditional Access tenant-wide.
Test both a permitted user and an unauthorized user on the restored route. Reconcile the temporary access permissions and set an expiration date for the exception.

Recovery boundaries

Changing a GSA acquisition rule can expose an existing LAN or VPN route instead of blocking the destination. Backend firewalls and alternative routes must enforce the intended security posture. Verify the actual disconnected-client behavior; do not assume a universal fail-closed guarantee. ^[16]

Entra emergency accounts help recover administration, but backend recovery may need an independent, tightly controlled management path. Document who can use that path, how credentials are protected and how use is audited.

20Production signoff checklist

Owner	Required evidence	Approval
Service owner	App scope, support model and service objectives	________
Identity team	Licenses, assignments, CA and emergency access	________
Endpoint team	Client rollout, compliance and recovery tests	________
Network team	Cloud egress, DNS, app ACLs and route ownership	________
Application owner	Business tasks, dependencies and authorization	________
Security operations	Audit, sign-in, traffic and alert handling	________
Operations team	Connector redundancy, patching and capacity	________

Production readiness

Confirm two healthy connectors per production group, tested backend reachability from both, current clients and a complete application dependency inventory. Record the license model and preview exceptions accepted by the service owner.

Confirm unassigned and noncompliant users are denied as designed, backend roles remain enforced, and the application is not reachable through an unintended alternate route. Retain evidence from a remote network with the legacy VPN disconnected.

Confirm that support can find one connection across client diagnostics, Entra sign-in results, GSA traffic logs and backend logs. Test connector maintenance, device restart and rollback before broad deployment.

Define success in measurable terms

Measure	Target to agree before cutover
Application task completion	Baseline and acceptable failure rate
Latency and transfer performance	Threshold by application and user location
Denied-access tests	All expected denials observed
Recovery time	Connector failure and rollback objectives
VPN retirement	Approved cohorts removed from old access groups
Exception backlog	Owner and expiry for every retained route

21Official references

Microsoft documentation checked 20 September 2026. Open the linked page before production rollout to confirm current support, prerequisites and preview status. The guide uses conservative pilot defaults and original operational recommendations alongside the cited product behavior.

Global Secure Access overview and licensinghttps://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access
Private Access conceptshttps://learn.microsoft.com/en-us/entra/global-secure-access/concept-private-access
Private network connectors and sizinghttps://learn.microsoft.com/en-us/entra/global-secure-access/concept-connectors
Connector installation and network prerequisiteshttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-connectors
Configure Quick Accesshttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-quick-access
Configure per-app access and segment precedencehttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-per-app-access
Conditional Access for Private Access appshttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-target-resource-private-access-apps
Private DNS and synthetic addressinghttps://learn.microsoft.com/en-us/entra/global-secure-access/concept-private-name-resolution
Private Access forwarding profile and assignmenthttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-manage-private-access-profile
Windows client installation and deploymenthttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-install-windows-client
Current known limitationshttps://learn.microsoft.com/en-us/entra/global-secure-access/reference-current-known-limitations
Application discovery and per-app segmentation labhttps://learn.microsoft.com/en-us/entra/global-secure-access/tutorial-private-access-app-segmentation
Private Access lab prerequisiteshttps://learn.microsoft.com/en-us/entra/global-secure-access/tutorial-private-access-introduction
Kerberos SSO for Private Accesshttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-kerberos-sso
Troubleshoot application accesshttps://learn.microsoft.com/en-us/entra/global-secure-access/troubleshoot-app-access
Windows client advanced diagnosticshttps://learn.microsoft.com/en-us/entra/global-secure-access/troubleshoot-global-secure-access-client-advanced-diagnostics
Logs and monitoringhttps://learn.microsoft.com/en-us/entra/global-secure-access/concept-global-secure-access-logs-monitoring
Microsoft Sentinel integration and export categorieshttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-sentinel-integration
Microsoft and Cisco VPN coexistencehttps://learn.microsoft.com/en-us/entra/global-secure-access/how-to-cisco-vpn-coexistence

Screenshots and diagrams

The PDF edition reproduces ten Microsoft Learn example screenshots, each attributed to its source article in its caption. They are not reproduced on this page; open the linked Microsoft Learn articles to see the current portal screens.

Process diagrams, the pilot architecture, test matrices and rollout recommendations were prepared for this guide. They illustrate logical stages rather than packet-level timing or a guarantee of instantaneous policy revocation.