What is changing 

Each Azure PoP now exposes two distinct DNS endpoints: 

This change applies to Azure PoPs only. AWS and GCP are out of scope. 

Note: No upgrade, reboot, or reconfiguration is required on your Connector Appliance — provided the new FQDNs are reachable on outbound TCP/443. 

PoPs affected 

All current Azure data PoPs receive a new <pop>-spa-rdvz.g.nssvc.net endpoint: 

For the live, authoritative list of SPA PoPs, run this DNS query from any machine with internet access: 

nslookup -q=TXT spa-pops.nssvc.net 

The returned TXT entries are the PoP shortnames (for example, az-us-e, az-eu-w) — append -spa-rdvz.g.nssvc.net to each to derive the full FQDN. 

Note: Citrix continues to add new Azure PoPs. If you maintain an explicit per-PoP allow list, rerun this TXT lookup periodically. Switching to the wildcard pattern below removes this maintenance burden. 

Do I need to take action? 

No action required — for customers using the recommended outbound allow list: 

• *.nssvc.net
• *.netscalermgmt.net
• *.citrixworkspacesapi.net
• *.citrixnetworkapi.net
• *.citrix.com
• *.servicebus.windows.net
• *.adm.cloud.com

The new <pop>-spa-rdvz.g.nssvc.net records resolve under *.nssvc.net and are already covered. Action required — for customers who currently allow specific PoPs by FQDN (for example, only az-eu-w-rdvz.g.nssvc.net on a strict egress firewall): For each currently permitted <pop>-rdvz.g.nssvc.net entry, add the corresponding <pop>-spa-rdvz.g.nssvc.net record to your firewall, proxy, or NetScaler allow list before the cutover. Outbound TCP/443 only — no inbound ports are required. 

Note: Also allow DNS resolution of the TXT record spa-pops.nssvc.net from your Connector Appliance network. 

How to verify after the change 

Once your firewall is updated, end users continue to launch Secure Private Access apps as before. To confirm you can access your connector appliance UI. The endpoints with *-spa-rdvz.g.nssvc.net will show up as red. 

Health monitoring after the cutover 

The Connector Appliance is automatically onboarded into the Infrastructure monitoring dashboard in DaaS Monitor when it connects to a Citrix DaaS site — no additional setup is required. Use the surfaces below to confirm that your Secure Private Access deployment remains healthy through and after the cutover. For full reference, see Health monitoring. 

Infrastructure monitoring dashboard 

Open DaaS Monitor and navigate to the Infrastructure monitoring dashboard. Each Connector Appliance in your resource location is listed with its current health status. The dashboard provides real-time visibility into the health and performance of the appliance, and lets you drill into detailed metrics and trends. After the firewall change, each connector should remain healthy with no new connectivity alerts. 

DaaS Monitor → Secure Private Access tab 

This is the primary surface for spotting cutover-related impact. Watch the following dashboard cards: 

Secure Private Access usage dashboard 

High-level visibility into Users, Applications, Policies, and Connector status. Use this to confirm overall service health at a glance after the cutover. 

Required admin role 

Viewing these dashboards requires the Secure Private Access full admin or read-only admin role. 

What it looks like when something is wrong 

If your firewall has not been updated: 

• End users see Secure Private Access app launch failures (typically a "connector unreachable" or "failed to connect" message).
• TheApp Failures (Web, SaaS, and TCP/UDP)card in DaaS Monitor spikes. 
• TheActive Sessions (Web, SaaS, and TCP/UDP)card drops. 
• The Connector Appliance entry on theInfrastructuremonitoring dashboard may transition to an unhealthy state. 
• HDX/ICA sessions are unaffected because they use the unchanged endpoints.

Impact is region-scoped: only apps that route through the affected PoP fail to launch. Connectors that can reach other PoPs continue to serve sessions normally. 

How to confirm and fix 

The checks below can be run from any machine on the same network as your Connector Appliance — for example, an admin workstation. They do not require access to the Connector Appliance itself. 

Step 1 — Verify DNS resolution 

From a workstation on the Connector Appliance's network, run: 

nslookup az-us-e-spa-rdvz.g.nssvc.net 

