Zero Trust Identity Guide: Identity as the Control Plane

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, a maturity journey described in the CISA Zero Trust Maturity Model, and a set of design principles published by national agencies such as the UK NCSC. This guide explains the principles and architecture, the identity capabilities zero trust depends on, how to apply it to people, devices, workloads and AI agents, how to detect misuse, and how to build and measure a roadmap that reduces risk early. It is written for identity architects, security leaders and platform teams.

Key takeaways

• No implicit trust from location. NIST SP 800-207 states that "network location alone does not imply trust"; every access is authenticated, authorised and evaluated against policy, per session.
• Identity is the foundation. Strong authentication, device trust, least privilege and continuous evaluation have to cover every identity type, human and non-human.
• Workloads and agents are in scope. NIST SP 800-207A shifts the focus of controls from IP addresses and subnets to application and service identities, and SP 800-207 flags software agents in administration as an open risk.
• Deliver in phases. Start with the highest-value assets and most-attacked access paths, such as administrators, remote access and the identity provider itself.
• Measure against a maturity model. CISA's model runs from Traditional through Initial and Advanced to Optimal; track movement per function instead of declaring a project finished.

Principles

NIST SP 800-207 (August 2020) sets out seven tenets. In practical terms:

• All resources are protected individually: "All data sources and computing services are considered resources", including applications, data, APIs, SaaS and infrastructure.
• Location grants nothing: "All communication is secured regardless of network location." A request from the corporate network meets the same requirements as one from the internet.
• Access is per session and per resource: trust in the requester is evaluated before access is granted, with the least privilege needed for the task.
• Decisions are dynamic: policy uses the observable state of the client identity, the application or service and the requesting asset, and may include behavioural and environmental attributes.
• No asset is inherently trusted: the enterprise monitors and measures the integrity and security posture of all owned and associated assets.
• Authentication and authorisation are continuous: "a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust".
• Telemetry improves policy: the enterprise collects as much information as possible about assets, network traffic and access requests, and uses it to improve its posture.

The UK NCSC's zero trust design principles say the same in operational terms: 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 do not trust any network, including your own. The NCSC adds that each identity, whether "a user (a human), service (software process) or device", should be uniquely identifiable.

The architecture

NIST SP 800-207 separates the decision from the enforcement. The logical components are below; the practitioner columns are NHI Mgmt Group examples, not NIST text.

NIST describes three approaches: enhanced identity governance, micro-segmentation, and network infrastructure with software defined perimeters. Most enterprises combine them, but the identity governance approach is the one every other approach depends on. NIST also warns that the PE and PA become "the key components of the entire enterprise": an administrator with configuration access to the policy engine's rules can make unapproved changes, so policy administration needs the strictest privileged access controls in the estate. NIST SP 1800-35 (June 2025) adds 19 example implementations built with commercial products. For policy models, see the Authorisation Models Guide; for gateways, see the Zero Trust Network Access (ZTNA) Guide.

The identity capabilities zero trust depends on

CISA's model defines an identity as "an attribute or set of attributes that uniquely describes an agency user or entity, including non-person entities". That definition matters: a zero trust programme that inventories only staff accounts has covered a fraction of the identities making requests.

Zero trust for people

• Centralise identity: put applications behind an enterprise identity provider and enforce conditional access on user, device, location and risk. OMB M-22-09 required US agencies to "employ centralized identity management systems" that can be integrated into applications. See the Identity Provider and SSO Security Guide and the Conditional Access Guide.
• Phishing-resistant MFA at the application layer: M-22-09 says "MFA must be enforced at the application layer, instead of the network layer", and requires agencies to drop methods that register phone numbers for SMS or voice, supply one-time codes or receive push notifications for routine staff access.
• Per-application access instead of network access: replace broad VPN access with per-application access where you can. See the Remote Access Identity Guide.
• Continuous access evaluation: account disablement, credential change or risk elevation should end existing sessions rather than waiting for tokens to expire. The OpenID Foundation approved the Shared Signals Framework, CAEP and RISC as Final Specifications in September 2025; CAEP events include session revoked, credential change, assurance level change and device compliance change.
• Administrators first: dedicated admin identities, phishing-resistant MFA, privileged access workstations and just-in-time elevation. See the Privileged Access Management Guide.

Zero trust for devices

• Give managed devices a strong identity, typically a certificate or hardware-backed key, and use it in access decisions. M-22-09 asks agencies to consider "at least one device-level signal alongside identity information about the authenticated user".
• Define what unmanaged and personal devices may reach, for example browser-only access to low-risk applications.
• Feed endpoint health into policy, and decide in advance what happens when a device falls out of compliance: step-up, restricted access or block.
• Cover devices that cannot run agents, such as printers, IoT and OT, with network controls and device identity. See the Device and IoT Identity Guide and the OT and ICS Identity and Access Guide.

Zero trust for workloads and non-human identities

Most requests inside a modern environment are service to service, and NIST SP 800-207A (September 2023) describes the shift for cloud-native applications: from controls based on IP addresses, subnets and perimeters to "authentication and authorization policies based on application and service identities".

