Setting up Sophos ZTNA: overview and order

Sophos Zero Trust Network Access, ZTNA for short, does not simply replace a VPN with a new button. ZTNA consists of identity, gateway, resources, policies, DNS, certificates and a client or agentless access path. If these building blocks are set up in the wrong order, the login may work, but the application will still remain inaccessible.

This article classifies the setup and shows the sensible order. For the specific gateway part, Plan and create Sophos ZTNA Gateway is also suitable.

For the vendor-neutral basics of Zero Trust, ZTNA and the distinction from VPN, start with Zero Trust explained simply: ZTNA instead of classic VPN.

Requirements

Before a ZTNA test, these points should be clarified:

Sophos Central Account with appropriate ZTNA license or test environment.
Microsoft Entra ID, formerly Azure AD, or a supported identity provider with maintained users and groups.
Decision between agentless access, ZTNA client or mixed operation.
Gateway model: On-premise Gateway, Sophos Cloud Gateway or Sophos Firewall as a gateway variant.
DNS names for gateway and published resources.
Wildcard certificate or matching certificate concept.
Internal accessibility of the applications from the perspective of the gateway.
Owner for policies, certificates, logs and subsequent changes.

Enable Sophos Central ZTNA

If ZTNA is not yet active, the test can be prepared using an existing or new Sophos Central account. It is important that the tenant, the user source and the subsequent resources match the planned test. A ZTNA test without a real target application says little about latency, DNS, browser experience or policy design.

Getting started via the Sophos test page can be useful for initial laboratory environments: Create a Sophos Central test account.

Plan certificate and DNS

ZTNA requires a certificate that matches the planned gateway and resource domains. In many environments, a wildcard certificate is the simplest option because multiple resources can be published under the same domain.

For productive environments, you should clarify the expiry date, renewal, responsibility and monitoring of the certificate. Let’s Encrypt can be useful for testing if a suitable wildcard certificate does not yet exist. The process is in Create Let’s Encrypt wildcard certificate.

Setup order

For a clean ZTNA rollout, the order should not be chosen arbitrarily:

Add directory service: Sync Microsoft Entra ID or another supported directory service with Sophos Central.
Add identity providers: Set up the identity providers required for authentication.
Add gateway: Plan and deploy the appropriate gateway model for each location or data path.
Create resources: Define applications with FQDN, port, access type and accessibility.
Add policies: consciously assign user groups, conditions and permitted resources.
Test client or agentless access: Verify with pilot users that sign-in and application work.

1. Sync users

For ZTNA, Sophos Central needs users and groups that will later be used in policies. In Microsoft environments, Microsoft Entra ID is the typical entry point. It is crucial that only the required groups are used and that names, UPN, email addresses and group memberships can be traced later.

The basis is in Add Sophos Central Azure AD.

2. Add identity provider

After the directory service, the identity provider is set up. For Microsoft Entra ID, these typically include Client ID, Tenant ID and Client secret. These values are security-relevant configuration data and should be treated like access data.

3. Add gateway

The ZTNA Gateway connects user access to internal applications. Depending on the design, it stands as an on-premise gateway in your own network, is operated via Sophos Cloud Gateway or uses a supported Sophos firewall variant.

Gateway planning is a separate work step because DNS, certificate, network segment, DNAT, internal accessibility and logs have to fit together. The process is in Plan and create Sophos ZTNA Gateway.

4. Create resources

Resources are the applications that should be accessible via ZTNA. To do this, you should document the following for each application:

internal FQDN or internal destination IP,
protocol and port,
Access type, for example web app or TCP app,
required user group,
desired external name,
Test user and acceptance criteria.

A resource should not be published more widely than necessary. Especially with admin tools, RDP, SSH or internal specialist applications you need clear groups, logging and an owner.

5. Add policies

Policies connect user groups to resources. In practice, you should start with a small pilot group and not immediately activate entire departments or all employees.

Good policy questions:

Which group really needs this application?
Is agentless access sufficient or is the ZTNA client required?
Does access need to be restricted by device, condition or location?
How is logging done and who checks failed attempts?
Is there a fallback path if ZTNA or the identity provider is disrupted?

6. Test access

After setup, it’s not just the login that should be tested. What is crucial is whether the real application can be achieved and whether the policy works exactly as planned.

Checkpoints:

Test user is in the correct group.
DNS points to the expected gateway or CNAME.
Certificate is accepted without browser warning.
Registration with the identity provider works.
The resource opens with the scheduled access type.
Unauthorized users are clearly rejected.
Logs in Sophos Central, Gateway and Firewall can be evaluated.

Common mistakes

Gateway, DNS and certificate are only checked after the policies.
Resources are published too widely.
Test users have more group memberships than regular users.
Internal DNS resolution only works on the LAN, but not from the gateway’s perspective.
ZTNA is planned to replace any VPN or admin connection, although some special cases may still require VPN, Jump Host, or another access model.