In short
Zero trust architecture (ZTA) is the plan that applies zero trust principles to how access works. A policy engine decides each request from identity, device and threat signals, a policy administrator sets up or ends the session, and a policy enforcement point sits in front of the resource. In most businesses ZTNA provides the enforcement layer.
Get a quote for zero trust architecture
Tell us roughly how many users or sites you have and we will come back to you with options and a quote.
What is zero trust architecture?
NIST SP 800-207 (opens in a new tab) defines zero trust architecture as an enterprise's cybersecurity plan that uses zero trust concepts and covers component relationships, workflow planning and access policies. The NCSC's Demystifying Zero Trust (opens in a new tab) puts it more simply: zero trust is the "why", the guiding security philosophy, and zero trust architecture is the "how", the practical design of systems and controls that delivers it.
Two things follow. First, a zero trust security architecture is specific to your organisation: your applications, users, devices and risks. Second, it is built up over time. NIST expects most organisations to run a hybrid of zero trust and perimeter-based design for a long while, and the NCSC says full migration may take several years.
The logical components (NIST SP 800-207)
NIST section 3 breaks a zero trust architecture into a small set of logical components. They are logical, not products: one product can do several jobs, and one job can be spread over several products.
| Component | Job | Where you find it in practice |
|---|---|---|
| Policy engine (PE) | Makes and logs the decision to grant, deny or revoke access, using policy and inputs from other systems | The decision service in a ZTNA platform or identity provider's conditional access |
| Policy administrator (PA) | Sets up or shuts down the communication path, including session tokens, by instructing the enforcement points | The ZTNA control plane that tells clients and connectors what is allowed |
| Policy decision point (PDP) | The PE and PA together; many products combine them into one service | The ZTNA cloud service |
| Policy enforcement point (PEP) | Enables, monitors and ends the connection between user and resource; may be split into a client agent and a resource-side gateway, or be a single portal | ZTNA client on the laptop plus connector in front of the app, or a clientless browser portal |
| Data sources | Feed the policy engine: device state (continuous diagnostics), compliance rules, threat intelligence, activity logs, data access policies, certificates (PKI), identity management and the SIEM | Device management and endpoint protection, identity provider, threat feeds, logging platform |
The NCSC uses the same vocabulary in its Introduction to Zero Trust (opens in a new tab): a policy engine takes signals and compares them with access policies, and a policy enforcement point mediates requests using the policy engine's decision. A zero trust policy, in this language, is simply the set of rules the policy engine applies.
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.
Zero trust architecture diagram: what happens on each request
This flow is the zero trust architecture diagram in words, following NIST's device agent and gateway model. Read it top to bottom; each step names the component doing the work.
| Step | What happens | Component |
|---|---|---|
| 1 | A user on a laptop opens an internal application | Subject and device; client-side PEP (agent) |
| 2 | The agent sends the request to the decision service instead of straight to the application | Policy administrator |
| 3 | The decision service checks identity and MFA, device health, the user's role and any threat signals against policy | Policy engine, fed by data sources |
| 4 | If allowed, it tells the agent and the gateway in front of the application to open a session for this user and this application only | Policy administrator to both PEP halves |
| 5 | The agent and gateway connect over an encrypted channel; the application only ever talks to the gateway | Resource-side PEP (gateway or connector) |
| 6 | The session ends when the work is done or when policy changes, for example a failed re-authentication or a device going out of compliance | Policy engine and administrator |
Two planes run through this. NIST separates the control plane, where the decision and set-up traffic flows, from the data plane, where the application traffic flows. In a ZTNA product the control plane is the vendor's cloud service; the data plane is the tunnel between the client and the connector. For the request flow inside ZTNA products specifically, see how ZTNA works.
Deployment models mapped to ZTNA
NIST section 3.2 describes several ways to deploy the components. Each maps neatly onto a type of product you can buy today:
| NIST deployment model | How it works | Product equivalent | Best fit |
|---|---|---|---|
| Device agent / gateway | An agent on each managed device and a gateway in front of each resource | Client-based ZTNA: an agent on the laptop and an outbound connector beside the application | Managed laptops; any application or protocol |
| Enclave gateway | The gateway sits at the edge of a group of resources, such as a data centre or private cloud | A ZTNA connector per site or network segment rather than per application | Legacy applications that cannot have their own gateway |
| Resource portal | A single gateway portal with no agent on the device | Clientless or agentless ZTNA through the browser | Contractors, BYOD, web applications |
| Application sandboxing | Approved applications run in a compartment on the device; only they may reach the PEP | An enterprise browser that contains private applications, such as Island Private Access | Unmanaged devices that need more control than a portal |
NIST also describes three approaches to building the architecture: enhanced identity governance (identity drives policy, common for SaaS), micro-segmentation (gateways or host firewalls protect small groups of resources) and network infrastructure and software defined perimeters (an overlay network controlled by the policy administrator). NIST says a full zero trust solution will include elements of all three; our page on zero trust networking covers the segmentation side.
Is zero trust architecture the right fit for you?
We will check it against your systems and requirements and recommend the right option.
NCSC reference architectures and anti-patterns
The NCSC's ZTNA reference architectures (opens in a new tab) (May 2026) give two deliberately simplified designs. For a private application, a managed device connects through a tunnel to a network policy engine; connectors at the edge of each segment make outbound connections so nothing listens on the internet; a separate application policy engine at single sign-on then decides whether this user may use this application; segments are separated by business criticality and every component's logs are collected centrally. For SaaS, the application redirects to single sign-on, the application policy engine evaluates the request and issues a short-lived token, and signals are re-checked before the session is extended. Both designs include a tightly governed break-glass route for emergencies.
The NCSC's ZTNA anti-patterns (opens in a new tab) list four design mistakes to avoid: recreating the "walled garden" (a new product, but users still get broad network access once connected), trusting network location, exposing private applications to the internet, and keeping legacy access routes that bypass the policy engine. Our summary of the NCSC ZTNA guidance covers both in more detail.
ZTA vs ZTNA: where ZTNA fits
Zero trust network architecture and ZTNA are related but not the same. ZTA is the whole design: identity, devices, networks, applications, data and monitoring. ZTNA is the access layer within it: the product that plays the policy decision point and enforcement point roles for user-to-application access. A business can deploy ZTNA without the rest of a zero trust architecture, but the NCSC's anti-patterns show what happens then: the old trust model survives inside a new product.
For the components of ZTNA products themselves, and the ZTNA architecture of clients, connectors and brokers, see how ZTNA works. Some vendors package ZTNA inside a wider SASE (opens in a new tab) platform with web security and SD-WAN.
Building blocks we supply
These are the main building blocks we supply for each part of the architecture. Facts come from each vendor's own site, read on 9 November 2026.
| Architecture role | Product | What the vendor says it does |
|---|---|---|
| Policy decision and enforcement for private apps | Cisco Secure Access | ZTNA using least-privilege principles and client or clientless methods to deny access by default; VPN as a Service for apps that cannot use ZTNA; ZTNA enforcement in the cloud or on premises (Cisco (opens in a new tab)) |
| Policy decision and enforcement for private apps | Check Point SASE Private Access | Granular zero trust Private Access with an identity-centric access policy for employees, third parties and branch offices (Check Point (opens in a new tab)) |
| Identity and device signals | Cisco Duo (opens in a new tab) | MFA, including phishing-resistant MFA, and Device Trust: device visibility, device health and continuous verification (Duo (opens in a new tab)) |
| Segmentation and admin access | Zero Networks | Automated microsegmentation from observed traffic, identity segmentation and just-in-time MFA on admin protocols (Zero Networks (opens in a new tab)) |
Forever Systems, a Cisco Partner and Check Point Advanced Partner, can quote for and set up these products; other options are on ZTNA providers. Contact us for free advice on a design that fits your applications.
How Forever Systems helps with ZTNA
Forever Systems supplies and supports several zero trust network access platforms, so we can recommend what fits how your people work and the tools you already run.
- 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 the ZTNA products we supply, including Cisco Secure Access (opens in a new tab) and Check Point Private Access
- 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 components of a zero trust architecture?
NIST SP 800-207 names a policy engine (makes the access decision), a policy administrator (sets up or ends the session) and a policy enforcement point (sits between the user and the resource), supported by data sources such as device management, identity, threat intelligence, logs and certificates.
What is a policy enforcement point in zero trust?
It is the component that enables, monitors and ends the connection between a user and a resource, following the policy engine's decision. In ZTNA products it is usually split between a client on the device and a connector or gateway in front of the application, or it is a browser portal.
What is a zero trust policy engine?
The policy engine takes signals such as user identity, MFA strength, device health and threat data, compares them with your access policies and decides whether to allow, deny or revoke each request. In most ZTNA products it is part of the vendor's cloud service.
Is ZTA the same as ZTNA?
No. ZTA (zero trust architecture) is the whole design across identity, devices, networks, applications and data. ZTNA is one part of it: the access layer that controls how users reach applications. Some vendors use ZTA to mean zero trust access, but NIST uses it for the architecture.
Is there a standard zero trust reference architecture?
NIST SP 800-207 gives the abstract model and deployment variations, and the NCSC publishes ZTNA reference architectures for private applications and SaaS. Both are illustrative, not prescriptive: you adapt them to your own environment and risk.
Still have a question about zero trust architecture?
Ask us and a member of our team will get back to you.