Set up Sophos ZTNA: complete setup runbook

Sophos Zero Trust Network Access, or ZTNA, controls access to internal applications and websites through identities, groups and policies. A complete setup requires a directory service, an identity provider, a gateway, a certificate and DNS design, policies and resources. Local applications require a ZTNA agent; web applications can be provided without an agent.

This runbook describes the overall architecture and the correct setup order. It does not replace detailed gateway planning or specialist runbooks for domain controllers, RDP or SSH. Start with exactly one application, one pilot group and a documented fallback path. Expand the scope only after both the positive and negative tests pass.

Direct answer: the correct order

Set up Sophos ZTNA in this order:

Check the license, administrator access, platforms and target application.
Define the access method and gateway mode.
Synchronize users and security groups from Microsoft Entra ID or Active Directory.
Set up the identity provider and test its connection.
Provide the wildcard certificate, domain and gateway.
Configure public and private DNS resolution.
Create a small ZTNA policy.
Deploy the ZTNA agent only where the access type requires it.
Create the resource with exactly one policy and the intended groups.
Test authorized and unauthorized access as well as logs.
Only then migrate additional users, applications and locations.

Sophos Fusion is the management layer. The gateway, agent, directory service, identity provider, certificate, DNS, policy and resource remain separate technical dependencies. A successful sign-in therefore does not prove that the application is reachable or properly restricted.

Prerequisites, license and roles

License and trial operation

Sophos ZTNA is part of Sophos Workspace Protection. The license is available as a standalone subscription, through MSP Flex or in the Sophos Endpoint Plus Workspace Protection bundle. For Workspace Protection, the required quantity is based on the highest consumption among the included products; for ZTNA, unique authenticated users within 30 days are counted. The same license type covers agent-based and agentless access as well as on-premises and Sophos Cloud Gateways.

Standalone Workspace Protection does not include a Sophos Endpoint license. Agent-based deployment therefore also requires an applicable Endpoint entitlement and the ability to install Sophos Endpoint Agent. This is separate from the fact that the ZTNA license itself covers both access methods.

Sophos Cloud Gateway also has an average transfer limit of 15 GB per user per month. A trial license normally runs for 30 days. A trial tenant allows no more than 1,000 entries per object type, such as users, groups or devices. After the license expires, the Workspace Protection products are unavailable in Sophos Fusion; the configuration is retained and reappears after renewal.

Activate and check the license through the profile icon > Licensing. For a structured trial, use Start and safely evaluate a Sophos Fusion trial.

Responsibilities

At minimum, clarify these roles before making changes:

Sophos Fusion administrator: can configure directory sources, identity providers, gateways, policies and resources. An administrator of the Sophos Central management console is required to configure an AD directory source.
Identity administrator: creates the app registration, Client Secret, groups, Redirect URIs and, where applicable, guest accounts at the identity provider.
DNS and certificate owner: can create public and internal DNS records, confirm domain ownership and renew certificates.
Network or firewall administrator: provides routing, outbound connections, NAT and firewall rules for the selected gateway mode.
Application Owner: knows the internal FQDN or target IP, ports, authentication, redirects and the business acceptance criterion.
Endpoint owner: deploys the Sophos Endpoint Agent with the ZTNA component and checks supported operating systems.

Do not store Client Secrets, bind passwords or private keys in the ticket or runbook. Instead, document the owner, storage location, expiration date and rotation process.

Technical pre-check

Before the first click, check:

