Zero Trust Architecture
What is zero trust architecture? A clear guide to the zero trust principles, the NIST SP 800-207 tenets, how it works, and how to implement it. Read on.
Article Contents
What Is Zero Trust Architecture (ZTA)?
Zero trust architecture is a way to design security so that no user, device, workload, or AI agent is trusted by default, and every request to reach a resource is verified against identity and context before access is granted. The older perimeter approach trusted anything already inside the network. A zero trust approach removes that assumption and checks every connection, every time.
Read on for a definition of zero trust architecture, the principles set out in NIST Special Publication 800-207, how the pieces work together, and what it takes to put a zero trust approach into production.
Zero Trust Architecture
Zero trust architecture is a security design that treats every access request as untrusted until it is verified, no matter where the request comes from. Rather than trusting a user or device because it sits inside a corporate network, a zero trust architecture authenticates and authorizes each connection based on who or what is asking, the device or workload the request comes from, and the sensitivity of the resource being requested.
The term traces to analyst John Kindervag, who argued in 2010 that the trusted internal network was itself the problem, because one breach of the perimeter handed an attacker broad reach. Google reached a similar conclusion with its BeyondCorp program and moved access decisions away from network location and onto verified identity and device state. The United States government later codified the approach in NIST SP 800-207, which remains the reference definition most teams work from today.
Zero Trust Architecture in plain English
Zero trust means never trusting a connection by default. Every request to reach a resource is checked against identity and context first, and access is limited to that one resource for that one session.
The principles of zero trust (NIST SP 800-207)
NIST SP 800-207 sets out seven tenets that define what zero trust architecture requires. Read together, the tenets move trust off the network and onto continuously verified identity, device state, and policy. The following table states each tenet and what it asks of a working system.
| NIST 800-207 tenet | What it requires |
|---|---|
| All data sources and computing services are resources | Treat every server, database, cluster, API, and service as something access must be requested for, not as trusted infrastructure. |
| All communication is secured regardless of location | Encrypt and authenticate traffic whether it originates inside or outside the network. Being on the LAN earns nothing. |
| Access is granted per session | Grant access to one resource for one session, then require verification again for the next request. |
| Access is determined by dynamic policy | Decide each request using identity, device state, workload attributes, and behavioral signals, not a static allow list. |
| The organization monitors the integrity of its assets | Continuously measure the security posture of every device and workload, and factor that state into access decisions. |
| Authentication and authorization are dynamic and strictly enforced | Verify identity and authorization before every connection, and re-verify as context changes. |
| The organization collects data to improve its security | Log access, device state, and network activity, and feed that data back into policy. |
However, no single product delivers all seven. Instead, a zero trust architecture is a design goal that identity, device, network, and monitoring systems work toward together, and NIST 800-207 is the framework that teams can measure their security design against.
What a zero trust architecture consists of
NIST SP 800-207 describes zero trust as three logical components that decide and enforce every access request. The policy engine (PE) is the part that makes the allow-or-deny decision, weighing identity, device health, and other signals against policy. The policy administrator (PA) carries out that decision, opening or closing the connection and issuing any session credential the request needs. Taken together, the PE and PA form the policy decision point, the control plane where trust is evaluated.
The policy enforcement point (PEP) sits in the data path and is where a decision becomes real. Every request from a user, service, or agent passes through the PEP, which admits authorized traffic and blocks everything else. In Teleport, the proxy acts as that enforcement point for infrastructure, brokering each connection to a server, database, or Kubernetes cluster after the decision is made.
A policy engine draws on identity from the provider, device posture from endpoint tools, threat intelligence, and activity logs. Strong identity is the most important input, because an access decision built on a weak or shared credential fails no matter how capable the engine is.
Zero trust architecture vs the traditional perimeter
For decades, security worked like a castle and moat. A firewall and a VPN formed the wall, and anything inside the wall was trusted. However, a perimeter design fails the moment an attacker gets in, because a single stolen credential or one compromised device inherits the broad reach that everything inside the perimeter enjoys. Attackers move laterally from the first foothold and reach far more than they should.
A zero trust architecture removes the trusted interior. Instead, every request is authenticated and authorized on its own, access is limited to a single resource, and a compromise of one identity no longer opens the rest of the network. The following table sets the two approaches side by side.
| Perimeter security | Zero trust | |
|---|---|---|
| Basis for trust | Network location (inside the firewall or VPN) | Verified identity, device state, and policy |
| Breadth of access | Broad network reach once connected | One resource, one session |
| Blast radius after a breach | Lateral movement across the flat network | Contained to what that identity was authorized for |
| Where policy lives | At the network edge | At every resource, evaluated per request |
| Fit for cloud and remote work | Poor, the perimeter dissolves across clouds | Built for multi-cloud, remote, and hybrid |
How does zero trust work?
A zero trust architecture turns identity into the control point and verifies context on every request. Five behaviors define what that looks like in production.
Verify identity for every request
Zero trust starts by proving who or what is connecting. Strong authentication, ideally phishing-resistant and backed by hardware, replaces the assumption that a network address is a stand-in for identity. Machines, workloads, and AI agents also receive verifiable identities.
Enforce least privilege and just-in-time access
Verifying identity is only half the decision. Zero trust grants the least privilege the task needs and, wherever possible, grants it just-in-time so access expires on its own. Standing administrative rights are the reward an attacker collects with one stolen credential, so a zero trust architecture keeps them close to zero.
Segment the network and limit blast radius
Microsegmentation divides infrastructure into small zones so that reaching one resource does not grant reach to other resources on the network. Resource-level authorization performs the same function at the identity layer.
Verify continuously, not just at login
A single check at login is not enough because context can change mid-session. Zero trust continuously re-evaluates and verifies trust to revoke or challenge access when a device falls out of compliance or behavior looks wrong.
Log and analyze everything
Every access decision and session becomes a record. Audit logs and session recordings give security teams the evidence to investigate incidents, satisfy auditors, and feed activity back into policy.
Frequently Asked Questions
What is zero trust architecture?
Zero trust architecture is a security design in which no user, device, workload, or AI agent is trusted by default. Every request to reach a resource is authenticated and authorized against identity and context first, and access is limited to that one resource for that one session, so a single stolen credential no longer opens the whole network.
What are the seven tenets of zero trust?
NIST SP 800-207 lists seven tenets. All computing services are treated as protected resources, all communication is secured regardless of location, access is granted per session, access is decided by dynamic policy, the organization monitors asset integrity, authentication and authorization are dynamic and strictly enforced, and the organization collects activity data to improve its security.
What is NIST SP 800-207?
NIST Special Publication 800-207 is the United States government’s reference definition of zero trust architecture, published in 2020. Written by the National Institute of Standards and Technology, the document sets out the seven tenets of zero trust and describes how to move an organization off perimeter-based security toward identity-based access.
Is zero trust the same as ZTNA?
Zero trust architecture and ZTNA are related but not the same thing. Zero trust architecture is the overall security design, while zero trust network access (ZTNA) is one technology that applies it to remote and infrastructure access by brokering identity-based connections to specific resources. ZTNA is a way to implement zero trust rather than a synonym for it.
How is zero trust different from a VPN?
A VPN grants broad network access when a user connects, so a compromise reaches everything on the network. A zero trust architecture grants access to a single resource per session based on verified identity, which keeps a breach contained and produces a clean, per-identity audit trail that a VPN cannot.
How do you implement zero trust architecture?
Start by inventorying resources and the identities that reach them, then move access decisions off the network and onto verified identity and device state. Reduce standing privilege with least privilege and just-in-time access, segment the environment to contain a breach, log every session, and expand from the highest-risk systems outward.