Sophos ZTNA Agent: systematic troubleshooting

Purpose and direct answer

An unavailable ZTNA resource does not automatically mean the agent is defective. Installation, policy, user group, DNS, identity provider, gateway, and internal application form a chain. Troubleshooting therefore starts with the visible symptom and changes only the layer for which evidence exists.

The shortest reliable check is:

Record the affected user, device, resource, and time.
Check the installation and local agent status.
Under My Products > ZTNA (full navigation: Sophos Central > My Products > ZTNA), compare the resource, access method, and policy.
Under ZTNA > Reports (full navigation: Sophos Central > My Products > ZTNA > Reports), look for successful authentication or the reason access was denied.
Under My Environment > Alerts (full navigation: Sophos Central > Alerts), look for a device installation, update, licensing, or connectivity event that matches the time.
Check DNS, identity, device health, or the gateway only as indicated by the symptom found.

A successful browser request does not prove that the agent path was used. Conversely, the ZTNA User Portal only shows agentless applications; an agent-based resource does not have to appear there.

Requirements, licensing, and roles

This diagnosis requires an affected user and managed device, the FQDN of an affected resource, and access to the correct tenant’s ZTNA configuration, reports, device view, and alerts. The ZTNA Agent must be assigned to the device when testing an agent-based resource. Under Devices > Computers or Servers, a green check indicates the installed ZTNA component; a plus sign means that it can still be installed.

The assigned sources do not specify a separate license name or a particular administrator role for this troubleshooting. Do not infer broader permissions from a menu being visible. If a required view or action is missing, involve the tenant administrator rather than concluding that there is a licensing or role problem.

Before making any change, record the following for exactly one affected user and device:

operating system, network, and time including time zone,
resource FQDN and access method, Agent or Agentless,
exact local ZTNA status and browser message,
whether other ZTNA resources work on the same device,
whether the same resource works for the same user on another network,
last change to policy, group, DNS, identity provider, or gateway.

Configuration with adaptable example values

Do not make blanket changes to production settings for a bounded test. Replace example values such as <USER>, <DEVICE>, <RESOURCE-FQDN>, and <TEST TIME WITH TIME ZONE> with values from exactly one case.

Under ZTNA > Reports, open the Report Generator tab. For denied access, select the Denied resource access template, narrow the period around <TEST TIME WITH TIME ZONE>, and, where the available columns permit, filter by <USER>, <DEVICE>, or <RESOURCE-FQDN>. Filter values with = and != are case-sensitive; ~ uses * as a wildcard and is case-insensitive. Multiple filters must all be satisfied. Then run the report with Create.

For an expected successful sign-in, use Authenticated users instead. This report records users whom ZTNA gateways authenticated successfully, regardless of the gateway deployment mode. The Gateway bandwidth and Resource bandwidth templates attribute traffic; they are not, by themselves, proof of a successful individual access attempt.

Under My Environment > Alerts, narrow the period and device to match the test. An alert can combine several recurring events. Open its title to display the associated events and full details. Do not close the alert merely to clear the list while analysis is in progress.

Validation and expected result

A positive test is complete only when all of the following agree:

The agent shows the expected state for the tested path.
<RESOURCE-FQDN> opens with the intended user, device, and network.
The Authenticated users report contains the successful authentication in the selected period.
The Denied resource access report contains no new denial for the same test.
My Environment > Alerts has no open installation, update, licensing, or connectivity alert matching the time that calls the success into question.

If the expected report record is missing, check the period and filter spelling, then repeat the test once with only one variable changed. If a denial appears instead, its reason determines the next section. If the second test also produces no usable record, do not force a “success” through more configuration changes; preserve the logs and SDU for escalation.

Troubleshooting by symptom

Status “Not configured”

Under Devices > Computers or Servers, check whether ZTNA is installed on the device. A green check confirms the installed component; a plus sign offers installation. An existing Sophos Endpoint installation alone does not prove that ZTNA was assigned.

There is an important Windows exception. If Don’t intercept on-premises traffic is configured under Global Settings > Products and Services > ZTNA and the Windows agent detects the internal network, it intentionally stops interception there and shows Not Configured. Configured is expected again after moving to another network. According to Sophos, this feature is currently Windows-specific; do not infer macOS parity.

