Integrate DNS Protection and ZTNA with Sophos Protected Browser

Sophos Protected Browser integrates DNS Protection and ZTNA through two separate operating paths. DNS Protection is not configured in the browser itself: Sophos Endpoint intercepts DNS requests from supported devices and forwards them to DNS Protection over HTTPS. 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 that you are working in the correct tenant. The integration page has no shared DNS/ZTNA switch.
Check the existing endpoint DNS configuration against the readiness points below and test it with a small Windows pilot group.
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

The DNS path requires a Workspace Protection licence, 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; before the pilot, you only need to confirm that Workspace Protection is available in the tenant and Sophos Endpoint is installed on the pilot devices.

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 endpoint, DNS Protection, ZTNA and Protected Browser objects, 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

The page under My Products > Protected Browser acts as a signpost for DNS Protection. It contains no local DNS configuration. 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 this Protected Browser integration, a readiness check before the pilot is sufficient:

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.
DNS requests from the pilot device appear under the expected location or in its associated DNS reporting.
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. First 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 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 DNS path only by following the rollback procedure in the linked guide, then validate both 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 endpoint DNS configuration or to user groups, the gateway or ZTNA resource. Regularly check Workspace Protection availability, the installed endpoint component, the DNS readiness points, 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.