Integrate DNS Protection and ZTNA with Sophos Protected Browser

Sophos Protected Browser integrates DNS Protection and ZTNA through two separate operating paths. DNS Protection Direct lets the browser resolve names using DNS over HTTPS independently of endpoint and network DNS. The existing endpoint DNS integration also remains available for supported devices. For private or local applications, by contrast, Protected Browser connects to the prepared ZTNA gateway.

The short process is therefore:

Under My Products > Protected Browser, check the tenant, and under Settings > DNS Protection, check the direct browser DNS path. DNS and ZTNA remain separate configurations.
Select the required DNS path: direct browser resolution or the existing endpoint DNS integration. Pilot them separately; their filtering policies may produce different results.
Fully configure ZTNA with identity, gateway, resources and policies.
For agentless applications and resources other than RDP and SSH, enable Enforce Protected Browser.
Test DNS resolution and ZTNA access separately, with both positive and negative tests. A successful DNS test does not prove that ZTNA access works, or vice versa.

Prerequisites, licence and roles

Check the Workspace Protection licence for this integration. DNS Protection Direct does not require the endpoint DNS integration to be enabled. Only the endpoint DNS path, described separately below, requires an installed Sophos Endpoint agent and supported Windows endpoints. Windows Server and macOS cannot currently be added to the documented endpoint policy for this purpose. Detailed licence boundaries are outside the scope of this integration; Workspace Protection must be available in the tenant before the pilot. Endpoint installation is a prerequisite only for the endpoint DNS path.

For the ZTNA path, users and groups, identity provider, gateway, resources, policies, DNS and certificates must already work. Protected Browser extends this prepared access path; it does not replace any of these foundations. Set up Sophos ZTNA describes the sequence and acceptance testing.

Sophos does not specify a particular administrator role for this integration page. The person carrying out the work must therefore have demonstrated access to the required DNS Protection, ZTNA and Protected Browser objects, and the endpoint objects when using the endpoint DNS path, without being given Super Admin rights as a precaution. If a product or control is missing, first clarify the tenant, licence and assigned permissions.

Before the pilot, also record:

a small user and device group;
one permitted and one deliberately blocked public test domain;
an internal name that must continue to be resolved by the local DNS service;
a permitted ZTNA test resource and an unauthorised test user;
the previous resolver and access path as the rollback route;
the time, responsible person and expected result of each change.

Provide DNS Protection for Protected Browser

Direct DNS resolution in the browser

Review date 21 October 2026: Sophos reports that DNS Protection Direct is fully available. Its own DoH connection can be enabled under Protected Browser > Settings > DNS Protection. It can use a different filtering policy from the endpoint or network. Therefore, check against the security design which previously blocked destinations should become reachable in the browser. Its effect applies to the browser and does not prove DNS protection for other applications.

Before enabling it, record the previous state and specify the default behaviour or required DNS filtering policy. The default allows requests except those for high-risk domains and leaves further decisions to browser policies. Where needed, use Domain exclusions to have internal domains resolved by the local DNS service. The browser can trust the DNS Protection CA to display block pages correctly. Then test permitted and blocked domains, internal names and block pages in the browser; a comparison test outside the browser distinguishes this path from endpoint DNS. For rollback, restore only the browser setting changed to its documented baseline and repeat the same tests.

Existing endpoint DNS path

The older integration help still describes DNS Protection with Sophos Endpoint. The following readiness points apply to this separate path and are not prerequisites for DNS Protection Direct. Installation, package version, the complete endpoint policy, locations, filtering, domain exceptions, block pages, troubleshooting and rollback are therefore described centrally in Configure Sophos DNS Protection for endpoints.

For the endpoint DNS path, carry out this readiness check before the pilot:

The DNS component is installed on the pilot devices; depending on the licence, it may be called DNS and ZTNA.
The endpoint policy assigned to the pilot devices or groups is active and Use Sophos DNS Protection is enabled.
The selected Default location, or a custom location, uses the Secure DNS connection method. A newly created location must not use another connection method for this endpoint path.
The expected filtering policy is assigned to the location. One filtering policy can be assigned to multiple locations or firewalls, but each individual location can have only one filtering policy. If filtering needs checking, these limits also apply: DNS Protection supports a maximum of 50 filtering policies; Allow permits all categories in a group, Block blocks them, and Specify sets the action for each category. Create and modify filtering policies by following the linked guide.
The internal test name is included there as an exception so that the intended local DNS service continues to resolve it.

Sophos Endpoint then intercepts DNS traffic except for excluded domains and forwards it to DNS Protection over HTTPS. Responses go directly to the application. Without the integration enabled, the local DNS service processes requests as before. Domain lists, NXDOMAIN retry and certificate distribution are not configured again in this article; plan and check them by following the linked guide.

Provide ZTNA for Protected Browser