• Platform-issued identity, not shared secrets: use cloud workload identity, workload identity federation or SPIFFE, whose specifications define "short lived cryptographic identity documents" called SVIDs. See the Cloud Workload Identity Guide and the Workload Identity Federation Guide.
• Authenticate and authorise every call: mutual TLS or signed tokens, with a policy check on each request. See the NHI Authentication Guide and the Service Mesh Security Guide.
• Segment by identity rather than address, so a compromised workload cannot reach everything on the same network.
• Scope cloud permissions tightly and remove unused entitlements. See the Cloud PAM and CIEM Guide.
• Rotate or retire every long-lived credential, because a single forgotten token undoes the model, as Cloudflare found in 2023.

AI agents

NIST SP 800-207 already anticipated this problem in its section on non-person entities: artificial intelligence and other software agents interact with policy components, how they authenticate "is an open issue", they may have "a lower bar for authentication (e.g., API key versus MFA)", and an attacker could "trick the agent into allowing the attacker greater access". Treat each agent as its own identity with short-lived, task-scoped credentials, evaluate policy per action rather than per session, and keep a human approval step for high-impact actions. See the Zero Trust for AI Agents Guide.

Maturity and roadmap

The CISA Zero Trust Maturity Model version 2.0 (April 2023) has five pillars (identity, devices, networks, applications and workloads, and data) and three cross-cutting capabilities (visibility and analytics, automation and orchestration, and governance), each moving through Traditional, Initial, Advanced and Optimal stages. To assess each pillar and plan the next stage, use the Zero Trust Maturity Model Guide. The identity pillar shows what progress looks like:

A phased sequence that works for most organisations:

For programme structure, see the Identity Security Programme Guide.

Detection and monitoring

Zero trust does not remove the need for detection; it changes what you watch. NIST notes that an attacker with valid credentials "may still be able to access resources for which the account has been granted access", and that a contextual trust algorithm is more likely to spot access "out of normal behavior". Monitor for:

• Policy changes: edits to conditional access, policy engine rules and exclusions, and who made them.
• Exceptions in use: sign-ins that succeeded only because of a trusted location, excluded group or legacy protocol.
• Session anomalies: token replay, sessions continuing after a credential change, impossible travel.
• Non-human identity drift: service accounts or tokens used from new sources, at new times or against new resources.
• Denied requests: repeated denials are often the first sign of lateral movement, as Cloudflare's 2023 incident showed.

See the ITDR Guide.

Lessons from incidents

• Snowflake customer breaches (2024): Mandiant found that the affected customer instances "did not require multi-factor authentication", that stolen credentials had in many cases not been rotated for as long as four years, and that network allow lists were not used. Every zero trust identity basic was missing.
• Cloudflare Thanksgiving incident (2023): attackers used one access token and three service account credentials that Cloudflare "failed to rotate" after an earlier Okta compromise. Cloudflare says access controls, firewall rules and hard security keys enforced through its own zero trust tools limited lateral movement; an attempt to reach a console server through a non-enforced ACL was denied.
• Federal agencies (M-22-09): OMB's reasoning for phishing-resistant MFA was that "enterprise users are among the most valuable targets for phishing", which is why the memorandum ruled out SMS, one-time codes and push for routine access.

Common failure patterns

• Buying a "zero trust product" and treating the project as done. NIST describes an architecture, not a product category. See the Top 10 Zero Trust Mistakes for others.
• Protecting users but not workloads, leaving service accounts and API keys with broad standing access, as in the Cloudflare incident.
• Exceptions that become permanent, such as trusted locations, excluded groups and legacy protocols kept "for now".
• Segmenting the network while identity stays weak, so an attacker with valid credentials walks through every segment.
• Unprotected policy administration: the policy engine is administered with ordinary accounts, so one compromise rewrites every decision.
• Login-time decisions only: sessions last days with no revocation when risk changes.
• No measurement, so nobody can show what risk has actually reduced.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official mapping. IDs were checked against the NIST CSF 2.0 text, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 list (control level), an ISO/IEC 27001:2022 Annex A control list and the OWASP NHI Top 10 2025.

Metrics that show progress

For a full metrics set, see the Identity Security Metrics Guide.

Practitioner checklist

• Inventory identities, devices, workloads, AI agents 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 at the application layer, starting with administrators and remote access.
• Use device identity and posture in access decisions.
• Give workloads platform-issued identities and authenticate every service-to-service call.
• Remove standing privilege and apply just-in-time access.
• Protect policy administration as the most privileged function in the estate.
• Adopt continuous access evaluation and shared signals for session revocation.
• Review and expire policy exceptions on a fixed cycle.
• Give each AI agent its own identity with per-action policy.
• Track progress against the CISA maturity model and report on it.

Standards and references

• NIST: SP 800-207, Zero Trust Architecture
• NIST: SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• NIST: SP 1800-35, Implementing a Zero Trust Architecture
• CISA: Zero Trust Maturity Model, version 2.0
• OMB: M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• NCSC: Zero trust architecture design principles
• OpenID Foundation: Shared Signals Working Group (SSF, CAEP, RISC)
• OpenID Foundation: Three Shared Signals Final Specifications Approved
• SPIFFE: SPIFFE Overview
• Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
• Cloudflare: Thanksgiving 2023 security incident

Related NHI Mgmt Group resources: Zero Trust for AI Agents Guide · Remote Access Identity Guide · Identity Security Programme Guide · JIT Access Guide · Network Segmentation and Microsegmentation Guide