NCSC Zero Trust Architecture Design Principles Guide: Applying Each Principle to Real Designs

The UK NCSC's zero trust architecture design principles are short and readable, which is exactly why many teams quote them without turning them into design decisions anyone can test. The principles describe zero trust as an approach where inherent trust in the network is removed, the network is assumed hostile and each request is checked against an access policy. This guide works through each principle as it stands in the current NCSC collection (version 1.1, reviewed 16 January 2026), explains what changed from the original eight-principle version, and turns the text into design choices, evidence and metrics. It is written for architects, security engineers and assurance teams in UK public and private sector organisations. For the US reference model behind most vendor architectures, read the NIST SP 800-207 Zero Trust Architecture Guide first; this page does not repeat it.

Key takeaways

• Seven principles are published today. The NCSC collection now lists seven design principles; the original version 1.0 on the NCSC GitHub repository had an eighth, "Choose services designed for zero trust", whose advice still matters for procurement.
• Identity is cryptographic and covers services and devices. Principle 2 expects every user, service and device to be uniquely identifiable, with hardware-bound device keys (such as a TPM with key attestation) giving the highest confidence.
• The policy engine is a crown jewel. Principle 4 tells you to restrict what it talks to, accept signals only from mutually authenticated sources and control who can import policy.
• Monitoring moves to the device. Without a VPN choke point, principle 6 expects device-level monitoring exported over a secure transport such as mTLS, correlated with network data.
• Keep old controls until new ones are proven. The NCSC's own companion pages say to run new policy in log-only mode first, keep existing controls during transition and remove legacy routes that bypass the policy engine.

What the NCSC guidance is and how it has changed

The design principles sit inside the NCSC Zero Trust collection alongside an introduction, a "Demystifying Zero Trust" article and a Zero Trust Network Access (ZTNA) section. The collection is aimed at organisations implementing zero trust in an enterprise environment, public and private sector, and is meant to help readers design and review an architecture and choose the services that support it. It is guidance, not a standard, and there is no certification against it.

The website is the authoritative version: cite its principle pages in contracts and treat the GitHub repository as historical context.

The principles one by one

Each principle below is summarised from the NCSC page, followed by the design decision it forces. The decisions are NHI Mgmt Group's interpretation, not NCSC requirements.

1. Know your architecture, including users, devices, services and data

The NCSC asks for an asset discovery phase (automated network discovery or non-technical sources such as procurement records), knowledge of what data is held, where and how sensitive it is, and a risk assessment that includes threat modelling of the zero trust approach itself. It warns that existing services ignored during transition may be at higher risk because they were never designed for a hostile network, and that where zero trust cannot mitigate a risk you should keep existing controls.

• Design decision: produce a register of resources that records, for each one, its owner, data sensitivity, whether it can sit behind a PEP and which legacy controls currently protect it. See the Asset Inventory and CMDB Security Guide.
• Do not skip: data flows and user journeys, which the NCSC ZTNA "before building" page also asks for.

2. Know your user, service and device identities

Every user, service and device should be uniquely identifiable. For users the NCSC wants a definitive directory linked to individuals, least-privilege roles, strong modern authentication, federation with SAML 2.0, OAuth 2.0 or OpenID Connect, SCIM 2.0 for external services, joiners, movers and leavers processes, and federation for external parties. Services should not act on behalf of users without limit: each action should be tied to a scope-limited, time-limited token linked to the user. Each service needs its own identity with minimum privileges, and service-to-service communication should be restricted to an allow list based on service identity, for example with a unique certificate per service used for mutual TLS.

Device identity confidence is graded explicitly:

For the identity side in depth, see the Zero Trust Identity Guide.

3. Assess user behaviour, device and service health

Health signals feed the policy engine continuously. For devices the NCSC lists a secure configuration baseline enforced through device management, platform security state (secure boot, OS patching, virtualisation-based security, system integrity protection), attestation of firmware, boot process, endpoint security suite and kernel, and a remediation path so a user with a device that missed a patch can fix it rather than being blocked indefinitely. For services it covers native hardening, disabling legacy protocols without modern authentication, knowing version and patch level, watching for unexpected state changes (for example a container running as a privileged user) and verifying code provenance through a controlled delivery pipeline. The policy engine and PEPs are services too and are in scope. For users it asks for a behavioural baseline, connection health policies (unexpected region, unusual hours) and step-up authentication.

• Design decision: decide which signals are blocking and which are advisory. A compliance signal that never denies access satisfies the principle only on paper.
• Infrastructure: the NCSC also expects flow monitoring and infrastructure logs to find rogue devices, beaconing to malicious domains and unexpected processes.

4. Use policies to authorise requests