This Windows behavior requires Sophos Core Agent 2025.2.1.709 or later. In Sophos Fusion (formerly Sophos Central), open the device and verify the installed Core Agent version on its Summary tab before diagnosing on-premises detection. An older version does not support this exception as described.

If the exception does not apply, check component assignment, online status, and update state in Sophos Fusion. Do not begin with reinstallation while it remains unclear whether ZTNA was assigned at all.

Status “Zero Trust Network Access: Error”

This status indicates a connection problem. Check in this order:

Does a ZTNA policy exist, and is it assigned to the resource?
Does the device resolve the gateway FQDN as intended?
Does Sophos Fusion show an installation or health error for the device?
On Windows, is the Sophos TAP configuration present, or has other network software changed it?

Sophos lists disabling IPv6 as a troubleshooting step. It is not a baseline fix: perform it only on one pilot device, with the initial state recorded, and for one reproduction test. Re-enable IPv6 afterwards. If the symptom changes unambiguously, preserve timestamps and an SDU and investigate with Sophos Support; do not leave IPv6 disabled permanently or broadly.

A tunnel may close when idle. Depending on the central setting, this happens after 5, 15, or 30 minutes, or one hour; the default is 5 minutes. New traffic re-establishes it. An idle closed tunnel alone is therefore not evidence of a fault.

For an agent-based resource, check in order:

Can the device reach the ZTNA gateway?
Is the ZTNA Agent process running?
Is there an incorrect public or internal CNAME from the application FQDN to the gateway? This CNAME must not exist for agent-based applications.
Do the resource, access method, and FQDN match in Sophos Fusion?
Do ZTNA logs show an SNTP, DNS, or connection error at the test time?

If sign-in appears but the user is not returned to the application, check the identity provider’s redirect URI. With Okta, the Groups claim expression is also case-sensitive. Reset browser cookies or credentials only after authentication itself has been confirmed as the failing class.

An authenticated agent resource fails or stops working

If authentication succeeds but an agent-based application does not open, inspect the SNTP logs on the endpoint for errors and verify in heartbeat.xml that the certificate recorded there is currently valid. Incorrect device time, failed time synchronization, or an expired or not-yet-valid certificate can break the authenticated agent path even when policy and DNS appear correct. Preserve the logs, file, and timestamp; do not edit the XML or bypass certificate validation.

If access previously worked and is then lost, perform the same checks of the SNTP logs and certificate validity in heartbeat.xml, and inspect the device in Sophos Fusion. A red Endpoint health state is a diagnosis lead: resolve the reported health cause and then retest rather than weakening the ZTNA policy.

“403 Access Denied / No Access”, “Device Health”, or “Policy Off”

The Denied resource access report narrows down the next check:

403 Access Denied / No Access: The user is not effectively in a group assigned to the resource, or security is not enabled for the group in Microsoft Entra ID. Check group import, security-enabled status, and identity-provider API permissions. Allowed-group changes can take up to one hour.
Device Health: The device does not meet the health conditions of the assigned agent policy. Resolve the specific health issue rather than weakening the policy broadly.
Policy Off: Open the affected policy under My Products > ZTNA > Policies and check Policy is enforced.
Upstream request error for Agentless: The gateway cannot reach the internal application, the application is down, its FQDN/IP resolves incorrectly, or its configured port is wrong. This is not evidence of a defective endpoint agent.
404 Not Found for Agentless: Check the application’s CNAME to the gateway FQDN. Do not apply this DNS rule to agent-based resources.

If the user was just added to a group, retest only after the documented replication interval. A private browser window can exclude stale browser state for a web application, but it cannot accelerate group replication.

DNS failures after installation

The ZTNA TAP adapter can become the default for nslookup. A lookup for a target outside the ZTNA gateway may then fail even though name resolution has not failed generally. For comparison, Sophos documents explicitly specifying the intended DNS server:

nslookup <FQDN> <DNS-SERVER>

Compare the response through the expected corporate resolver and then the real application request. Do not change adapter order, metrics, or DNS server addresses speculatively. For agent-based resources, also make sure no gateway CNAME exists for the application.

Sophos DNS Protection is a separate data path. If it is also in use, follow Configure Sophos DNS Protection for endpoints for policy and exclusions; do not treat ZTNA DNS and Endpoint DNS Protection as the same feature.

ZTNA alongside VPN or remote-access software