Gateway host: VMware ESXi 6.5 or later, or Hyper-V on Windows Server 2016 or later. For both, Sophos specifies at least 2 CPU cores, 4 GB RAM and 80 GB storage; SSD is recommended. The date and time must be correct and the time zone must be UTC.
Sophos Firewall as gateway: SFOS 19.5 MR3 or later and management through Sophos Fusion. Hardware, cloud, virtual and software firewalls are supported. Some newer features may require a later SFOS version.
Certificate: wildcard certificate from Let’s Encrypt or a trusted CA. RSA with at least 2048 bits and ECDSA are supported, but P-384 and P-521 are not.
Directory: Microsoft Entra ID or on-premises Active Directory with maintained groups. Entra groups for ZTNA must be security-enabled.
Identity provider: Microsoft Entra ID, Okta or on-premises Active Directory.
Agent platform: Windows 10 1803 or later, or macOS 11 Big Sur or later.
Application: static, known ports. Applications with dynamic port assignment or very large port ranges, such as older VoIP products, are not supported.
Network: internal reachability and private name resolution from the gateway to the application. On-premises gateways must also be able to reach the Sophos-required destinations outbound; SSL/TLS inspection must not break the required gateway connections.

For gateway architecture, sizing and network rules, follow Plan and create a Sophos ZTNA Gateway.

Example values for this runbook

Replace all values with your own. Do not mix test and production domains.

Purpose	Example value
Pilot group	`ZTNA-Pilot-Finance`
Gateway FQDN	`ztna.example.net`
External resource FQDN	`wiki.example.net`
Internal target	`wiki.intern.example.net`
Web port	`443/TCP`
Policy	`ZTNA-Pilot-Healthy`
Resource	`Wiki-Pilot`
Primary PoP	`Europe (Frankfurt) Region`
Allowed test user	`ztna-allow@example.net`
Blocked test user	`ztna-deny@example.net`

1. Choose the access path and gateway mode

Agentless or with an agent

The choice is technically binding:

Requirement	Without agent	With agent
Web application or website	Yes	Yes
Local application, for example a native TCP app	No	Yes
Check device health	No	Yes
Sophos Endpoint Agent required	No	Yes
External resource FQDN publicly resolvable	Yes	No
Warning when resource is unreachable	Only for this mode	No

Agentless access can only control web applications and websites. It does not assess device health. An agent-based policy can check security health and restrict all supported resource types. Agent-based policies and resources do not work until the ZTNA component is installed on the devices.

The full Protected Browser and its extension are not equivalent: the extension in another browser does not assess endpoint health. Endpoint protection conditions therefore apply only to traffic from the full Protected Browser. Agentless RDP and SSH sessions through Protected Browser are separate deployment cases; create an agentless ZTNA policy, a tightly restricted resource and the associated Protected Browser objects for them. Do not copy a web-app policy unchanged to administrative RDP or SSH targets.

On-premises gateway or Sophos Cloud Gateway

On-premises gateway: the virtual appliance resides in your own data center and is reachable from the internet. You manage the instance and need suitable firewall ports and NAT rules.
Sophos Cloud Gateway: Sophos operates the cloud data plane. A gateway instance in the data center connects this plane to internal resources; direct internet exposure, inbound port rules and NAT rules for the access path are not required.

The modes are interchangeable and migration is possible. Nevertheless, treat migration as a controlled change: DNS, certificate, PoP, external names and tests must match the new data path.

For cloud mode, select the Point of Presence (PoP) near the data center, not automatically near the users. Regions are available in Ireland, Frankfurt, Ohio, Oregon, Mumbai and Sydney. From ZTNA 2.1, a neighboring secondary PoP is configured by default and used for automatic failover. Change the PoP under My Products > ZTNA > Gateways: open the gateway, select Edit, change the region under Points of Presence, and save.

2. Prepare the directory service and groups

ZTNA authorizes access based on synchronized user groups. Therefore, first create a small, security-enabled pilot group and add only the allowed test user. A second user outside the group is required for the negative test.

Synchronize Microsoft Entra ID

The existing step-by-step guide Synchronize Microsoft Entra ID with Sophos Fusion remains the detailed owner. These points are particularly important for ZTNA:

