# Zero Trust

Zero Trust is a security model that verifies every user, device and request regardless of network location, with least-privilege access. Learn its principles.

## Overview

Zero Trust is a security model built on one rule: never grant trust just because a request comes from inside the network. Every user, device and workload must prove who it is, show that it is in an acceptable state, and receive only the access it needs, for each resource, every time it asks. The traditional model drew a hard perimeter around the corporate network and trusted most things inside it. Zero Trust treats the network as hostile everywhere and moves protection close to each resource.

An everyday analogy is the difference between a medieval castle and a modern hospital. The castle has a moat and a gate; once you are inside the walls, you can wander almost anywhere. A hospital has card readers on wards, pharmacies and operating theatres. A nurse's badge opens the wards she works on during her shift, not the drug store or the records office, and the badge is cancelled the day she leaves. Being inside the building is not enough. Zero Trust brings that hospital logic to computer systems.

The model matters because work is no longer inside one network. People work from home, applications run in several clouds, partners connect from outside, and attackers who steal one password or compromise one laptop should not be able to roam. For AI systems the same logic applies to agents and tools: an agent calling internal APIs should have its own identity, narrowly scoped permissions and every call logged, rather than broad network access.

## What it is

Zero Trust is a set of principles and an architecture, not a single product.

| Principle or component | What it means |
|---|---|
| Verify explicitly | Authenticate and authorise every request using identity, device and context |
| Least privilege | Grant only the access needed, for the shortest time needed |
| Assume breach | Design so that one compromised account or host causes limited damage; monitor continuously |
| Policy engine | Decides whether to grant access based on policy and signals |
| Policy administrator | Establishes or tears down the session based on the decision |
| Policy enforcement point | Sits in front of the resource and allows or blocks traffic, such as a proxy or gateway |
| Signals | Inputs like user identity, MFA strength, device health, location, time and behaviour |
| Microsegmentation | Dividing networks and workloads into small zones with explicit rules between them |

The policy engine, administrator and enforcement point come from the reference architecture in NIST Special Publication 800-207. The same thinking applies across pillars that guidance commonly lists: identity, devices, networks, applications and workloads, and data, supported by visibility, automation and governance.

## Where it came from

Concerns about perimeter security grew in the 2000s; the Jericho Forum promoted "de-perimeterisation" from 2004. The term "Zero Trust" was popularised by John Kindervag, then an analyst at Forrester Research, in 2010, who argued that networks should not trust internal traffic by default.

Google described its internal implementation, BeyondCorp, in a 2014 paper: employees reach internal applications from any network through an access proxy that checks user and device, without a traditional VPN. In August 2020 the US National Institute of Standards and Technology published SP 800-207, "Zero Trust Architecture", which became a widely used reference. A US executive order in May 2021 (EO 14028) and the Office of Management and Budget memorandum M-22-09 in January 2022 directed federal agencies towards Zero Trust, and the Cybersecurity and Infrastructure Security Agency (CISA) published version 2.0 of its Zero Trust Maturity Model in April 2023. Many vendors now market Zero Trust products, which makes it important to focus on principles rather than labels.

## How it works

### 1. Know your resources and flows

Inventory applications, data, services and who needs access to what. You cannot protect what you do not know exists.

### 2. Establish strong identity

Centralise users in an identity provider with [OIDC](/tools/oidc) or SAML single sign-on and require multi-factor authentication, preferably phishing-resistant methods such as passkeys or hardware keys. Give every workload an identity too, for example through [mTLS](/tools/mtls) certificates or signed tokens.

### 3. Check devices

Assess device posture: managed or not, disk encryption on, operating system patched, endpoint protection running. Feed this into access decisions.

### 4. Put enforcement in front of each resource

Use identity-aware proxies, API gateways and service meshes so every request passes a policy enforcement point. Remove broad network-level access such as flat VPNs.

### 5. Decide per request

The policy engine evaluates who, what device, which resource, what action and what context. A finance analyst on a managed laptop may read the reporting dashboard; the same analyst on an unknown device may get read-only access or be asked to re-authenticate.

### 6. Limit and segment

Grant least-privilege, short-lived access. Segment networks and workloads so services can talk only to those they need, as in [microservices](/tools/microservices) with explicit service-to-service policies.

### 7. Monitor and adapt

Log every decision and access. Analyse for anomalies and feed risk signals back into policy, for example revoking sessions when a device falls out of compliance.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Perimeter security | Trusting traffic inside a network boundary. |
| Implicit trust | Access granted because of location rather than verification. |
| Least privilege | Minimum access necessary for a task. |
| Microsegmentation | Fine-grained network or workload isolation. |
| Policy decision point | The component that evaluates access requests. |
| Policy enforcement point | The component that enforces the decision at the resource. |
| Device posture | The security state of a device. |
| ZTNA | Zero Trust Network Access, application-level access replacing broad VPNs. |
| Just-in-time access | Privileges granted only when needed and removed afterwards. |
| Continuous verification | Re-evaluating trust during a session, not only at login. |
| Lateral movement | An attacker moving from one compromised system to others. |

## A worked example

This scenario is illustrative. A company of 600 people uses a VPN. Once connected, any employee can reach about 400 internal hosts, including databases, a model training cluster and an admin console. A phishing attack steals one engineer's password; the attacker connects to the VPN and starts scanning.

