Zero trust: a complete guide to ZTNA and zero trust architecture

What is zero trust?

Zero trust is a security model built on the principle that no user, device, or system should be trusted by default, regardless of where it is located. In a traditional network security model, devices and users inside the corporate network were generally trusted once they had passed through a perimeter control. Zero trust removes that assumption. Every access request is verified, every connection is evaluated against policy, and access is granted only to what is specifically needed rather than to the network as a whole.

The model emerged in response to a straightforward problem: the perimeter-based security model was designed for a world of fixed offices, on-premises servers, and a clear boundary between inside and outside. That world no longer exists for most organisations. Users access systems from home, from branch sites, from mobile devices, and through cloud services that sit outside the traditional perimeter. The perimeter itself has dissolved. Zero trust replaces the perimeter with a policy layer that travels with each access decision, wherever that decision is made.

The three core principles

Zero trust is often described through three principles that, taken together, define the model.

• Verify explicitly. Access decisions are based on multiple signals: who the user is, what device they are using, its security posture, where the request is coming from, what application is being accessed, and what the risk context is. No single signal is sufficient on its own. The decision is made by evaluating all of them together, continuously rather than once at login.
• Apply least privilege access. Users and systems are granted access only to the specific resources they need, for the period they need it. Not to the network. Not to a broad set of systems that happen to share a VLAN. Just the application, data, or service the request is for. This limits the blast radius if credentials are compromised or a device is affected.
• Assume breach. The architecture is designed on the assumption that a breach will occur or already has occurred. This shifts the design goal from keeping threats out of the perimeter to containing and detecting them when they are inside. Monitoring is continuous. Traffic is inspected. Anomalies are detected against a verified baseline rather than assumed to be legitimate because they originate inside the network.

Zero Trust Network Access (ZTNA)

Zero Trust Network Access is the technical implementation of zero trust principles for remote and application access. It is the modern replacement for remote access VPN, and the distinction matters in practice.

A VPN places a remote user on the corporate network – effectively extending the trusted interior to wherever the user happens to be. From there, the user’s access is governed by whatever network controls exist. ZTNA works differently: it creates a direct, encrypted connection between the user and the specific application they need, without placing the user on the network at all. The user never has network-level access. They have application-level access, verified continuously against policy.

The practical consequences are significant. A ZTNA connection reduces the attack surface substantially: a compromised device on a VPN connection can potentially access everything the user can reach on the network; a compromised device on a ZTNA connection can only reach the specific applications the policy allows, and only while the connection continues to pass verification. For organisations managing multi-site estates with many remote users or third-party supplier connections, this containment is operationally important.

ZTNA also improves the user experience relative to VPN in most environments. Connections are application-specific and therefore faster to establish. There is no requirement to connect to a VPN endpoint before accessing cloud-hosted services. And the performance degradation that affects VPN connections under load is largely absent from ZTNA architectures.

Zero trust architecture: the components

Implementing zero trust requires several components working together. No single product delivers zero trust; it is an architecture.

• Identity and access management is the foundation. Every user needs a verified, managed identity. Multi-factor authentication is required. Role-based access controls need to reflect actual job requirements, not historical access that has accumulated over time. For privileged access – administrative accounts, emergency access, accounts with elevated rights – specific controls and detailed audit trails are required.
• Device trust extends identity verification to the devices making access requests. A managed, patched, encrypted device presents a different risk profile from a personal device with an unknown security posture. ZTNA access policies can incorporate device health into the access decision, allowing organisations to apply different levels of access depending on whether the device meets the minimum security bar.
• Network micro-segmentation divides the network into isolated segments, each with its own access controls. Clinical systems sit in a different segment from corporate systems, which sit in a different segment from guest access. Inter-segment communications are governed by explicit policy rather than permitted by default. This limits lateral movement: if one segment is compromised, the segmentation contains the blast radius and prevents the compromise spreading across the estate.
• Continuous monitoring and analytics gives the architecture its ongoing verification capability. Access decisions are not made once and assumed to remain valid. User behaviour, device posture, and traffic patterns are monitored continuously. Deviations from verified baselines trigger alerts or automated responses. This is also where the compliance evidence is generated: the logs, access records, and policy enforcement history that regulated organisations need to produce at assessment time.
• Policy management ties it together. Zero trust policies define what each user or system can access, under what conditions, from what devices, and from what locations. Managing those policies centrally – rather than distributed across individual systems and network devices – is what makes the architecture operable at scale.

Zero trust in regulated environments

For NHS organisations, government departments, and policing, zero trust addresses a specific version of the broader problem. These organisations typically have complex, multi-site estates, significant numbers of third-party supplier integrations, and compliance obligations that require them to evidence their security controls continuously rather than at annual review.

The DSPT, CAF, and PSN Code of Connection all have expectations around identity management, access governance, monitoring, and incident response that zero trust architecture directly addresses. An organisation that has implemented zero trust and is generating continuous access logs, policy enforcement records, and anomaly alerts is in a considerably stronger position at assessment time than one relying on perimeter controls that cannot produce that evidence.

Third-party access is a specific area where zero trust is particularly valuable for regulated organisations. Supplier and partner access to clinical or government systems is a significant attack vector. ZTNA applied to third-party connections means that suppliers access only the specific systems they need, that access is time-limited and audited, and that a compromised supplier credential does not provide access to the broader estate.

The hybrid working context is the other driver. Clinical staff, government workers, and officers in the field all need access to systems from locations and devices outside the traditional network perimeter. Zero trust provides consistent security policy across all of those access scenarios without requiring users to connect through centralised VPN infrastructure that was not designed for the volume or variety of modern hybrid working.

Implementation: a phased approach

Zero trust is not deployed in one step. Most organisations implement it progressively, starting with the highest-risk access patterns and extending coverage over time.

A typical phased approach begins with an assessment of the current identity and access management estate: who has access to what, through which systems, and how that access is governed and audited. From that baseline, the first implementation phase establishes MFA and strengthened identity governance for the highest-risk users and systems. Device compliance requirements follow, then application-level ZTNA for remote and third-party access. Network segmentation is typically implemented in parallel, starting with the most critical network boundaries. Monitoring and analytics are built out as the architecture develops and as the baseline of verified behaviour is established.

The phasing is pragmatic rather than prescriptive. The right starting point depends on where the greatest risk currently sits: an organisation with a large remote workforce may start with ZTNA; an organisation with poor network segmentation may prioritise that first.

How Cloud Gateway delivers zero trust

Cloud Gateway’s Secure Private Access (SPA) product delivers ZTNA as part of the Secure Access suite within the Protect pillar. SPA creates verified, application-specific connections for remote users, third-party suppliers, and inter-site access, without placing those users on the network. Network segmentation and continuous monitoring are delivered alongside SPA through the managed platform, with policy managed centrally and evidence generated as a by-product of the service.

For regulated organisations, the platform generates the access records, policy enforcement logs, and monitoring data that DSPT, CAF, and PSN assessments require, without those records needing to be assembled separately before each assessment cycle.

For more on how SPA and the wider Secure Access suite works, see our Secure Private Access page and our platform page.