Register the ZTNA application in Entra ID.
For ESXi and Hyper-V gateways, add https://<gateway-fqdn>/oauth2/callback; for Sophos Firewall gateways, add https://<gateway-fqdn>/ztna-oauth2/callback as the Redirect URI. Multiple gateway FQDNs are possible.
Record the Client ID, Tenant ID and Client secret value when it is created. The secret value cannot be displayed again later.
Grant only the required Microsoft Graph permissions and the necessary admin consent.
Create or select security-enabled groups. Explicitly verify this for groups imported from the Microsoft 365 portal or AD.
In Sophos Fusion, open Global Settings > Directory service or Access control > Sign-in & identity and add Microsoft Entra ID.
Configure the domain, Client ID, Client secret, its validity period, and the schedule Hourly, Daily, Weekly, Monthly or None.
Limit the users and groups to synchronize to the scope actually required. Save and check the result under My Environment > Users & groups.

You cannot synchronize multiple Entra ID sources from the same domain. Office 365 GCC High is not supported for this synchronization. If the UPN and endpoint sign-in do not match, duplicate or unlinked users can be created. If you later rename an assigned Entra group, its name is not automatically updated in the assignment; assign the group again.

Synchronize on-premises Active Directory

For AD, download Active Directory Synchronization Setup under Global Settings > Directory service. Prerequisites are .NET Framework 4.6.2 on the synchronization computer, Sophos API credentials with the Service Principal Active Directory Sync role, unique users and email addresses, and the required firewall or proxy rules.

Validate the Client ID and Client Secret in the setup program.
For LDAP, use an account with read access to the forest and as few permissions as possible.
Keep Use LDAP over SSL connection enabled where possible. Port 636 is customary for LDAPS and port 389 for an unsecured connection.
Select users and user groups together. The same applies to devices and device groups.
Limit the scope with Base Distinguished Names and LDAP filters, for example OU=Finance,DC=example,DC=net.
After initial setup or a filter change, first run a manual preview and synchronization. Manual synchronization can take up to 15 minutes.

Do not synchronize users and groups from the same domain from AD and Entra ID at the same time. Primary AD user groups are not synchronized for ZTNA; affected users must also belong to another AD group. Changes to a Base DN or filters can remove previously imported objects from the search scope and thus delete them from Sophos Fusion. Remove inactive accounts in the source directory rather than merely hiding them from synchronization.

Guest access

Microsoft Entra B2B can be used for external users. Check in advance whether the tenant permits external collaboration, which domain may be invited and who approves invitations. Guests can be added individually or in a controlled batch operation. Create a separate guest group, synchronize it to Sophos Fusion and assign only the required resources. The Application Owner must know the departure date and sponsor for every guest account.

Add an individual user manually

If a user is not synchronized from a directory, open My Environment > Users & groups, select Add user, and enter First and last name, Email address, and, where needed, Role, Manager, Exchange login, and Add to groups (optional). Assign an administrator role only when required; User grants access only to the self-service portal. Select Email setup link only if the user should protect their own device and has local administrator rights and internet access. Save, then verify that the user appears in the list and intended ZTNA group. If not, check the email address, group filter, and whether the directory service should instead be authoritative.

3. Set up the identity provider

Open Sophos Central > My Products > ZTNA > Identity providers > Add identity provider or My Products > ZTNA > Identity providers. Only one entry is possible per identity provider. Avoid special characters such as ., @ or # in the name, because otherwise the configuration may not save.

Microsoft Entra ID

Select Microsoft Entra ID (Azure AD).
Enter the name, description, Client ID, Tenant ID and Client secret.
Test the connection.
Save only after a successful test.

On-premises Active Directory

Select Microsoft AD (on-prem).
Enter the host and port of the primary AD server and, optionally, a secondary server in the same domain.
Enable TLS or StartTLS. If you select Verify SSL certificate, upload a certificate in .pem, .crt or .cer format with a maximum size of 10 KB.
Enter the Bind DN, bind password and the Base DN for users and user groups.
Optionally enable Captcha and an email-based one-time password with SMTP configuration.
Assign the identity provider to a gateway. Then reopen the provider, select the gateway under Test Connection, and optionally enter a username. If a user is specified, the test also shows their groups.

