Zero Trust

Before beginning, organisations should ensure they have a solid understanding of their current architecture. This will make design decisions easier, and help set realistic and well-defined goals for ZTNA implementation, avoiding the risk of carrying existing weaknesses into the new access model.

You should:

• identify the organisation’s users, devices, services and applications
• understand all data flows and user journeys
• recognise architectural constraints, legacy systems, and dependencies
• understand risks through threat modelling activities

1.1 Updating the threat model

ZTNA should either maintain or improve an organisation's security posture. Introducing ZTNA represents a change in how access is granted and enforced. As such, organisations should review and, where necessary, update their threat model before implementation.

This includes understanding:

• how existing threats are mitigated
• how those mitigations change when moving away from existing solutions
• any new risks which may be introduced

1.2 Implementing a zero trust strategy

ZTNA is not designed to operate in isolation. Before adopting ZTNA, organisations should have in place – or be developing – a wider zero trust strategy that includes the full range of architectural components: identity, devices, applications, services, data, and monitoring. See the NCSC’s guidance on demystifying zero trust and zero trust architecture design principles to understand more about the wider zero trust concept.

ZTNA depends on reliable signals about users, devices and activity. These signals allow policy decisions to be made and enforced consistently. Before ZTNA implementation, organisations should ensure the following prerequisites are in place.

2.1 Identity prerequisites

Strong identity foundations are essential for ZTNA because identity is the primary control used when making access decisions.

Organisations should have:

• An authoritative identity provider: an Identity Provider (IdP) acting as the single source of truth for user identities.
• Strong authentication: phishing‑resistant authentication methods such as FIDO2 credentials.
• Consistent authentication: single sign‑on (SSO) across applications so that all access is subject to the same authentication strength and policy.
• Defined user roles: clear understanding of what users need access to, and how many levels of access are required.
• Identity signals: contextual signals from the IdP that can inform access decisions.
• Identity governance: defined processes for creating, modifying, and removing user accounts.
• Timely de‑provisioning: user accounts are removed promptly when access is no longer required.
• Auditable activity: identity activity is centrally logged and available for monitoring and investigation.

2.2 Device prerequisites

Strong device foundations are essential for ZTNA to reliably enforce risk-aware access controls.

Organisations should have:

• Strong device identity: a cryptographically backed device identity uniquely bound to the physical device, using secure hardware such as a Trusted Platform Module (TPM).
• Centralised device management: authoritative oversight of organisational devices through a centralised device management platform, such as a mobile device management (MDM) system or equivalent.
• Baseline device security: enforced baseline security controls in line with the NCSC’s device security guidance, including device hardening, automatic patching, secure configuration, and minimising unnecessary exposure.
• Device posture visibility: visibility of device health and configuration status, including signals such as patch level, configuration state, and compliance with security policies.
• Endpoint monitoring: monitoring of device behaviour to inform access decisions, integrating where appropriate with endpoint security tooling such as Endpoint Detection and Response (EDR).
• Device posture signals: the ability for devices to provide signals that can be used when making access decisions.
• Device lifecycle management: clear ownership and management responsibility for devices, including processes for provisioning, ongoing management, and secure decommissioning.
• Auditable device activity: device activity is centrally logged and available for monitoring and investigation. See the NCSC’s logging and protective monitoring guidance for further information on what should be logged.

2.3 Internet access controls

Before protecting organisational resources using a zero trust approach, organisations should first establish a secure baseline understanding of how users and devices connect to the internet. Addressing common risks associated with general internet use helps ensure that broader zero trust controls are applied on top of a stable and well‑managed foundation.

Organisations should have:

• Malicious domain blocking: controls that prevent users and systems from accessing domains associated with known malicious activity.
• Internet traffic policy controls: the ability to enforce policy over internet traffic, for example, by restricting or blocking high-risk content based on characteristics such as file type, malware scan results, traffic behaviour or website category.
• Security logging for internet activity: comprehensive logs of internet access and security events that can support monitoring and alerting. These logs should be integrated into a centralised logging and monitoring capability, such as a security information and event management (SIEM) tool.

Organisations may choose to implement additional controls to strengthen internet access security, including:

