Zero Trust

Network traffic must be transported securely, in line with the NCSC zero trust principle of: don’t trust any network, including your own. ZTNA architectures must ensure that all network traffic between users, devices and applications is protected against interception, tampering and impersonation. Traffic should be cryptographically secure throughout its journey, regardless of whether the underlying network is private, public or internal to an organisation. Organisations must ensure this protection is consistently enforced.

Secure transport mechanisms

Organisations should ensure that only strong cryptographic protocols, cipher suites, and key lengths are used and that insecure or deprecated options are disabled. Typically, the traffic should be protected using secure protocols such as TLS or IPsec. Where applications already support strong TLS directly between the client and the application, traffic can be protected without additional tunnelling. TLS or IPsec should be configured in line with the NCSC’s guidance on using transport layer security to protect data and using IPsec to protect data.

Secure transport as a supporting control

Secure transport is a foundational requirement that enables ZTNA, but alone does not imply trust. Even when traffic is encrypted and authenticated, access decisions should still be driven by policy engines and signals. Secure transport must operate in support of broader zero trust controls rather than replace them.

In a ZTNA architecture, access to resources must be explicitly authorised by policy, before any connection is established, in line with the zero trust principles to use policies to authorise requests and authenticate and authorise everywhere. Users and devices should not gain access simply because they are connected to a corporate network, using a VPN, or operating from a known location. Instead, every access request should be evaluated against defined policies that reflect the organisation's security requirements, risk appetite, and threat model.

Just enough access

Enforcing policy before granting access ensures resources are not exposed to unauthorised or non-compliant users or devices. ZTNA solutions that only provide secure connectivity without enforcing policy decisions do not meet the intent of zero trust.

Users should only be able to reach the resources they are explicitly authorised to use, and no others. This reduces the attack surface and limits the impact of compromised credentials or devices.

Policy enforcement points

Depending on the architecture, policy enforcement may occur at either network or application layer (see the section on signals and policy engines for details). They can be used independently or together, but the security outcome should be consistent: applications are not exposed until policy has been satisfied.

Access decisions in a ZTNA architecture should be informed by multiple signals, rather than rely on any single attribute such as network location, user identity, or device ownership.

Why multiple signals are needed

Using multiple signals is consistent with the zero trust principle to use policies to authorise requests. No individual signal is sufficiently reliable on its own. Combining signals provides greater confidence in access decisions and makes it harder for attackers to bypass controls.

Signals should collectively describe:

• who is requesting access
• what device they are using
• whether the device is sufficiently secure

This allows organisations to make proportionate, risk-based decisions that reflect both the sensitivity of the application and the threat environment.

Core signals

As outlined in the signals and policy engine section of this guidance, at a minimum, organisations should establish a baseline set of signals that support strong assurance. In most environments this will include:

• user identity – to establish who is requesting access
• device identity – to confirm the request originates from a known or managed device
• device health – to assess whether the device is in an acceptable security state
• user behaviour – to help identify anomalous or high-risk behaviour

Selecting and managing signals

The exact combination of signals used will vary depending on the organisation's architecture, applications and risk appetite. Signals should be selected deliberately, with a clear understanding of what each signal contributes to the access decision and its limitations. The choice of signals should not be static. As threats evolve and new capabilities become available, organisations should review and adapt the signals used to inform access decisions.

Signals inform access policy decisions, but you should avoid excessive policy granularity, as it can quickly become difficult to manage and maintain. Where possible, access policies should be standardised into a small number of well-defined categories, such as guest access, standard business access, and access to critical applications.

ZTNA architectures should minimise the exposure of applications by ensuring they are not directly reachable from untrusted networks. Reducing application exposure limits attack surface, constrains attacker reconnaissance, and is in line with the zero trust concept of least privilege.

Applications should only be reachable after access has been authorised, and exposure should be limited to the specific applications a user is permitted to access. Broad network access, even when encrypted, undermines ZTNA objectives and increases the potential impact of credential compromise.

Private applications

For privately-hosted applications (for example on-premises, private cloud, or private networking in a public cloud), access should be mediated using components designed to be exposed to an untrusted network such as an outbound-only connector, proxy or VPN endpoint.

Where possible, these components should be deployed close to the applications they protect and scoped narrowly, limiting which applications or services they can reach. This reduces the risk of lateral movement if a connector or user session is compromised.

SaaS applications

For SaaS applications, organisations typically don't control the underlying network or hosting environment. In these cases, exposure should be managed at the identity and application layer rather than the network layer.

Access to SaaS applications should be integrated with enterprise single sign-on (SSO) and protected by the application-level policy engine. This ensures that access decisions are made during authentication and users only obtain access when organisational policy is satisfied. Organisations should set permissions following the principle of least privilege and this should be a feature of the SaaS application, not the policy engine.

Even though SaaS applications are by design internet-facing, ZTNA principles still apply. Access should be mediated, explicitly authorised and limited to what is necessary.

ZTNA architectures should be designed on the assumption that network compromise will occur and that the impact of such a compromise needs limiting. This is achieved by minimising blast radius – the scope of systems and data exposed if a user, device or component is compromised – and by restricting lateral movement between segments.

Network segmentation

Network segmentation is fundamental to minimising impact of compromise in ZTNA private access solutions. Large, flat networks without segmentation allow attackers to bypass security controls and are considered an anti-pattern. The appropriate segmentation model will vary depending on organisational structure, application architecture, and risk profile.

Each application should reside in an appropriately-sized network segment based on risk and business criticality. Access to each segment should be mediated through a connector, proxy or network security device (such as a VPN appliance, physical or virtual firewall), under the control of a network-level policy engine. This ensures that traffic can only reach a segment when access has been explicitly authorised. These components should be deployed in tightly-constrained environments, with defence‑in‑depth controls.