For AD as the identity provider, an ESXi or Hyper-V gateway must use at least ZTNA 2.1; Sophos Firewall requires at least SFOS 19.5 MR3. The email field of the test user must be valid. In this scenario, ZTNA supports only one domain, not multiple child domains in a forest. With on-premises AD, users must authenticate the first time they access resources behind each gateway and can be authenticated on only one device at a time.

Okta

For Okta, you need synchronized groups and an OIDC authorization server. The gateway must use at least version 1.1. In Okta, create an OIDC web application, enable Client Credentials and Refresh Token, use the appropriate callback path, and assign the groups. Then enter the Client ID, Client Secret and Issuer URI in ZTNA. A custom Okta authorization server requires an API Access Management license.

Federated sign-in to Sophos Fusion administration is a separate control path from the ZTNA identity provider above. You need Super Admin rights and must first verify the sign-in domain under Access control > Sign-in & identity > Sophos sign-in with the generated TXT record. Then open Access control > Sign-in & identity > Federated identity providers and select Add identity provider:

Enter a name and description without ., @, or #.
Select Microsoft Entra ID, OpenID Connect, or Microsoft AD FS. Entra ID requires the Tenant ID; OIDC requires Client ID, Issuer, Authorization endpoint, and JWKS URL; AD FS requires its metadata URL.
Assign the verified domain. You can add several domains, but each user can belong to only one.
Deliberately select IdP-enforced MFA or No IdP-enforced MFA. With the latter, Sophos Fusion enforces MFA after successful IdP authentication.
Save and enable the provider. Incomplete or invalid settings prevent enablement.

Enable federated sign-in only after all affected administrators and users have a domain and a suitable provider. Test a bounded administrator account in a private browser window while keeping a working Super Admin session open as the fallback. If the test fails, disable the new provider from that session and check domain assignment, endpoints, certificate trust, and the MFA selection.

Select an identity provider in Sophos ZTNA

4. Provide the gateway, domains and certificate

Plan and create the gateway according to Plan and create a Sophos ZTNA Gateway. Use a wildcard certificate for multiple resources under the same domain. Create a Let’s Encrypt wildcard certificate is available for Let’s Encrypt.

For the Sophos Fusion-managed Let’s Encrypt path, open My Products > ZTNA > Settings > Domains and certificates and select Add domain. Fusion generates a CNAME for _acme-challenge.<domain>. Publish its name and target exactly in public DNS, retain it for renewals, and select Verify. The status must become verified. Copy the complete target; some providers require a trailing dot. Move a domain previously validated with TXT to the current CNAME before generating the managed certificate. After adding any domain, regenerate the account’s single managed certificate so that it includes that domain.

The manual Certbot DNS challenge for your own wildcard certificate is separate: only that path uses the TXT value requested by Certbot. Upload the certificate, full chain, and private key, and check the domain and Subject Alternative Names. It is operational only when an external client trusts the full chain. Full issuance remains in the linked wildcard-certificate runbook.

5. Configure DNS

On-premises gateway

For an agentless setup, you need the following public records:

an A record for the gateway FQDN, for example ztna.example.net,
one CNAME per resource pointing to the gateway FQDN, for example wiki.example.net,
the gateway and agentless resources in the same domain.

For agent-based access, only the public A record for the gateway is required; resources do not need a public CNAME. The gateway must be able to resolve the target FQDN internally. Alternatively, enter the internal target IP when creating the resource.

Sophos Cloud Gateway

Confirm domain ownership with the CNAME generated by Sophos. Then publish the CNAME for the gateway alias. For each agentless resource, add a separate CNAME pointing to the displayed resource alias. Agent-based resources do not require a public resource CNAME.

Check every name from three perspectives:

publicly from an external network,
internally from the gateway network,
from the pilot device in the intended access mode.

The agent intercepts traffic by FQDN, not by IP address. If a web application redirects to another FQDN, create that redirect FQDN as a resource as well.