Do not delete TAP adapters, change bindings, or hard-code network metrics as a general response. First reproduce access to the same resource in a controlled test with and without the other client, recording time, DNS response, and ZTNA status.

For ZTNA 2026.1 with Sophos DNS Protection, Sophos documents one specific coexistence path: enable DNS Protection and turn on Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN in its endpoint policy. This requires the applicable version, license, and DNS Protection configuration; it is not a universal fix for arbitrary VPN products.

Narrow macOS cases

On macOS Sequoia, Chrome can block applications behind an on-premises gateway after a ZTNA-only fresh installation when the browser lacks local-network access. For this symptom only, check under System Settings > Privacy & Security > Local Network whether Google Chrome is allowed to find local devices. Sophos Cloud Gateway is not affected by this documented case. This implies neither a general permission recommendation nor a promise of macOS “private access.”

High CPU usage after an MDM deployment can be caused by multiple VPN profiles whose names begin with Sophos ZTNA. Under System Settings > VPN, check for duplicates. Keep exactly one profile; an MDM-installed profile cannot be removed locally and must therefore be the profile that remains. Restart the Mac, then recheck CPU usage and ZTNA access. This cleanup applies only to this confirmed macOS case, not to Windows TAP adapters.

If stale credentials are explicitly reproduced, the Sophos reset procedures may be used only for debugging or demonstrations, not as routine sign-out in production. On macOS, the Endpoint diagnostic tool offers ZTNA > Reset; browser cookie scripts or manual removal of Safari website data must match the gateway and identity provider exactly. On Windows, the Sophos procedure requires Tamper Protection to be disabled and the KB attachment clearcreds.bat to be run elevated. Do not use third-party cleanup scripts or invented manual deletion paths. The original files and limits are in Sophos ZTNA: Sign out from the agent.

Safe rollback or offboarding

The assigned diagnostic and reporting sources do not document a general agent repair, uninstallation, or rollback. The safe stopping point is therefore:

Test filters and Report Generator do not change the data path; a template or schedule saved only for diagnosis can be deleted again under Saved templates or Scheduled exports.
Immediately restore the documented initial state after an IPv6 comparison test.
Do not leave a temporarily relaxed policy, changed group, DNS configuration, or certificate check in place as a fix. If such a change was made outside this procedure, restore the previously documented state and retest with the same case.
Do not remove the agent, delete TAP adapters, or bypass certificate validation while the fault location remains unproven. If there is no documented rollback, stop and escalate with the preserved evidence.

After every rollback, the agent status, DNS response, real resource request, and applicable ZTNA report must again match the initial state. If they do not, do not make a second change.

Operations, review, and lifecycle

ZTNA reports and alerts are operational evidence, not repair actions. For recurring reviews, save a filtered report template or schedule an export. Scheduled reports can be generated daily, weekly, or monthly as PDF, CSV, or HTML; Sophos Central supports at most 200 schedules. Manually or automatically generated exports are deleted after 90 days. If a report contains personal data, prefer an email link to a file attachment because the link requires sign-in to Sophos Central.

Alerts show severity, status, events, and device. Recurring events can be combined into one alert; a later event can automatically close an alert as Resolved. During an incident, therefore, always read the included events and timestamps. Mark as acknowledged removes an alert from the list but does not resolve its cause. Mark as resolved is likewise no substitute for technical remediation.

Before reinstalling, cleaning profiles, or making further network changes, collect:

device, user, operating system, and actually installed components,
resource, access method, policy, and assigned group,
exact message, local ZTNA status, and timestamp including time zone,
result with a second user, device, or network, changing only one variable each time,
DNS responses for resource and gateway FQDNs,
relevant Central events and ZTNA, SNTP, and installation logs,
the filtered ZTNA report or export for the test period,
a current SDU archive.

Current help and component versions take precedence. This procedure supports no conclusions about historical ZTNA transitions, withdrawal of earlier entitlements, migration deadlines, retirement, or exact end-of-life dates.

For architecture and dependencies, see Set up Sophos ZTNA: overview and sequence. This article remains focused on agent state and connection evidence; gateway deployment and a supposed general agent repair are outside its scope.

Sophos Endpoint: diagnostics with SDU explains safe collection. Then open a Sophos support case with the preserved evidence. Do not copy credentials, tokens, or browser cookies into tickets or unprotected attachments.