• PDNS services: PDNS uses threat intelligence to prevent users from connecting to known malicious domains before a connection is established. See the NCSC guidance on PDNS for public and private sectors to find out more information.
• Client-side enforcement: controls on user devices, such as EDR solutions, which can enforce internet access policies and monitor user activity.
• Integrated internet filtering within ZTNA services: some ZTNA platforms also provide filtering for general internet browsing. These capabilities can help organisations meet the baseline controls described above while using a single access platform.

2.3.1  Deciding whether to tunnel internet traffic

Some ZTNA and Secure Access Service Edge (SASE) products encourage organisations to route, or tunnel, user internet traffic through the service. In this context, traffic from a user’s device is forwarded to a central policy enforcement point – such as a SASE, Secure Service Edge (SSE), or VPN service – before reaching its destination.

As most modern internet services use Transport Layer Security (TLS), which the NCSC believes provides appropriate levels of protection for data in transit, adding an additional encrypted tunnel for general web traffic may provide limited additional security benefit. In some cases, the performance, usability and complexity trade-offs may outweigh that benefit.

Where applications or services still rely on unencrypted protocols, organisations should prioritise removing or replacing them. Tunnelling may provide interim protection while this is addressed.

Organisations may choose to tunnel internet traffic where it enables a specific security outcome that cannot be achieved by other means. For example, tunnelling may support advanced content filtering, centralised monitoring, or consistent enforcement of organisational policy. However, tunnelling all traffic should not be treated as a default design choice. Decisions about whether to tunnel should be informed by the organisation's threat model, the capabilities of the products in use, and the organisational risk appetite.

2.3.2. Considerations for TLS inspection

Organisations sometimes consider using TLS inspection as part of their approach to controlling and monitoring internet‑bound traffic. Introducing TLS inspection can require encrypted connections to be terminated and re-established by an intermediary which has significant architectural and security implications. TLS inspection concentrates trust in a small number of systems and increases the impact of compromise, misconfiguration, or operational failure. Components that can decrypt large volumes of user traffic should therefore be treated as critical to the security of the system as a whole.

In many cases, the outcomes organisations seek from TLS inspection, such as detecting malicious activity, enforcing acceptable use, or applying security policy, can be achieved through alternative controls. For example, EDR, device posture signals, DNS protections, and application‑level logging can provide meaningful visibility and enforcement while reducing the need to introduce additional trust dependencies.

In some cases, inspection of traffic may be necessary; however, this should be done deliberately and transparently, with a clear understanding of the security and privacy implications. In these cases, it is important to understand how TLS inspection is benefiting the organisation and whether alternative controls can result in the same outcome.

Where TLS inspection is deployed, organisations should recognise that they are placing a significant amount of trust in the inspecting component and the organisation operating it, including how decrypted data is handled, protected, and secured in operation. As with other critical security services, this trust should be supported by appropriate assurance, transparency, and supply‑chain risk management.

TLS inspection should not be treated as a default component of internet access, and the trade‑offs involved should be explicitly understood and documented.

Adopting ZTNA commonly involves introducing a third-party service into a critical access path for users, devices, and applications. This creates a dependency on an external provider and moves part of the organisation’s trust boundary outside its direct control. As a result, selecting a ZTNA service should be treated as a risk management and assurance decision rather than solely a procurement activity.

Many vendors offer broad platforms that combine several security capabilities and may market these as delivering ‘zero trust’. However, zero trust is an architectural approach rather than a single product. Purchasing a product alone won’t deliver zero trust outcomes without appropriate architectural design and integration.

When assessing ZTNA services, organisations should focus on how a product supports their intended architecture and security objectives. They should also understand how the introduction of the service changes the trust model as several decisions may now be handled by a cloud provider.

Organisations should ensure they understand the trust they are placing in the provider, how that trust is justified, and how it will be maintained over time. For further information, see the NCSC’s guidance on evaluating and trusting a cloud supplier.

Before selecting or deploying a ZTNA product, organisations should undertake the following measures:

3.1 Understanding the trust relationship

3.2 Gaining confidence in a product

3.3 Assurance over security and operation