6. Create a policy

Open Sophos Central > My Products > ZTNA > Policies > Add policy or My Products > ZTNA > Policies.

Select Add policy.
Select Agent or Agentless according to the resource.
Enter a unique name, for example ZTNA-Pilot-Healthy.
For an agent policy, leave Use access control conditions enabled under Access rules.
Under Allow access, select the required security health state.
Save.

A policy defines the access method and conditions. User groups are assigned to the resource, not to the policy. Exactly one policy is possible per resource; a new assignment replaces the previous one.

Agentless policies have no device health rules. If Request agent appears on the policy page, you can create the policy already, but must wait for agent provisioning and installation before agent-based tests.

7. Agent and special access cases

Install the ZTNA component through the Sophos Endpoint Agent only for the pilot group. Then verify on the endpoint that the agent is configured and has received the expected policy.

Under My Products > ZTNA > Settings, you can set the agent tunnel inactivity time to 5, 15 or 30 minutes, or 1 hour; the default is 5 minutes. The tunnel is automatically re-established when new traffic occurs. The minimum time before a changed device health state triggers a rule prevents unnecessary blocks during brief status issues.

On Windows, Do not monitor local traffic can prevent hairpinning in the office. This requires at least Sophos Core Agent 2025.2.1.709. Enter an FQDN and an IP in Sophos Fusion and the same mapping in internal DNS. If resolution matches, the agent sends local traffic directly over the LAN. Enable this option only if the resources should be reachable on the LAN without ZTNA; according to the assigned product documentation, it is not yet available on macOS.

Plan special cases separately:

RDS farm: First complete the farm and domain membership according to current Microsoft documentation. Under My Products > ZTNA > Resources & access > Add resource, select the gateway, Access method: Agent, Resource type: Remote Desktop Protocol (RDP), the RD Gateway external FQDN, the required ports (the documented example uses 3389, 443, and 80), its internal FQDN or IP, and the pilot group. From the pilot device, open https://<rd-gateway-fqdn>/rdweb, download the RDP file, and connect. A session must open on a session host. A packet capture must show ZTNA traffic on the TAP/TUN adapter and no direct RD Gateway or session-host traffic on the primary interface. Otherwise check the agent, type, ports, DNS, and RDS broker/gateway before expanding access.
SaaS control: Use this only if the SaaS application supports IP allow lists. Add it as a ZTNA resource, assign only the required group, and leave Internal FQDN/IP address blank so the external FQDN becomes the target. In the SaaS application, allow only the public IP or range of the NAT interface in front of the ZTNA gateway. A pilot user must succeed through ZTNA; an unauthorized user or direct path outside that NAT range must fail. If not, compare the actual egress NAT range with the allow list and check the group, external FQDN, and gateway path.
Windows Hello: This key-based passwordless path requires Microsoft Entra ID, an Azure Premium license, Windows 10 or 11, an existing ZTNA setup, and an application server in the same domain as the agent device. In Azure, enable device joining under Devices > Device settings. In Intune, enable Windows Hello under Devices > Windows enrollment > Windows Hello for Business for everyone, or create a Windows 10 and later > Templates > Identity protection profile under Devices > Configuration profiles > Create profile for the pilot group. Join the pilot device under Settings > Accounts > Access work or school > Connect > Join this device to Azure Active Directory, restart it, sign in with the Entra account, and set up MFA and a PIN or biometrics. Then install the ZTNA agent. Direct access to an agent-based app, including CIFS or RDP, must not prompt again for the IdP; Sophos Endpoint must show ZTNA configured and the user authenticated. Otherwise check the Entra join, assigned profile, Hello sign-in, common domain, and agent status. Verify Microsoft menu names against current vendor documentation before rollout.
In the office: consciously choose between the same ZTNA path used externally and direct LAN access. Avoid unintended hairpinning.
Domain controller: create these as agent-based resources for Windows devices. Since Endpoint version 2026.1, Sophos supports multiple domain controllers; priority and weighting of the automatically generated SRV records enable failover and load balancing. For the specific three-DC setup, use Configure multiple domain controllers with Sophos ZTNA instead of recreating failover in a general web resource.

