Zero-trust architecture.
For decades, networks worked like a guarded building: get past the front door once, and the inside trusts you. Zero trust replaces that with a simpler rule. Never trust, always verify.
Zero trust removes implicit trust based on where a request comes from, and instead checks every request on its own, every time, against who is asking, what device they are on, and what policy allows right now. This page explains the field: what it is, why the old model broke, how a per-request decision works, what it unlocks, and where it is going. The canonical standards and source reports are linked, so you can read them yourself.
Trust is earned per request, not granted by location.
Zero trust is a set of guiding principles and an architecture, not a single product you buy.
The slogan that captures it is "never trust, always verify." Being on the network proves nothing. Every request to reach a resource is checked on its own, against who is asking, what device they are on, and whether policy allows it right now. Access is kept as narrow as the job needs, which the field calls least privilege, and the system keeps watching rather than deciding once at login and forgetting.
The lineage matters. The Jericho Forum's work on deperimeterization in the mid-2000s argued the hard outer wall was eroding as work went mobile and cloud. The phrase "zero trust" was coined by John Kindervag at Forrester in 2010. NIST SP 800-207 (2020) is explicit that the perimeter does not vanish. It just stops being the thing you trust. Two scopes are worth separating: zero trust for user access (people reaching apps) and zero trust for service-to-service traffic inside production (workloads that do not trust each other by default). Both are zero trust. The subject differs.
- Identity verified
- Device meets policy
- Action is within the granted scope
The perimeter assumption broke, and fixing it is an architecture change.
Cloud apps, mobile devices, remote work, and contractors mean the "inside" is no longer a place. There is no single wall to stand behind.
Lateral movement is the target.
In a perimeter model, one breached credential or device often grants broad internal reach. Zero trust exists to shrink that blast radius, so a compromise should reach one resource, not the whole estate.
You cannot bolt it on.
Zero trust touches identity, device management, segmentation, and every enforcement point. NIST and CISA both frame it as a multi-year migration, not a feature you switch on.
Strong identity and device signals first.
A per-request decision is only as good as its inputs. You need reliable identity, ideally phishing-resistant authentication, and trustworthy device posture, or the "verify" half of the slogan is hollow.
Policy becomes the source of truth.
Moving from "trusted network" to "written policy evaluated per request" concentrates risk in the policy and the decision engine. Policy has to be authored, tested, and governed like software.
Latency, availability, friction.
Checking every request adds a decision in the path and makes the policy engine a critical dependency. Done badly it slows people down or becomes a single point of failure. The design has to account for both.
It is not a product category.
Many tools attach the "zero trust" label. The discipline is the principle set, not any one box. Honest copy keeps that distinction, and so does this page.
Every request flows through a decision.
The core abstraction from NIST SP 800-207: an enforcement point in the path asks a decision point, which evaluates policy against live signals and returns permit or deny.
- Request reaches the PEP
Include verified identity and relevant device or context signals.
- PDP evaluates policy
Determine whether this subject may perform this action on this resource.
- PEP enforces the decision
Permit only the authorized access or deny the request.
The model NIST SP 800-207 pins down: the enforcement point asks, the policy engine decides from who, what device, and what policy allows right now.
1Signals feed the decision, continuously
A decision, not a one-time login.
The engine weighs identity, device posture and health, the resource being requested, prior behavior, threat intelligence, and environmental context such as time, location, and risk. NIST calls this continuous diagnostics. The verdict is dynamic.
Access is evaluated as close to per request as practical, and trust is re-evaluated rather than assumed for a whole session. A change in device health or risk can revoke access mid-stream. The same person can get one answer from a healthy laptop and a different answer from a flagged one.
| Time | Context | Decision |
|---|---|---|
| 09:01 | Healthy managed device | Permit scoped request |
| 09:14 | Policy still satisfied | Continue permitted access |
| 09:20 | Device becomes high risk | Reevaluate or revoke |
2Least privilege and microsegmentation
Grant the narrow thing, segment the rest.
Grants are scoped to the specific resource and kept as small as the job needs. The network is divided into small segments, down to per-workload, so that reaching one thing does not imply reaching its neighbors. The implicit trust zone shrinks toward a single request.
This is the discipline behind a familiar enterprise-software outcome: keeping one client's data walled off from another's in shared software, and answering a question using only the records the asker is permitted to see. We state that as an example of what the field enables, not as a claim about any one product.
Broad access
Segmented access
Separate policy checks guard App B, the database, and administration.
3Two patterns in practice
The proxy for people, mutual auth for services.
For user access, an identity-aware access proxy fronts each application and checks user and device on every request, rather than a VPN that places a device "inside." Network location grants nothing; the proxy and policy do. This is the BeyondCorp (Ward and Beyer, 2014) pattern.
For traffic between services in production, BeyondProd (Google, 2019) extends the same posture: services authenticate each other with mutual TLS, run with verified provenance so only centrally built, approved code deploys, and are isolated by sandboxing. No service trusts another simply because they share a network.
| Request path | Relevant checks |
|---|---|
| Person → application | Identity, device context, resource permission |
| Service → service | Workload identity, mutual authentication, authorization |
| Deployment → production | Artifact provenance and deployment policy |
4An operating map
Five pillars for where to start.
CISA's Zero Trust Maturity Model (2023) organizes the work into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data, with cross-cutting capabilities for Visibility and Analytics, Automation and Orchestration, and Governance.
It lays out a maturity path from traditional to optimal, which is useful for the "where do we even start" question. It is a reader's map, not the last word on definitions. NIST SP 800-207 remains the canonical reference for the architecture itself.
- Visibility and analytics
- Observe activity and risk across the pillars.
- Automation and orchestration
- Apply consistent policy and response.
- Governance
- Define ownership, rules, and review.
What the posture unlocks.
At the field level: containment by design, location-independent work, context-aware decisions, and boundaries you can prove and review.
A sales co-pilot built on CRM and conversation data, used from offices, homes, and phones across many SaaS apps, lives in exactly the world that broke the perimeter model. So this is the field worth understanding on its own terms. The connection here is at the level of the buyer's outcome, not the plumbing. We make no claim about how any product implements it.
Containment by design.
A compromised credential or device reaches a bounded set of resources, not the whole network. Lateral movement is the explicit thing the architecture denies.
Isolation as a feature.
Applied well, the same discipline is what keeps one organization's data walled off from another's in shared software, and supports answering only from records the asker may see. Stated as the field's payoff, as an example for enterprise SaaS.
Decisions that use context.
Per-request evaluation can factor device health, risk, and sensitivity, so the same person gets a different answer from a healthy laptop and a flagged one.
Provable, reviewable boundaries.
Centralized policy and enforcement make "who can reach this, under what conditions" answerable and auditable, which is what security reviews and customers ask for.
For AI REV Voice's data protection and access controls, see Security & privacy. This explainer covers the underlying research.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
A standardized posture.
Zero trust moved from a Forrester idea to government direction, with US Executive Order 14028 (2021) and OMB M-22-09 setting federal agencies on a zero-trust path, NIST SP 800-207 as the reference architecture, and CISA's model as the roadmap.
Per-workload, not just user access.
The center of gravity is moving toward service-to-service trust, the BeyondProd direction: mutual authentication, workload identity, and provenance checks as the default inside production.
Phishing-resistant by default.
Hardware-backed, passkey-style, device-bound authentication is becoming the assumed input, because per-request verification is only as good as the identity signal behind it.
Re-checking, not a single grant.
The trend is toward continuous evaluation and risk-adaptive access, re-checking during a session and adjusting on changing signals, rather than one decision at login.
Externalized, version-controlled policy.
Shared decision engines and more standard device and identity signals feeding them are the practical direction, so policy can be authored, tested, and reviewed like software.
A posture and a journey.
Zero trust reduces blast radius and removes a bad assumption. It does not make a system "unbreachable." The hard part is sustaining strong identity, device signals, and good policy as the organization changes.
The sources behind this page.
- Kindervag, J. (2010). No More Chewy Centers: Introducing the Zero Trust Model of Information Security. Forrester Research.
- Ward, R., & Beyer, B. (2014). BeyondCorp: A New Approach to Enterprise Security. ;login:, USENIX, 39(6), 6-11.
- Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207.
- Google (2019). BeyondProd: A new approach to cloud-native security. Google Cloud.
- Cybersecurity and Infrastructure Security Agency (2023). Zero Trust Maturity Model, Version 2.0. CISA.
Keep reading.
Sibling explainers in the Research section, same theme.
Talk. Done.
The field is mature, the standards are public, and the discipline is well understood. See what a voice you can just talk to feels like on a real call.
No app required. Just your phone number.