Zero trust replaces "inside the network means trusted" with a decision for every request, based on who or what is asking, from where, and for what. That makes identity the control plane: every user, device, workload and AI agent needs a verifiable identity, and every access decision needs policy that can see it. Zero trust is not a product. It is an architecture described in NIST SP 800-207 and a maturity journey described in the CISA Zero Trust Maturity Model. This guide explains the principles, the identity capabilities zero trust depends on, how to apply it to people, devices and workloads, and how to build a roadmap that delivers risk reduction early.
Key takeaways
- Zero trust means no implicit trust from network location. Every access is authenticated, authorised and evaluated against policy.
- Identity is the foundation: strong authentication, device trust, least privilege and continuous evaluation for every identity type.
- Apply it to workloads and machines, not just people. Most east-west traffic is service to service.
- Deliver in phases, starting with the highest-value assets and most-attacked access paths, such as admin access and remote access.
- Measure progress against a maturity model rather than declaring a project finished.
Principles
NIST SP 800-207 sets out the core tenets. In practical terms:
- All resources are protected individually, whether they are applications, data, APIs or infrastructure.
- Location grants nothing. A request from the corporate network is treated like one from the internet.
- Access is granted per session and per resource, with the least privilege needed.
- Decisions are dynamic, using identity, device posture, behaviour and resource sensitivity.
- Everything is monitored, and the security posture of assets is continuously measured.
- Assume breach: design so that one compromised identity or device reaches as little as possible.
The architecture
NIST SP 800-207 describes a policy decision point (PDP), made up of a policy engine and policy administrator, and a policy enforcement point (PEP) that sits in front of resources. The PDP draws on signals such as identity, device health, threat intelligence and activity logs. In real deployments, the PEP might be an identity-aware proxy, a zero trust network access (ZTNA) gateway, an API gateway, a service mesh sidecar or the application itself. The Authorisation Models Guide covers policy engines in more depth.
The identity capabilities zero trust depends on
| Capability | What good looks like | Related guide |
|---|---|---|
| Identity inventory | Every person, device, workload and agent known, owned and classified | NHI Ownership Guide |
| Strong authentication | Phishing-resistant MFA for people; attested, short-lived credentials for workloads | MFA Guide |
| Device trust | Access decisions consider device management, health and ownership | Device and IoT Identity Guide |
| Least privilege | Fine-grained, just-in-time access with no standing admin rights | JIT Access Guide |
| Centralised policy | Consistent policy evaluated by a PDP rather than scattered per application | Authorisation Models Guide |
| Session control | Short, bound sessions that are re-evaluated and revoked when risk changes | Token and Session Security Guide |
| Visibility and detection | Identity activity monitored for misuse and attack paths | ITDR Guide |
Zero trust for people
- Put applications behind the identity provider and enforce conditional access based on user, device, location and risk. See the Identity Provider and SSO Security Guide.
- Replace network-level VPN access with per-application access where you can. See the Remote Access Identity Guide.
- Use continuous access evaluation, so that events such as account disablement, password change or risk elevation end existing sessions, rather than waiting for tokens to expire. The OpenID Shared Signals Framework and CAEP standardise how such events are exchanged.
- Apply the strictest controls to administrators: dedicated admin identities, phishing-resistant MFA, privileged access workstations and just-in-time elevation.
Zero trust for devices
- Give managed devices a strong identity, typically a certificate or hardware-backed key, and use it in access decisions.
- Define what unmanaged and personal devices may reach, for example browser-only access to low-risk applications.
- Feed endpoint health into policy, and decide what happens when a device falls out of compliance.
Zero trust for workloads and non-human identities
Most requests inside a modern environment are service to service. Zero trust applies there too:
- Give each workload a verifiable identity from its platform, for example cloud workload identity or SPIFFE, rather than a shared secret. See the Cloud Workload Identity Guide and the Guide to SPIFFE and SPIRE.
- Authenticate service-to-service calls with mutual TLS or signed tokens, and authorise each call. See the NHI Authentication Guide.
- Segment by identity rather than by IP address, so a compromised workload cannot reach everything on the same network.
- Scope cloud permissions tightly. See the Cloud PAM and CIEM Guide.
- AI agents need the same treatment, with per-action policy. See Zero Trust for AI Agents.
Maturity and roadmap
The CISA Zero Trust Maturity Model (version 2.0) describes five pillars (identity, devices, networks, applications and workloads, and data) and three cross-cutting capabilities (visibility and analytics, automation and orchestration, and governance), each progressing through traditional, initial, advanced and optimal stages. A practical sequence for most organisations:
- Harden identity first: consolidate identity providers, enforce phishing-resistant MFA for admins, remove legacy authentication.
- Protect the most-attacked paths: remote access, email, the identity provider and privileged access.
- Add device signals to access decisions.
- Move applications to per-application access and retire broad network access.
- Extend to workloads: workload identity, service-to-service authentication and identity-based segmentation.
- Automate and continuously evaluate: shared signals, session revocation and automated response.
Common failure patterns
- Buying a "zero trust product" and treating the project as done.
- Protecting users but not workloads, leaving service accounts and API keys with broad standing access.
- Exceptions that become permanent, such as trusted locations and excluded groups.
- Segmenting the network while identity stays weak, so an attacker with valid credentials walks through every segment.
- No measurement, so nobody can show what risk has actually reduced.
Practitioner checklist
- Inventory identities, devices, workloads and the resources they access.
- Put every application behind policy-based access through the identity provider or an identity-aware proxy.
- Enforce phishing-resistant MFA, starting with administrators and remote access.
- Use device identity and posture in access decisions.
- Give workloads platform-issued identities and authenticate service-to-service calls.
- Remove standing privilege and apply just-in-time access.
- Adopt continuous access evaluation and session revocation.
- Track progress against the CISA maturity model and report on it.
Standards and references
- NIST SP 800-207: Zero Trust Architecture (2020)
- CISA Zero Trust Maturity Model, version 2.0 (2023)
- NIST NCCoE: Implementing a Zero Trust Architecture (SP 1800-35)
- OMB M-22-09: Moving the U.S. Government Toward Zero Trust (2022)
- OpenID Shared Signals Working Group (SSF, CAEP, RISC)
Related NHI Mgmt Group resources: Zero Trust for AI Agents · Remote Access Identity Guide · Identity Security Programme Guide · JIT Access Guide