ZTNA must be fully configured before the browser integration. Protected Browser connects to the ZTNA gateway, enabling controlled access to internal applications and private cloud environments. The shared ZTNA configuration remains in the linked ZTNA runbook; it is not repeated here as a second, potentially divergent process.

For agentless access to applications and resources other than RDP and SSH, then enable Enforce Protected Browser. Sophos does not document a reliable menu path or additional form fields for this setting. Therefore, use the switch only in the ZTNA configuration visible in your own tenant. If it is missing, stop here rather than guessing a path from another product view.

RDP and SSH are a separate variant. Sophos requires a specific ZTNA configuration for agentless RDP or SSH resources. A general web application test or enabling Enforce Protected Browser alone does not validate this path.

Validate the pilot

Acceptance deliberately separates DNS and ZTNA. Start by testing exactly one pilot device with an authorised user.

Check the DNS result

Expected results:

The permitted public test domain resolves and is reachable.
The blocked test domain is blocked according to the assigned filtering policy.
The internal test name uses the intended local DNS service and remains reachable.
For the endpoint DNS path, requests appear under the expected location or in its associated DNS reporting. For DNS Protection Direct, check the browser setting and selected filtering policy separately.
Test an application with its own Secure DNS or DNS-over-HTTPS behaviour separately instead of extrapolating from a browser-only test to all applications.

If an expected event is missing, do not immediately loosen filtering. For the direct browser path, first check its setting and filtering policy. For the endpoint path, check the installed component, the endpoint policy that is actually active, Use Sophos DNS Protection, the Secure DNS location and the resolver actually in use. The linked guide contains further DNS troubleshooting.

Check the ZTNA result

Using the authorised user, open the prepared private test resource in Protected Browser. Success means that sign-in, ZTNA gateway, resource assignment and application work together. Then use a user outside the approved group to confirm the negative case: the resource must not be available or reachable to that user.

Log the DNS and ZTNA tests separately, including time and result. This makes it clear which path is affected by a later fault.

Troubleshooting by symptom

DNS does not work on the pilot device

First identify the affected DNS path. For DNS Protection Direct, check the browser setting, filtering policy, DoH connectivity, local domain exclusions and block page certificate. The following Windows check applies only to endpoint DNS, not the direct browser feature.

First check that it is a supported Windows endpoint, that Sophos Endpoint and the DNS component are installed, and that the effective active endpoint policy enables Use Sophos DNS Protection. Then check the selected Secure DNS location and HTTPS connectivity to DNS Protection. Windows Server and macOS are not suitable comparison tests for this endpoint policy path. Make policy, location, filtering, domain or rollback changes by following the linked guide.

If you also check a network-based location to narrow down the issue, it requires a valid public IPv4 address or a resolvable location FQDN. RFC 1918 addresses in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 are not valid public addresses for this purpose. However, not every address beginning with 172. or 192. is private, so do not use that shorthand as a test criterion.

DNS Protection is then not the first suspect. Check user and group assignment, the ZTNA resource, the selected gateway and application reachability from that gateway’s perspective. Then confirm that Enforce Protected Browser is active for the intended agentless access. Do not compare RDP and SSH with the general web application path.

If Enforce Protected Browser is missing or the process visible in the tenant is unclear, make no further configuration changes at this point. The responsible ZTNA team must clarify the licence, permission and current product view before anyone bypasses safeguards or creates resources again.

Safe rollback and offboarding

Do not dismantle DNS and ZTNA at the same time. Before any rollback, document the pilot devices, affected path, responsible person and last successful test result.

Roll back the endpoint DNS path by following the rollback procedure in the linked guide; for DNS Protection Direct, use the browser rollback described above. In both cases, then validate internal and public name resolution. Do not remove the shared software component named DNS and ZTNA as an immediate measure, because this could also affect the ZTNA path.

Sophos does not document a complete deletion or rollback procedure for Enforce Protected Browser. Therefore, for ZTNA, do not delete the gateway or identity, DNS, certificate or shared policy objects as a supposed immediate rollback. If access must be stopped, give the responsible ZTNA team the affected resource and user group, then repeat the negative test. Without a reversible step confirmed in the tenant, rollback stops at this point.

Operations and regular review

After the pilot, assign different people to the DNS and ZTNA paths. Repeat the relevant positive and negative tests after changes to the direct browser DNS setting, endpoint DNS configuration or user groups, the gateway or ZTNA resource. Regularly check Workspace Protection availability; for the endpoint DNS path, the installed component and its DNS readiness points; for the direct browser path, its setting and filtering policy; and ZTNA access and the documented rollback route.

Decisions about continued operation must be based on the current product configuration visible in the tenant and the current help for each component. Do not derive migration deadlines, shutdown dates or EOL dates from historical announcements. If Sophos changes a prerequisite or product view, rerun the pilot before adapting the wider rollout.