ZTNA controls don't remove the need for local network segmentation. ZTNA determines which segments a user can access, while traditional controls – such as firewalls, security groups, and network access control lists – restrict movement between segments after access is granted.

Segmentation model

In an ideal design, each application resides in its own isolated network segment, but this is often impractical and doesn't scale well. A more realistic and widely adopted approach is to group applications based on risk or business criticality, for example:

• Low-risk, broadly accessible applications: internal services, such as company news portals or restaurant menus, can share a segment since compromise or temporary unavailability would have limited impact.
• Medium-risk, department-specific applications: systems used by specific business functions (for example, HR, Finance, or Engineering) reside in smaller, dedicated segments to limit exposure.
• Critical business applications: services essential to business continuity or processing sensitive data, such as payroll systems, customer databases, or repositories of sensitive documents, are isolated in dedicated segments.

Organisations should consider using automation techniques, such as Infrastructure as Code (IaC), to define and manage network segments, access rules, and dependencies. This supports segmentation at scale and can reduce the operational burden of maintaining many small segments, making it easier to review, test, and evolve segmentation decisions over time.

ZTNA solutions should support contextual re-evaluation of a policy during a session. User behaviour, device posture, and risk conditions can change over time, and access decisions should reflect this. Where the conditions required for access are no longer met, access should be restricted or revoked. This reduces the window of opportunity for attackers and limits the impact of compromised credentials or devices.

Token lifetimes and policy re-evaluation

Using short-lived credentials or tokens is a common way to support continual policy enforcement without significantly affecting the user experience. When access tokens have a limited lifespan, policy engines are forced to re-evaluate policy before issuing a new token. Token lifetimes should be proportionate to the sensitivity of the application and the organisation’s risk appetite.

Event-driven enforcement

Where available, organisations should use near real-time or event-driven enforcement. These allow accesses to be actively terminated if contextual conditions change, for example, if a device falls out of compliance, a user risk score increases, or suspicious activity is detected. They also reduce reliance on token expiry alone.

ZTNA architectures should be designed to be observable.

Importance of visibility

This visibility enables organisations to, for example:

• understand how access decisions are made
• detect suspicious activity
• support investigation and incident response

ZTNA solutions should generate high-quality, security-relevant logs for both successful and unsuccessful access attempts. These logs should include sufficient context to explain why an access decision was made, for example the identity involved, the application accessed, the time of the request, and the policy or authentication method used to make the decision.

ZTNA architectures are composed of multiple components, such as identity providers, policy engines, connectors, proxies, endpoint security tools, and SaaS platforms. Organisations should ensure they can collect and correlate logs from these different sources to build a coherent view of user activity and access decisions. Without this visibility, activity that spans multiple systems may be difficult to detect or investigate.

Key logging events

At a minimum, ZTNA architectures should log the following events:

• Successful access requests, including the identity involved, the application accessed, and the time and method of authorisation.
• Denied or blocked access attempts, including the reason for denial where available.
• Changes in signals or context that affect access decisions, such as a device becoming non-compliant or a change in user risk level.

Logs should be centralised into a monitoring capability such as a security information and event management (SIEM) platform to support correlation and analysis.  Organisations should retain logs in line with operational and regulatory requirements, protect them from unauthorised access or tampering, and ensure they are actively monitored and reviewed.

Effective observability supports both security and operational assurance. Logging and monitoring enable organisations to validate that access policies are working as intended and identify overly-restrictive controls. This helps organisations to refine and improve their ZTNA implementation. Further information on developing logging use cases is available in the NCSC guidance for Security Operations Centres on onboarding systems and log sources.

ZTNA architectures should be designed to maintain service availability while enforcing strong access controls. If policies are overly restrictive or incorrectly configured, legitimate users may be blocked from the services they need. This can disrupt business operations and reduce confidence in the access control system. Availability should therefore be treated as a core design consideration.

Testing and safe policy rollout

Organisations should design ZTNA policies with the expectation that failures will occur. Devices may temporarily fall out of compliance, identity attributes may change, or security signals may become unavailable. ZTNA architectures should handle these situations safely, allowing users to recover access without weakening security controls.

Where possible, organisations should test policies before enforcing them. Testing allows organisations to understand how policies affect legitimate access and identify unintended consequences before users are impacted. Phased or conditional rollout of new policies can further reduce the risk of widespread disruption.

Recovery mechanisms

ZTNA designs should also include clear recovery paths for common access failures. For example, organisations should consider:

• allowing non-compliant devices to access remediation services (such as update or patching systems), rather than blocking access entirely
• providing clear user or support processes to resolve access problems quickly
• ensuring support teams have sufficient visibility to diagnose policy-related access failures

Organisations should also plan for recovery from more serious failures, such as misconfiguration or service outage. Managing ZTNA infrastructure and policy configuration using IaC can help support this. Defining ZTNA components, access policies, segmentation rules and dependencies as code enables organisations to:

• restore environments quickly and consistently after failures
• reduce configuration drift across environments
• manage changes safely through version control, review and rollback

Emergency access

Organisations should implement a break glass or emergency access mechanism for use during incidents or recovery scenarios. Break glass access should be tightly restricted to designated accounts and devices, and used only when normal access mechanisms are unavailable. Organisations should ensure that such access:

• bypasses standard policy enforcement only when necessary
• triggers heightened monitoring and alerting
• is tested regularly to ensure it functions as intended
• is subject to strict governance, auditing, and post-incident review

Designing for availability helps ensure ZTNA controls remain effective and trusted. By planning for failure, testing policies carefully, and providing safe recovery mechanisms, organisations can enforce zero trust principles without unnecessarily preventing legitimate access.