Every request is authorised against a policy: the user connects to a PEP, the PEP asks the policy engine, and the engine returns allow or deny, re-evaluated in real time so a posture change can end the session or force re-authentication. Example signals the NCSC lists are user role, physical location, authentication factors, device health, time of day, the value of the service and the risk of the action. High-impact actions such as creating an administrator need stricter policy than viewing a lunch menu.

Three parts of this principle are often missed:

• Protecting the engine: allow it to talk only to trusted PEPs and signal providers, accept signals only from known, mutually authenticated sources, validate input before parsing, and restrict who can import policy, with policies that can be audited and reviewed.
• Denial messages: return a general authentication error rather than detail such as "the account does not exist", which helps enumeration.
• Break glass: emergency access from an individual account, a specific device, a specified location, for a limited time and with minimum privilege, with every use alerted to a shared channel. See the Break-Glass Account Guide.

5. Authenticate and authorise everywhere

The NCSC treats MFA as a requirement for zero trust and presents passwordless authentication such as FIDO2 as the ideal option across all services, with extra factors prompted only for higher-impact requests (sensitive data, privileged actions, creating users) or when confidence drops. Service-to-service requests are authenticated with API tokens, OAuth 2.0 or PKI, and should be mutually authenticated so that each side can confirm the other and connections can be allow-listed by identity. See the Passwordless and Passkeys Guide and the mTLS Guide.

6. Focus your monitoring on users, devices and services

Monitoring shifts from the network perimeter to devices, users and services. The NCSC asks for monitoring on the device with data exported centrally over a secure transport such as mTLS, caution with logs from devices whose health is in doubt (a compromised device may tamper with them), endpoint security suites as a source, behavioural monitoring of users, visibility of which data services and users touch, and feedback from monitoring into policy decisions. BYOD and guest devices that cannot be fully monitored get reduced trust. The network is still monitored for performance, rogue devices and malicious activity, and network connections should be traceable to the process that created them. For collection design see the Log Management and Retention Guide.

7. Don't trust any network, including your own

No network between the device and the service is trusted, including the local network. Traffic uses a secure transport such as TLS; devices are configured to resist DNS spoofing, adversary-in-the-middle attacks and unsolicited inbound connections; foundational services such as DNS may best be protected by wrapping them in a secure transport. Where a service cannot use authenticated, encrypted protocols, existing protections such as a corporate VPN may still be needed. Because traffic may no longer be backhauled, web filtering moves to the device (malicious domain blocking, safe browsing) or to a managed cloud proxy assessed against the NCSC cloud security principles. See the Protective DNS Guide.

The former principle 8: choose services designed for zero trust

Version 1.0 advised preferring services with built-in zero trust support that can protect themselves when directly exposed, budgeting for extra components around legacy services, not building your own supporting infrastructure, and choosing standards-based technology (OpenID Connect, OAuth 2.0, SAML) for interoperability. Cloud-hosted zero trust services were to be trusted only after assessment against the cloud security principles. The current ZTNA "before building" page carries the same intent into provider assessment: trial with your own users and applications, judge fit against your design rather than marketing claims, and define shared responsibility for configuration, policy and incident response.

How the NCSC principles compare with NIST SP 800-207

The two agree on the core model; the differences are in emphasis.

A practical approach is to use the NCSC principles as the design checklist and SP 800-207 vocabulary for component diagrams. For maturity scoring, the CISA Zero Trust Maturity Model Guide adds stages per pillar that the NCSC does not define.

Where non-human identities fit

Principle 2 is one of the clearest government statements that services are first-class identities: unique, least-privileged, allow-listed by identity and mutually authenticated. In practice this is where most programmes fall short, because service accounts, API keys and CI/CD tokens keep long-lived static secrets that a policy engine cannot meaningfully re-evaluate.

• Inventory: include service accounts, workloads, API clients and AI agents in the principle 1 register, each with an owner.
• Credentials: move from shared secrets to per-service certificates or federated, short-lived tokens. See the Workload Identity Federation Guide.
• Delegated access: the NCSC's scope-limited, time-limited token tied to the user is the pattern for services and agents acting on someone's behalf. See the Zero Trust for AI Agents Guide.
• Policy plane identities: accounts and pipelines that can import policy into the engine are tier-zero, as principle 4's import restrictions imply.

Implementation roadmap

The NCSC's demystifying article frames zero trust as a multi-year programme driven by your own threat scenarios. The phases below combine its advice with the principles and ZTNA pages.