8. Create a resource and assign access

Open Sophos Central > My Products > ZTNA > Resources & access > Add resource or My Products > ZTNA > Resources & access.

Document in advance:

resource name and Application Owner,
gateway,
web application, website or local application,
internal FQDN or internal IP,
external FQDN,
protocol and port,
access with or without an agent,
policy,
allowed groups,
redirect FQDNs,
positive and negative tests.

Use an FQDN for web applications and websites. Connect local apps by IP address. For agentless access, the external FQDN must be publicly available. For agent-based access, the external FQDN must not be publicly available, otherwise the resource is unreachable.

Select Add resource.
Select the gateway and access type.
Enter the internal and external names, protocol and port.
Select the policy created previously.
Assign only the pilot group.
Save and open the resource summary for a cross-check.

Changes to group memberships can take up to one hour to become effective at the gateway. Observe this period before changing the configuration again.

Validation and expected result

Check the configuration

No unexpected High or Medium alerts are visible under My Products > ZTNA > Dashboard.
The identity-provider connection test succeeds and, for an AD test, shows the expected group.
The domain and certificate are valid; external browsers report no certificate error.
Public DNS records point to the expected gateway or alias generated by Sophos.
The gateway resolves the internal target and can reach its port.
The policy type, resource type and agent status match.
The resource shows exactly the intended policy and pilot group.

Test access

Open the application as an authorized pilot user through its external FQDN, not by IP address.
Confirm sign-in with the configured identity provider.
Test actual application functionality, not only the landing page: sign-in, navigation and a harmless read operation must work.
Test with a user outside the allowed group. Access must be rejected in a traceable way.
For an agent policy, change the relevant device health state only in a controlled test window. The defined condition must take effect.
Check the ZTNA, gateway, identity-provider, DNS and firewall logs for the same timestamp.
Document the user, device, FQDN, time, expected result and actual result.

Users can open web applications directly or through the ZTNA user portal. The portal address is the FQDN configured on the gateway. For platform type Sophos Firewall, an administrator must first configure a resource for portal access. The portal displays allowed agentless applications across gateways; agent-based applications are not displayed there. A new sign-in is required after seven days without resource access. Five consecutive failed authentication attempts block further resources for 60 minutes.

Troubleshooting by symptom

Test the connection under My Products > ZTNA > Identity providers.
Check the Client ID, Tenant ID, secret expiration and Redirect URI.
Verify that the user and group are synchronized and security-enabled.
For AD, check the Bind DN, Base DN, port, TLS certificate and a valid email field for the test user.
After five failed attempts, wait for the 60-minute lockout instead of generating more tests.

A provider cannot be enabled while setup is incomplete or contains invalid information. For the message Verification failed due to invalid Client ID, check the app ID and whether user sign-in is enabled for the application in Entra ID.

Open exactly the external resource FQDN.
Check redirects and create every additional FQDN as a resource.
Test internal resolution and the target port from the gateway network.
Compare the resource type, policy type and agent installation.
Check whether the external resource FQDN is publicly resolvable for agentless access and specifically not publicly resolvable for agent-based access.
Check whether a new policy replaced the old resource assignment.
If direct access works but the user portal on Sophos Firewall does not, verify that the required portal resource exists and is assigned to the correct group.

User unexpectedly has no access

Check the effective group membership, not only the expected membership.
Wait up to one hour after a group change.
Reassign renamed Entra groups.
For AD, ensure that the user is not only a member of a primary group.
Check whether filters or the Base DN removed the user from the synchronization scope.

DNS or certificate is faulty

