Zero Trust explained simply: ZTNA instead of classic VPN

Zero Trust does not mean that nobody is trusted anymore. It means that access is no longer granted broadly just because a user is on the internal network, in the VPN or at a known location. Every access attempt is checked deliberately: Who is accessing? From which device? To which application? Under which conditions?

Zero Trust Network Access, or ZTNA, is a concrete implementation of this idea for remote access and private applications. Instead of opening an entire network through VPN, a user receives access only to the applications or resources intended for their role.

This article explains the basics deliberately vendor-neutrally. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access and other solutions implement similar principles in different ways. The first decision is therefore not the product, but the access model.

Classify Zero Trust and ZTNA

Zero Trust is a security architecture. ZTNA is a technical access path within that architecture.

Zero Trust is a principle

Classic networks often work with an implicit assumption: inside is more trusted than outside. That assumption is dangerous today. Users work remotely, applications live in SaaS, data centers and cloud platforms, devices constantly change location, and compromised credentials are realistic.

Zero Trust shifts the focus from network boundaries to identity, device, application, data and context. NIST describes Zero Trust as an architecture that reduces implicit trust and evaluates access per request. In practice, a successful login alone is no longer enough.

ZTNA is access to specific resources

ZTNA replaces broad network access with resource-based access. A user does not automatically see an entire subnet, but only the applications for which a policy matches.

Typical ZTNA resources are:

• internal web applications,
• admin portals,
• RDP or SSH access through controlled paths,
• individual TCP applications,
• development, support or partner access,
• SaaS applications with additional access control.

This makes remote access more granular. A compromised account should not immediately be able to reach the entire internal network.

Why ZTNA is different from VPN

VPN is not automatically bad. Many environments still need site-to-site VPN, admin VPN, special protocols or emergency access. The difference is the trust model.

VPN often opens a network

A classic remote access VPN connects a device to an internal network. Routing, firewall rules, DNS and segmentation then decide what is reachable. If the environment is built cleanly, this can work. In practice, VPN networks are often too broad, historically grown or hard to review.

Typical risks are:

• Users receive access to more systems than necessary.
• Old VPN groups remain in place.
• Split tunnel, DNS and routes are unclear.
• Malware on a VPN client can reach internal targets.
• Admin access uses the same tunnel as user access.

ZTNA checks closer to the application

ZTNA decides per application or resource. A policy can consider user group, MFA, device, location, risk, client status and other conditions. Only when the conditions match is access to exactly that resource allowed.

This reduces the attack surface, but it does not replace secure application design. An insecure application remains insecure even behind ZTNA. ZTNA controls access, not automatically the application itself.

Building blocks of a good Zero Trust environment

Zero Trust is weak when it is introduced only as a new access tool. Its value comes from several building blocks that fit together.

Identity and MFA

Identity is the most important entry point. Users, groups, roles and external accounts must be maintained cleanly. MFA should be mandatory for critical access. In Microsoft environments, Microsoft Entra ID is often the central identity source; in other environments, other identity providers can take the same role.

Offboarding is just as important. When a user leaves the company, access must disappear not only in one application, but in the central identity and all relevant policies.

Device and context

ZTNA becomes stronger when not only the user but also the device is evaluated. Depending on the solution, operating system, device status, certificate, EDR status, management status, location or risk can influence the decision.

This is especially relevant for:

• personal devices,
• external service providers,
• privileged admin access,
• access to finance, HR or production systems,
• devices without current protection status.

Gateway, connector or cloud service

ZTNA needs a data path between user and application. Depending on the provider, there are gateways, connectors, tunnels or cloud PoPs. This part determines where traffic enters, who operates the data path and which DNS, certificate and firewall rules are required.

Cloudflare often works with Cloudflare Tunnel and Access Policies. Sophos ZTNA uses Sophos Central, ZTNA Gateways and resource policies. The architecture is different, but the core question remains the same: How does a user reach an application in a controlled way without opening the whole network?