The company adopts Zero Trust in phases over 12 months. Phase one: all staff move to single sign-on with phishing-resistant MFA, and the VPN requires managed devices. Phase two: the 30 most-used internal web applications move behind an identity-aware proxy; each has an access policy by group, and device posture is checked on every session. Phase three: in the Kubernetes clusters, a service mesh enforces mTLS and policies so that, for example, only the feature service can reach the feature database. Phase four: administrative access to production uses just-in-time elevation lasting at most 2 hours, approved and logged.

A year later a similar phishing attempt succeeds in capturing a password, but the attacker cannot pass the hardware-key MFA. In a separate incident, malware on one laptop is detected; its posture fails, and access to all protected applications is cut within minutes. The VPN is reduced to a few legacy systems scheduled for migration.

## Strengths and limitations

**Strengths:**

- Limits damage from stolen credentials and compromised devices.
- Supports remote work and multi-cloud without a hard perimeter.
- Access decisions are explicit, consistent and auditable.
- Reduces lateral movement through segmentation and least privilege.
- Aligns with modern regulatory and government guidance.

**Limitations:**

- A long programme, not a quick project; legacy systems are hard to fit.
- Requires mature identity, device management and asset inventory.
- Poorly tuned policies frustrate users and generate workarounds.
- Vendor marketing blurs what is genuinely Zero Trust.
- More components, such as proxies and policy engines, need high availability.

## How it compares with alternatives

| Model | Approach | When it fits or falls short |
|---|---|---|
| Perimeter (castle and moat) | Firewall at the edge, trust inside | Simple, but weak once anything inside is compromised |
| VPN-based remote access | Network-level tunnel into the internal network | Easy to deploy; grants broad network reach |
| Defence in depth | Multiple layers of controls | Complementary; Zero Trust is one way to organise layers |
| SASE | Cloud-delivered networking and security services | A delivery model that often includes ZTNA |
| Network segmentation only | VLANs and firewalls between zones | Helpful but coarse without identity-based decisions |

## Practical guidance and best practices

1. Start with identity: single sign-on and phishing-resistant MFA for everyone, including administrators.
2. Inventory resources and data flows, and classify what matters most.
3. Protect high-value applications first behind identity-aware access, then expand.
4. Use device posture in access decisions for sensitive resources.
5. Give workloads and AI agents their own identities with narrowly scoped, short-lived credentials, for example via [OAuth 2.0](/tools/oauth-2-0).
6. Apply microsegmentation and default-deny policies between services.
7. Replace standing admin rights with just-in-time, approved elevation.
8. Log all access decisions centrally and alert on anomalies.
9. Measure progress against a maturity model, such as CISA's, rather than product checklists.

## Common mistakes

- Buying a "Zero Trust" product and assuming the job is done.
- Strong login but broad access afterwards, leaving lateral movement open.
- Exempting administrators, service accounts or legacy systems indefinitely.
- Ignoring machine identities while focusing only on users.
- Rolling out strict policies without visibility first, breaking critical workflows.
- Treating Zero Trust as a network project only, without data and application controls.

## Frequently asked questions

### Does Zero Trust mean trusting nobody?

It means no implicit trust. Users and systems are trusted for specific actions after verification, and that trust is limited and re-evaluated.

### Do I still need firewalls?

Yes. Firewalls and segmentation remain useful layers. Zero Trust changes their role: the perimeter is no longer the main reason for granting access.

### Is a VPN compatible with Zero Trust?

A VPN that gives broad network access conflicts with Zero Trust principles. Application-level access through identity-aware proxies, often called ZTNA, is the usual replacement, though VPNs may remain for some legacy needs.

### What is NIST SP 800-207?

A NIST publication from August 2020 that defines Zero Trust concepts and a reference architecture with policy decision and enforcement components. It is widely used as a neutral reference.

### How does Zero Trust apply to AI agents?

Agents should have their own identities, receive narrowly scoped and short-lived tokens for each tool, have every action logged, and be denied access by default. See [sandboxing](/tools/sandboxing) and [guardrails](/tools/guardrails).

### How long does adoption take?

Typically years for a full programme, delivered in phases. Early phases, such as MFA and protecting key applications, bring large benefits quickly.

## Glossary

- Zero Trust: a security model without implicit trust based on location.
- ZTA: Zero Trust Architecture.
- ZTNA: Zero Trust Network Access.
- MFA: multi-factor authentication.
- Phishing-resistant MFA: methods such as FIDO2 security keys and passkeys.
- Microsegmentation: fine-grained isolation of workloads.
- Identity-aware proxy: a gateway that authorises requests by identity and context.
- Device posture: a device's security state.
- Just-in-time access: temporary privilege granted on demand.
- Lateral movement: spreading from one compromised system to others.

## Summary

Zero Trust replaces trust based on network location with explicit verification of every user, device and workload for each request, least-privilege access and an assumption that breaches will happen. Popularised by John Kindervag in 2010, demonstrated by Google's BeyondCorp and codified in NIST SP 800-207 in 2020, it now guides government and industry security programmes. It is a gradual journey: start with strong identity and MFA, protect critical applications with identity-aware access, give workloads and AI agents their own scoped identities, segment services, remove standing privileges and monitor every decision.