In short
The NCSC ZTNA guidance, published on 27 May 2026, explains how to design zero trust network access that matches zero trust principles. It covers four signal types and two kinds of policy engine, prerequisites, how to assess providers, eight design requirements, reference architectures and four anti-patterns. It is not a checklist and does not prescribe a single solution.
Get a quote for a ZTNA design review
Tell us roughly how many users or sites you have and we will reply by email with options and a quote.
What the NCSC published and who it is for
The guidance sits in the NCSC's Zero Trust collection under Zero Trust Network Access (ZTNA), with a downloadable PDF, and was introduced in the NCSC blog post Designing secure access with ZTNA on 27 May 2026. It is aimed at architects, security practitioners and technical decision makers responsible for designing or evolving access architectures.
The starting observation is that ZTNA tools are widely deployed but often still built on old trust assumptions, with network location treated as the main signal of trust. The NCSC is clear about the guidance's limits: in the blog's words it does not "prescribe a single technical solution" and is not intended to be used as a checklist or compliance framework. It treats ZTNA as one part of a wider zero trust architecture; our page on the NCSC zero trust principles covers that wider picture.
The six sections
| Section | What it covers |
|---|---|
| Introduction to ZTNA | ZTNA as an architectural approach: connectivity alone does not grant access, and each request is explicitly authorised; contrast with the walled-garden model; private application and SaaS access |
| Signals and policy engines | The four signal types, network-level and application-level policy engines, and layering them |
| What to do before building a ZTNA architecture | Readiness, identity, device and internet access prerequisites, and assessing ZTNA services and providers |
| How to implement ZTNA | Eight design requirements |
| ZTNA reference architectures | Illustrative designs for connecting to a private application and connecting to SaaS |
| ZTNA anti-patterns | Four common design mistakes and how to avoid them |
Not sure which option fits? Ask us
Tell us what you need and we will recommend the right option for your organisation, with a quote.
Signals and policy engines
The NCSC says to prioritise four categories of signal: user identity, device identity, device health and user behaviour. It recommends a baseline set drawn from these, using signals from several independent sources so that no single control carries the whole decision, and reviewing them as threats change. Sign-in location is described as weak on its own but useful alongside stronger signals.
It then describes two kinds of policy engine:
- Network-level: controls which network destinations a client can reach, instructing an enforcement point such as a proxy or connector to forward traffic. VPN as a service, SSE and SASE platforms are given as examples. (The NCSC writes "Secure Service Edge"; the common industry term is security service edge.)
- Application-level: authorises access to a specific application, often through the identity provider or SSO, issuing a short-lived token. The guidance favours OAuth 2.0 and OpenID Connect for API access, non-human identities and continuous enforcement, while accepting SAML for browser-based human access.
Whichever layer is used, access should be explicitly authorised, based on multiple signals, and centrally logged and auditable. The mechanics are walked through on how ZTNA works.
Before you build: readiness and prerequisites
The guidance asks organisations to check they are ready before choosing technology:
- Readiness: understand users, devices, services, data flows, legacy constraints and dependencies; update the threat model, since ZTNA changes how access is granted; and have, or be developing, a wider zero trust strategy.
- Identity prerequisites: an authoritative identity provider, phishing-resistant strong authentication such as FIDO2, single sign-on, defined roles, governance over account changes, prompt de-provisioning and central logging of identity activity.
- Device prerequisites: cryptographically backed device identities (for example TPM-based), central management such as MDM, baseline security controls, visibility of device health, endpoint monitoring such as EDR, clear lifecycle ownership and central logging.
- Internet access controls: secure general internet use first, by blocking known malicious domains, enforcing traffic policy and logging internet activity centrally. The NCSC says tunnelling all web traffic through a central point should not be the default, and that TLS inspection concentrates trust and should be a deliberate, documented decision rather than a default.
For many organisations the identity and device prerequisites are the largest part of the work, so it pays to assess them early. See ZTNA vs IAM on why identity comes first.
Is a ZTNA design review the right fit for you?
We will check it against your systems and requirements and recommend the right option.
Assessing ZTNA services and providers
Because ZTNA usually puts a third-party service in a critical access path, the NCSC frames provider selection as a risk management and assurance decision, not just procurement. It notes that many vendors market broad platforms as delivering "zero trust", repeats that zero trust is an architectural approach rather than a single product, and asks you to focus on how a product supports your intended architecture. Its three areas:
| Area | Questions to answer |
|---|---|
| Understanding the trust relationship | Which functions does the provider perform (identity enforcement, policy decisions, traffic handling, logging, availability)? What happens if it fails, and what is the fallback? How much control do you keep over policy, logs and monitoring? |
| Gaining confidence in a product | Trial it with realistic scenarios before committing. Does it support your intended design rather than its marketing? How does it integrate with your identity provider, device management and monitoring? |
| Assurance over security and operation | Is the vendor's assurance proportionate to the risk? Which logs are available? How are incidents detected and handled? Which responsibilities sit with the vendor and which with you? |
We use the same structure to compare the platforms on ZTNA providers.
The eight design requirements
| NCSC design requirement | In practice | How to check your design |
|---|---|---|
| 1. Transport network traffic securely | Encrypt traffic between users, devices and applications with strong protocols such as TLS or IPsec, whatever network it crosses | Are any internal apps still reached over unencrypted protocols? |
| 2. Enforce policy before granting access | Authorise every request before a connection is made; being on the corporate network, on a VPN or in a known location is not enough | Can anyone reach an app without passing the policy engine? |
| 3. Use multiple signals to inform access decisions | Combine user identity, device identity, device health and behaviour; keep policies to a few standard categories | Does any policy rely on a single attribute such as group or IP range? |
| 4. Minimise exposure of applications | Private apps sit behind outbound-only connectors, proxies or narrowly scoped endpoints; SaaS exposure is managed through SSO and app-level policy | Do any private apps still have public addresses or inbound ports? |
| 5. Limit the impact of compromise | Assume compromise; segment by risk and criticality; ZTNA does not replace local firewalls and access control lists | If one laptop is compromised, what else could it reach? |
| 6. Continuously re-evaluate access as context changes | Re-check during sessions; short-lived tokens; restrict or revoke when conditions are no longer met | How quickly does access end after an EDR alert or account disablement? |
| 7. Ensure ZTNA architectures are observable | Log allowed and denied attempts with identity, application, time and policy; centralise in a SIEM; protect and monitor logs | Can you explain why a given user reached a given app last Tuesday? |
| 8. Design for resilience and availability | Phase and test policy changes, provide remediation paths, manage configuration as code, and keep a restricted, monitored, tested break-glass route | What happens if the provider or the identity provider is unavailable? |
The how to implement zero trust network access guide turns these into project phases.
The four ZTNA anti-patterns
The NCSC calls the anti-patterns section particularly important, because it sees many ZTNA deployments fail not for lack of technology features but because legacy trust assumptions are carried forward into new designs. It describes four:
| Anti-pattern | Why it matters | How to avoid it |
|---|---|---|
| Recreating the 'walled garden' trust model | If SSE or SASE is dropped in as a VPN replacement with the old access model, a compromised account or device still inherits broad internal access | Scope access per application to the minimum needed, backed by segmentation and policy, not just a new remote access tool |
| Trusting network location | An IP address, such as an office range or VPN address pool, says nothing about identity, authentication strength, device health or risk | Send every request to the policy engine whatever its source; use location only as a supporting signal |
| Exposing private applications to the internet | Flaws in the application, such as authentication bypass, can be exploited before any policy is enforced | Broker access through a hardened connector or proxy as the only exposed component; private apps need no public addresses |
| Maintaining legacy access routes that bypass the policy engine | Old VPNs or static firewall rules reintroduce implicit trust and make it hard to audit who can reach what | Remove legacy routes wherever possible; where one must stay, restrict it tightly and govern it centrally |
The fourth is easy to fall into during a migration: the new ZTNA platform goes live, but the old VPN is never switched off. The NCSC notes these routes are often kept for convenience, legacy systems or phased migration. Our guide to a VPN replacement project includes closing those routes as an explicit step, and ZTNA vs VPN covers when a tightly scoped VPN is still justified.
Reviewing your design against the guidance
If you already run ZTNA, SSE or a remote access VPN, we can review the design against the eight requirements and four anti-patterns and give you a written list of gaps, in priority order, with options for closing each. If you are about to choose a platform, we can use the NCSC's provider assessment questions to structure a fair comparison and a trial. We supply several platforms, so the review is not a sales pitch for one of them. Scope is confirmed at quote. Contact us to arrange a review.
How Forever Systems helps with ZTNA and SASE
We are an independent IT and cyber security provider. We supply and support several zero trust access and SASE platforms, so we can recommend what fits how your people work rather than one vendor's answer to everything.
- Assess first: we look at your current VPN, firewall, identity set-up and the applications people need to reach before suggesting anything new
- Vendor-aware advice across ZTNA, SSE and SASE options, including Cisco Secure Access and Check Point Harmony SASE
- Pilots and phased roll-out: we can help you start with one group of users or one application, then extend access policy by policy
- VPN replacement: planning the move away from remote access VPNs, including identity provider integration and device posture checks
- Ongoing support: policy changes, licence reviews and renewals, with the details confirmed at quote
We work with businesses, schools, charities and public sector organisations. Pricing depends on users, features and term, so ask us for a quote.
Frequently asked questions
When did the NCSC publish its ZTNA guidance?
The NCSC published its Zero Trust Network Access (ZTNA) guidance on 27 May 2026, with a blog post titled Designing secure access with ZTNA. It sits in the NCSC's Zero Trust collection and is available as web pages and a PDF.
What are the NCSC ZTNA anti-patterns?
Recreating the walled garden trust model; trusting network location, such as office IP ranges or VPN address pools; exposing private applications to the internet; and maintaining legacy access routes that bypass the policy engine.
What are the NCSC ZTNA design requirements?
Transport network traffic securely; enforce policy before granting access; use multiple signals to inform access decisions; minimise exposure of applications; limit the impact of compromise; continuously re-evaluate access as context changes; ensure ZTNA architectures are observable; and design for resilience and availability.
Is the NCSC ZTNA guidance a compliance standard?
No. The NCSC says it does not prescribe a single technical solution and is not intended to be used as a checklist or compliance framework. It is design guidance for architects and technical decision makers.
Does the NCSC recommend a ZTNA product?
No. The guidance names categories, such as VPN as a service, SSE and SASE platforms, but no vendors. It advises trials or proofs of concept with realistic scenarios before committing, and judging a product on how it supports your intended architecture rather than on 'zero trust' marketing.
Still have a question about a ZTNA design review?
Ask us and a member of our team will reply by email.