Policies, logging and operation

A ZTNA policy must remain understandable later. Names, groups, conditions and exceptions should therefore be documented. Logging is mandatory, because otherwise it is impossible to see whether a policy is too broad, users are blocked or access is used unexpectedly often.

When ZTNA makes sense

ZTNA fits especially well when individual applications should be reachable in a controlled way. It is not an end in itself and not an automatic replacement for every connection.

Good use cases

ZTNA usually makes sense for:

• internal web applications for employees,
• partner or service provider access,
• admin portals that should not be publicly reachable,
• RDP or SSH through controlled access paths,
• applications with clear user groups,
• environments where VPN access has become too broad,
• gradual replacement of old remote access models.

For external service providers in particular, ZTNA is often more comfortable than VPN. Instead of exposing an entire network, one concrete application can be published with a clear policy.

Where VPN still fits

VPN remains useful when entire networks must be connected, when special protocols do not work cleanly through ZTNA or when emergency access must be independent from cloud services. Site-to-site links, some OT environments, legacy applications and complex admin scenarios can still require VPN.

The right question is therefore not: “VPN or ZTNA?” A better question is: “Which resource needs which access path?”

Evaluate vendors neutrally

ZTNA solutions differ significantly. Some are very good for browser-based applications, others for client-based access, and others as part of a broader SSE or SASE platform.

Important selection criteria

Before choosing a product, clarify these points:

• Which applications must be reachable?
• Is browser-based access, client access or both required?
• Which identity provider is already set?
• Should devices be checked based on posture?
• Where is the data path: own site, provider cloud or both?
• How do logs, SIEM export and audit work?
• Are emergency and break-glass processes clear?
• How well does the solution fit existing firewalls, EDR, MDM and DNS?

Cloudflare is often strong when Access, Tunnel, DNS, web security and global edge infrastructure should work together. Sophos ZTNA often fits well in environments that already use Sophos Central, Sophos Endpoint or Sophos Firewall heavily. This is not a belief question, but architecture work.

Not every Zero Trust setup is automatically better

Poorly maintained ZTNA is only a more modern risk. If groups are too broad, old exceptions remain, nobody reads logs or device checks exist only on paper, no strong Zero Trust environment is created.

Roll out in a sensible order

A good rollout does not start with the product click, but with a small, well-understood application.

1. Inventory applications and sort them by risk.
2. Clean up user groups and external roles.
3. Stabilize identity provider and MFA.
4. Select a pilot application that is important but manageable.
5. Plan data path, DNS, certificate and logging.
6. Test the policy with a small user group.
7. Review logs, collect support cases and improve user experience.
8. Migrate additional applications step by step.
9. Reduce VPN access only after ZTNA works in operations.

For Sophos-specific environments, Set up Sophos ZTNA: overview and sequence is the next step. If the gateway is the concrete topic, Plan and create Sophos ZTNA Gateway helps.

Common mistakes

Treating ZTNA as a pure VPN replacement project

If only the tunnel is replaced while groups, applications, devices and logs stay unchanged, there is little security gain. ZTNA should be planned per resource.

Migrating too many applications at once

A large big-bang rollout is risky. A pilot with a real application, clear success criteria and a clean fallback path is better.

Forgetting emergency access

Identity provider, DNS, cloud service or gateway can fail. Admins need a documented break-glass access that is strongly protected, rarely used and reviewed regularly.

Not operating the logs

ZTNA without logging is hard to support. It should be visible which user accesses which resource, which policy applies, why access was blocked and whether unusual patterns emerge.

Operational checklist

• Document applications and owners.
• Keep user groups small and understandable.
• Enforce MFA for critical access.
• Use device checks actively if the solution supports them cleanly.
• Review policies regularly against real usage.
• Send logs to a SIEM or central logging if access is critical.
• Document and test break-glass access.
• Remove old VPN permissions after successful migration.
• Give service provider access an expiration date or review date.

FAQ