1. Define the threat scenarios: write down the three to five attacks you want to stop (stolen credentials, compromised device, lateral movement from a supplier connection) and check whether narrower targeted controls would deliver similar benefit, as the NCSC suggests.
2. Discover and register (principle 1): users, devices, services, data and flows, including non-human identities and legacy services that cannot sit behind a PEP.
3. Fix identity prerequisites (principle 2): one authoritative identity provider, single sign-on, phishing-resistant authentication, governed joiners, movers and leavers, and hardware-backed device identity on managed devices.
4. Stand up signals (principle 3): device compliance from management tooling, EDR telemetry, service patch levels and a remediation path for users.
5. Write policy for one high-value flow (principle 4): pick a flow such as administrator access or finance approvals, define allow conditions, then run in log-only mode for a short period while auditing the would-deny events.
6. Enforce for a pilot ring: keep traditional controls blocking in parallel during the transition, as the NCSC suggests, and keep the legacy route as a logged rollback.
7. Extend to services (principle 5): mutual authentication and identity-based allow lists for service-to-service traffic, starting with the services behind the pilot flow.
8. Move monitoring and filtering to devices (principles 6 and 7): device telemetry over mTLS, on-device web protection or a managed proxy, and continued local network hygiene.
9. Retire bypass routes: remove broad VPN access, direct routes and static firewall rules once there has been a sustained period with no fallback use, and only after listing every control the VPN provided and confirming its replacement.

Rollback: every enforcement change should have a documented switch back to log-only mode, and break-glass access must be tested before enforcement, not after the first lockout.

Small and large organisations: a small, cloud-first organisation can meet most principles with its identity provider's conditional access as the policy engine, device management for health signals and SaaS-native controls, which also suits the former principle 8's advice not to build your own infrastructure. A large estate will run several PEP types and must keep their policy consistent.

ZTNA anti-patterns to design out

The NCSC's ZTNA anti-patterns page names four ways a zero trust programme reproduces the old model. Use them as review questions.

The ZTNA pages also advise against making TLS inspection or tunnelling of all internet traffic a default: inspection components concentrate trust, and tunnelling TLS traffic adds limited value. Decide on both from the threat model and document the trade-off. See the TLS Inspection Guide.

Detection and measurement

Evidence that the principles are working comes from decisions and coverage, not diagrams. Log every policy engine decision with subject, device, resource, signals and policy version; alert on break-glass use, on policy imports and on any access that arrives through a route that bypasses the engine. Correlate device telemetry with network flows so that a connection can be traced to its process.

Framework mapping

For UK regulated operators the same evidence supports the identity, access and monitoring objectives of the NCSC Cyber Assessment Framework (CAF) Guide, and the NCSC's own pages lean on the cloud security principles for provider assurance (see the NCSC 10 Steps and 14 Cloud Security Principles).

Common failure patterns

• Quoting eight principles from an old slide: designs and tenders cite the GitHub version 1.0 list. Reference the current website pages and record the version and review date.
• Users only: human sign-in goes through the policy engine while services keep shared secrets and flat network paths, contrary to principle 2's service identity and allow-list advice.
• Health signals that never deny: device compliance is collected but set to report only, and there is no remediation path, so the team is afraid to enforce.
• Unprotected policy engine: any administrator or pipeline can import policy without review, and signals are accepted from unauthenticated sources.
• Trusted IP exclusions: office or VPN ranges exempt from conditional access, the second NCSC anti-pattern. See How to Find Accounts Excluded From MFA and Conditional Access.
• Removing the VPN first: the VPN is switched off before every control it provided has a replacement, which the demystifying article warns against.

Practitioner checklist

• Cite the current NCSC principle pages with version and review date, and note the former principle 8 separately if you use it for procurement.
• Build a resource register with owner, data sensitivity, PEP status and current legacy controls.
• Give every user, service and device a unique identity; grade device identity by the NCSC confidence levels and require hardware-bound keys for privileged access.
• Replace shared service secrets with per-service certificates or federated short-lived tokens and allow-list service traffic by identity.
• Decide which health signals block access, and provide a user remediation path before enforcing.
• Restrict policy engine communication to trusted PEPs and signal sources, and put policy imports under change control with audit.
• Run each new policy in log-only mode, review would-deny events, then enforce for a pilot ring with a documented rollback.
• Configure break-glass access with device, location, time and privilege limits and shared-channel alerting, and test it.
• Review the design against the four NCSC ZTNA anti-patterns and retire bypass routes on a dated plan.

Standards and references

• NCSC: Zero trust architecture design principles
• NCSC: Know your user, service and device identities
• NCSC: Use policies to authorise requests
• NCSC: Introduction to zero trust
• NCSC: Demystifying Zero Trust
• NCSC: ZTNA anti-patterns
• NCSC: What to do before building a ZTNA architecture
• NCSC on GitHub: Zero trust architecture design principles (version 1.0)

Related NHI Mgmt Group resources: NIST SP 800-207 Zero Trust Architecture Guide · Zero Trust Identity Guide · CISA Zero Trust Maturity Model Guide · Top 10 Zero Trust Mistakes · Securing the ZTNA broker and remote access VPN itself