In short
The NCSC zero trust principles guide the design of a zero trust architecture: know your architecture; know your user, service and device identities; assess behaviour and health; use policies to authorise requests; authenticate and authorise everywhere; focus monitoring on users, devices and services; and don't trust any network. The NCSC stresses that zero trust is an approach, not a product.
Not sure where to start?
Tell us what you need to achieve and we will point you to the right option.
What the NCSC zero trust collection contains
The NCSC's Zero Trust collection is a set of guidance pages rather than a single document. As at November 2026 it contains:
| NCSC page | What it covers |
|---|---|
| Introduction to Zero Trust | What zero trust is: an approach to system design where inherent trust in the network is removed |
| Demystifying Zero Trust | Plain-language answers to common misconceptions, including that zero trust is not a product you can buy off the shelf |
| Zero trust architecture design principles | The principles for designing and building a zero trust architecture, one page per principle |
| Zero Trust Network Access (ZTNA) | Guidance published on 27 May 2026 on designing ZTNA: signals, policy engines, prerequisites, design requirements, reference architectures and anti-patterns |
| Help implementing zero trust architecture | Links to NCSC blog posts on migration: where to start, how to know whether you can remove your VPN, and building a mixed estate |
The ZTNA guidance is the newest and most practical part for anyone replacing a VPN. We summarise it separately on NCSC ZTNA guidance.
Not sure which option fits? Ask us
Tell us what you need and we will help you choose the right option.
The NCSC zero trust architecture design principles
These are the principle pages as the NCSC currently names them in the collection. For each we give our reading of what it means in practice and the kinds of product capability that support it. No product delivers a principle on its own; each needs design and process around it.
| NCSC principle | What it means in practice | Capabilities that support it |
|---|---|---|
| 1. Know your architecture including users, devices, services and data | Inventory who your users are, what devices they use, which services and applications exist and where the important data lives, before designing controls | Asset and SaaS discovery, application inventories, data flow mapping |
| 2. Know your user, service and device identities | Every user, device and service has a unique, verifiable identity, held in an authoritative source | Identity provider with MFA and SSO, device certificates, managed identities for services |
| 3. Assess user behaviour, service and device health | Measure whether devices are configured securely and whether behaviour looks normal, so access can reflect risk | MDM compliance, EDR risk scores, identity risk detection |
| 4. Use policies to authorise requests | A policy engine decides each request using several signals, rather than network location | Conditional access, ZTNA and SSE policy engines |
| 5. Authenticate and authorise everywhere | Internal services authenticate and authorise each connection too, not only the internet edge | SSO to internal apps, per-app ZTNA, service-to-service authentication |
| 6. Focus your monitoring on users, devices and services | Monitor identities, endpoints and service behaviour, since the network perimeter no longer tells you much | SIEM, EDR or XDR, ZTNA and identity logs |
| 7. Don't trust any network, including your own | Treat the office LAN, Wi-Fi and VPN like the internet: encrypt and authenticate everything | TLS everywhere, ZTNA for on-site users as well as remote, segmentation |
One detail to be aware of: the introduction on the NCSC's principles page still describes "eight principles", but the overview and the collection's navigation list and link the seven above. Check the NCSC principles page for the current wording before quoting it in a policy document.
Zero trust is an approach, not a product
The NCSC is consistent on this point across the collection. Demystifying Zero Trust says to think of it as an architectural approach, not a product you can buy off the shelf. The ZTNA guidance notes that many vendors market broad platforms as delivering "zero trust", and says that purchasing a product alone won't deliver zero trust outcomes without appropriate architectural design and integration.
What that means when you are buying:
- A product can support the principles, for example by providing a policy engine, device posture checks or connectors that hide applications. It cannot know your architecture or decide your policies for you.
- Migration takes time. The NCSC notes that full migration may involve rearchitecting systems over several years, and that existing controls should stay in place until their replacements are mature.
- Zero trust and a VPN can coexist. The NCSC says they are not mutually exclusive and that replacing the VPN should not be the goal in itself; remove it only once the controls it provides have been replaced, and do not inherently trust traffic arriving through it. Our ZTNA vs VPN comparison covers when each fits.
- It is an ongoing process. The roadmap should keep evolving as systems and threats change.
This is why our product pages describe what each platform does, not that it "delivers zero trust".
Need help choosing?
We will recommend what fits your organisation and explain why, in plain English.
Applying the principles in a UK organisation
For most small and mid-sized organisations, a practical order of work looks like this:
- Map what you have (principle 1): users, devices, applications, where data sits and how people reach it today, including the VPN and any remote desktop routes.
- Fix identity (principle 2): one identity provider, MFA for every account, phishing-resistant methods for administrators, and a reliable leaver process.
- Manage devices (principle 3): enrol devices in MDM, set a compliance baseline and add EDR so device health can be a signal.
- Write access policy (principle 4): decide who needs which applications and on what conditions, starting with the most sensitive.
- Move applications behind per-app access (principles 5 and 7): ZTNA for private apps, SSO and conditional access for SaaS, and treat the office network as untrusted.
- Monitor (principle 6): send identity, endpoint and access logs to one place and review them.
Each step maps to concrete work in our guide on how to implement zero trust network access. Where Cyber Essentials is also a goal, the identity and device work overlaps heavily; see Cyber Essentials on our sister site.
Where the NCSC ZTNA guidance fits
The design principles are deliberately general. The ZTNA guidance published in May 2026 applies them to one problem, controlling how users and devices access applications over a network, and adds specifics: four signal types, two kinds of policy engine, prerequisites, how to assess providers, eight design requirements and four anti-patterns to avoid. If your immediate project is replacing a VPN or choosing a ZTNA platform, read our summary of the NCSC ZTNA guidance next, then replace your VPN for the project view.
How we help
We can review your current architecture against the NCSC principles and produce a short, prioritised plan: what you already meet, where the gaps are and which products, if any, would help close them. Because we supply several ZTNA and SASE platforms, the plan is not tied to one vendor. Scope and timescales are confirmed at quote. Contact us to arrange a review.
Explore NCSC zero trust
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
What are the NCSC zero trust principles?
The NCSC's zero trust architecture design principles currently cover: know your architecture including users, devices, services and data; know your user, service and device identities; assess user behaviour, service and device health; use policies to authorise requests; authenticate and authorise everywhere; focus your monitoring on users, devices and services; and don't trust any network, including your own.
Does the NCSC recommend zero trust for every organisation?
Not automatically. In Demystifying Zero Trust the NCSC suggests defining the threats you want to address, assessing existing capabilities and considering whether a zero trust approach is warranted or whether targeted controls could deliver similar benefits. It also notes that full migration may take several years and that existing controls should stay in place until replacements are mature.
Is there NCSC guidance on ZTNA?
Yes. The NCSC published Zero Trust Network Access (ZTNA) guidance on 27 May 2026 as part of its Zero Trust collection. It covers signals and policy engines, prerequisites, provider assessment, eight design requirements, reference architectures and four anti-patterns.
Can a product make us zero trust compliant?
No. The NCSC says zero trust is an architectural approach rather than a single product, and that purchasing a product alone won't deliver zero trust outcomes without appropriate architectural design and integration. Products support the principles; design, identity, device management and policy make them work.
What is 'Demystifying Zero Trust'?
It is a page in the NCSC's Zero Trust collection that addresses common misconceptions: zero trust is not a quick fix or a product, it means more security controls rather than fewer, it does not mean no trust, it is not mutually exclusive with a VPN, and you never 'complete' it.
Still have a question about a zero trust architecture review?
Ask us and a member of our team will reply by email.