Replace az-us-e with any PoP shortname your users are routed through. A successful response returns one or more IP addresses. Also verify the TXT-record lookup that publishes the live PoP list: 

nslookup -q=TXT spa-pops.nssvc.net 

You should receive a list of PoP shortnames. If either lookup fails or returns nothing, work with your network team to confirm that outbound DNS (UDP/TCP port 53) is permitted and that your DNS security tooling does not strip TXT responses. 

Step 2 — Verify TCP/443 reachability 

From the same workstation, test outbound TCP/443 to a SPA edge FQDN. On Windows (PowerShell): 

Test-NetConnection az-us-e-spa-rdvz.g.nssvc.net -Port 443 

On Linux or macOS: 

nc -vz az-us-e-spa-rdvz.g.nssvc.net 443 

A successful result reports TcpTestSucceeded : True (PowerShell) or succeeded! (nc). 

Step 3 — Update your allow lists 

If either check in Step 1 or Step 2 fails, update your firewall, web proxy, and NetScaler outbound allow lists to permit <pop>-spa-rdvz.g.nssvc.net — preferably via the wildcard *.nssvc.net. The Connector Appliance picks up the change automatically. Within a few minutes, the Connector Appliance health page returns to a healthy state and end users can launch apps successfully. 

Step 4 — If the issue persists 

If both checks pass and end users still cannot launch Secure Private Access apps, open a Citrix Support case and reference this notice. Include: 

• Your Citrix Cloud customer ID.
• The names or IDs of the affected connectors (visible on theConnector Appliance healthpage). 
• The approximate time window when launches began failing.
• The output of thenslookupand Test-NetConnection (or nc) commands above, run from a workstation on the Connector Appliance's network. 

Citrix Support has access to the backend telemetry that is not exposed in the admin console. 

Frequently asked questions 

1. Does this affect my HDX/ICA sessions?No. HDX traffic continues to use the existing<pop>-rdvz.g.nssvc.net endpoints and is unaffected.  
2. Will I lose connectivity during the cutover?No planned outage. The new endpoints are provisioned and reachable before the change takes effect. Once yourfirewall permits the new FQDNs, no further action is required. 
3. Do I need to upgrade my Connector Appliance?No. No Connector Appliance upgrade isrequired for this change. Continue to follow your normal upgrade cadence for security and feature updates.  
4. Are AWS and GCPPoPsaffected? No. This change is scoped to Azure PoPs only.  
5. How long will the old `<pop>-rdvz.g.nssvc.net` records continue to serve Secure Private Access?The old endpoints continue to serve traffic during a transition period. Citrix will publish the deprecation date through theWhat's New page. Plan to have your allow lists updated before that date.  
6. What happens if I miss the cutover and myfirewallblocks the new FQDNs? End users will be unable to launch Secure Private Access apps in the affected regions. HDX (Citrix DaaS) sessions are not affected. The fix is to add *.nssvc.net — or, at minimum, the new per-PoP <pop>-spa-rdvz.g.nssvc.net records — to your outbound allow list. The Connector Appliance picks up the change automatically and the Connector Appliance health page returns to a healthy state within a few minutes. 

Note: This notification applies only to customers who have configured PoP-level FQDN allow lists at their firewall, proxy, or NetScaler — or any custom entries outside the documented recommendations. Customers using the recommended wildcard domain (*.nssvc.net) do not need to take any action. 

As part of ongoing performance and infrastructure optimizations for Citrix Secure Private Access™, Citrix is introducing a new set of DNS endpoints dedicated to Secure Private Access traffic at each Azure Point of Presence (PoP). HDX (Citrix DaaS / ICA) traffic is unaffected and continues to use the existing endpoints. This change is transparent for customers who use the recommended wildcard allow list. Customers who explicitly allow specific PoP FQDNs at their firewall, web proxy, or NetScaler must update their allow lists before the cutover.

Related documentation 

• Connector Appliance for Secure Private Access—firewall requirements, outbound FQDNs, sizing 
• Points of Presence (PoPs) locations for Citrix Secure Private Access service— fullPoP list 
• Health monitoring— Connector Appliance health page reference
• Real-time session troubleshooting using Monitor— session error codes
• Triage and troubleshoot— end-to-end triage flow
• What's New— original Important Notice entry