Compare A and CNAME values character by character with Sophos Fusion. Check TXT only for the separate manual Certbot path or Fusion federated-sign-in domain verification.
For a managed certificate, check the CNAME at _acme-challenge.<domain>, retain it for renewals, and regenerate the account certificate after a domain change.
Check whether the DNS provider appended your own domain name to the CNAME.
Check the certificate chain, wildcard scope, expiration date and supported key type.
Test publicly and internally separately. A successful LAN test does not prove public resolution.

Agent is installed, but the tunnel or device health does not take effect

Check the operating system, Endpoint version and installed ZTNA component.
Ensure that the policy and resource are both agent-based.
Take the configured minimum time for device health into account.
With Do not monitor local traffic, the FQDN and IP in internal DNS must exactly match the Central configuration.
The Protected Browser extension does not provide endpoint health status; test such conditions in the full Protected Browser or with the ZTNA agent.

Escalation to Sophos Support

Under Global Settings > Products and Services > ZTNA, set the expiration time for support access. Then generate a time-limited support token in the gateway settings. Do not transmit permanent credentials, and revoke the token or let it expire after completion.

Safe fallback and offboarding

Roll back a failed pilot

Stop expansion to additional users.
Remove the pilot group from the resource or set the policy to Policy bypassed. Note: this prevents users from accessing the managed resources.
Restore the previously documented access path, such as VPN or direct LAN access. Do not retire it until ZTNA has been accepted.
Remove the ZTNA component only from pilot devices if no other agent-based resource needs it.
Remove public resource CNAMEs only after the return to the old path has been confirmed. Do not hastily delete gateway DNS or the certificate while other resources use them.
Use positive and negative tests to verify that the old path works and that no unintended public exposure remains.

Do not disable Use access control conditions as a supposed emergency bypass: doing so removes the device health check. If secure access cannot be restored, stop here and escalate instead of broadening the policy.

Offboard a user or guest

Remove the group membership in the authoritative directory or disable the account at the identity provider.
Allow up to one hour for the change to take effect at the gateway. Disabling the account at the identity provider then forces sign-out and blocks resources.
Verify that no second synchronized group grants the same access.
Check the ZTNA logs with a negative test after access has been revoked.
Remove orphaned guest accounts, invitations and temporary groups from the source system.

Users generally remain signed in until they have been inactive for seven days. Currently, only an administrator can trigger immediate sign-out. Take this into account especially for shared devices.

Retire a resource or gateway

Inventory all assigned groups, policies, resources, DNS names and certificate dependencies.
Remove user access first and observe the logs.
Then delete the resource.
Remove public DNS records only when no other access path needs them.
Delete a gateway only after all resources have been migrated and the new path has been validated.
Revoke secrets and certificates that are no longer needed and remove old firewall or NAT rules.

Operations, review and lifecycle

Perform a review at least quarterly and after every major change:

active users and license consumption over the last 30 days,
group and guest memberships,
resource-to-policy assignment and Application Owner,
certificate expiration and secret rotation,
gateway, agent, SFOS and hypervisor versions,
PoP, failover and current status notifications,
unreachable agentless resources and alert trends,
outbound firewall exceptions, NAT and old DNS records,
positive and negative tests for each critical application,
documented emergency and fallback path.

The ZTNA dashboard shows alert counts and the five applications with the highest data transfer over the last 24 hours. Use the Gateway bandwidth and Resource bandwidth reports to track authenticated users and data volume.

An active ZTNA license includes feature and maintenance releases, 24x7 support and the associated Sophos Fusion functions. Sophos expects feature releases approximately every six to twelve months and maintenance releases every one to three months. The current feature version and one selected additional feature version are maintained; the last two maintenance releases should be supported for each maintained feature version. The expected support period for a feature version is approximately 24 months, normally with 90 days’ public advance notice of end of support.

Treat this information as release planning, not as a guarantee of a specific date. Before upgrades, check the current ZTNA release notes, known limitations, agent compatibility and the status of the PoPs in use. Historical transition, entitlement, migration or EOL statements without a current product announcement do not belong in the operational plan.