Zero Trust Architecture

What Zero Trust is (and isn't)

Zero Trust is an architectural strategy built on a single assumption: the network is not a trust boundary. A request originating inside the corporate VPN, the production VPC, or the Kubernetes cluster is treated with the same skepticism as one from the public internet. Every request - human to application, application to API, service to service - is authenticated, authorized against a dynamic policy that considers identity, device posture, and context, and recorded.

That definition has three load-bearing words. Architectural: it is a way of designing systems, not a SKU. Strategy: it is multi-year and touches identity, networks, applications, workloads, and data; you do not buy your way to it in a quarter. Per-request: trust is established at the moment of access, not at the moment of network connection, and it can be revoked between requests.

Things Zero Trust is not:

• Not a product. No vendor ships "Zero Trust." Vendors ship products that implement parts of a Zero Trust Architecture - ZTNA, microsegmentation, identity-aware proxies, posture-management agents, service meshes. The architecture is what you build on top.
• Not just VPN replacement. ZTNA replacing your VPN is a real, valuable project. Calling it Zero Trust is a category error - you've improved remote user access while leaving every workload-to-workload call inside the cluster on implicit trust.
• Not "trust no one" in a literal sense. The shorthand never trust, always verify is rhetorical. Of course you trust authenticated identities to do their job - the point is that trust is established per request from explicit signals, not granted implicitly because of network location.
• Not a one-time project. Zero Trust is closer to a posture you continuously improve than a milestone you hit. Maturity models (CISA, DoD) explicitly stage the work over years.
• Not the death of the firewall. Defense in depth still matters. Perimeter and egress controls remain useful as coarse-grained filters and for compliance - they're just no longer where trust decisions live.

If you take one thing from this page, take this: a Zero Trust program is half engineering and half organizational change. The technology is largely ready; the hard part is sequencing the work and not letting any single vendor talk you into thinking their box is the whole story.

The origin story

Three moments matter.

2010 - Forrester coins the term

John Kindervag, then a Forrester analyst, published No More Chewy Centers: Introducing the Zero Trust Model of Information Security. The argument was that the prevailing castle-and-moat model - hard perimeter, soft interior - had failed; once an attacker was inside the network, lateral movement was trivial. Kindervag's prescription: trust nothing by default, verify everything, inspect and log all traffic. This is the conceptual seed. The implementation guidance was thin because the tooling didn't yet exist at scale.

2014 - Google publishes BeyondCorp

Google's BeyondCorp papers (initial paper 2014, series running through 2018) described a working production implementation. The motivation: after the 2009 Operation Aurora intrusion, Google moved every employee application off the corporate VPN. Access was made conditional on user identity, device identity (managed device with valid certificate), and per-application policy enforced at an identity-aware proxy. The location of the user - corporate office, home, coffee shop - became irrelevant. BeyondCorp is the proof-of-existence reference every later vendor pitch implicitly invokes.

2020 - NIST SP 800-207 standardizes it

NIST Special Publication 800-207, Zero Trust Architecture, published August 2020, is the canonical vendor-neutral definition. It establishes the seven tenets, the logical components (PDP / PEP / Policy Engine / Policy Administrator / Trust Algorithm), and three deployment approaches (enhanced identity governance, micro-segmentation, network infrastructure / SDP). Federal civilian agencies were directed to align with it under OMB Memorandum M-22-09 in January 2022. The downstream consequence is that every U.S. federal cloud security program - and a large fraction of regulated private-sector programs - now maps to 800-207 terminology. When in doubt, that is the document to read.

Other touchstones worth knowing: the DoD Zero Trust Reference Architecture v2.0 (2022), the CISA Zero Trust Maturity Model v2.0 (2023), and NSA's Embracing a Zero Trust Security Model guidance.

The seven tenets (NIST SP 800-207)

800-207 enumerates seven tenets every Zero Trust Architecture is expected to satisfy. Paraphrased in operator language:

1. All data sources and computing services are considered resources. A virtual machine, a SaaS API, a Kubernetes pod, a managed database, a customer-managed key - every one is a resource that must be protected by the same access-decision discipline. There is no "internal" stuff you don't have to wrap.
2. All communication is secured regardless of network location. A request from a workload in the same VPC gets the same authentication, the same encryption (typically mTLS), and the same authorization check as one from the public internet. Same-subnet implicit trust is gone.
3. Access to individual resources is granted per session. Authentication and authorization happen at the moment of access for that specific resource. A previously granted session does not implicitly grant access to other resources, and may not survive context changes (location, posture, time of day).
4. Access is determined by dynamic policy. The policy decision considers the requesting identity, the device's posture, the data sensitivity, behavioral context, and risk signals. Policy is not a static ACL; it's an evaluation that can return different answers for the same identity at different moments.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. Devices, workloads, services - their state is observed continuously. A device whose posture has degraded loses access until remediated.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Re-authentication and re-authorization happen on a cadence appropriate to the resource sensitivity. Strong authentication, ideally phishing-resistant (FIDO2 / WebAuthn, hardware tokens), is the floor for human users; cryptographic identity for workloads.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses it to improve its security posture. Telemetry is foundational. The policy engine and the SOC both depend on a richly instrumented environment - flow logs, audit logs, posture signals, identity events - to make better decisions over time.

Pragmatic reading: tenets 1, 2, and 3 are the architectural shifts; tenets 4 and 6 require a real policy engine, not just static rules; tenets 5 and 7 are why a Zero Trust program is also necessarily a telemetry investment. You cannot have dynamic, posture-aware access decisions without the signals that feed them.

Core components: PDP, PEP, Policy Engine, Trust Algorithm

NIST 800-207 abstracts the architecture into a small number of logical components. Every product you evaluate maps to one or more of them.

The mental model that helps: the PEP is on the data path and must be fast; the PDP is on the control path and may be more expensive; both are continuously fed by signal sources. When you evaluate a "Zero Trust" product, ask which boxes it occupies - and where it expects the others to come from.

Identity-aware proxy & ZTNA vs VPN

The most visible Zero Trust pattern, and the one most often mistaken for the whole thing. The premise: instead of giving a remote user a VPN tunnel into the corporate network - where they then have broad lateral access - terminate them at an identity-aware proxy that brokers access to specific applications, based on identity and device posture, per request.

The shape

User opens a browser, hits app.internal.example.com, is redirected to the IdP, authenticates with MFA, the proxy evaluates a policy ("this user, this device, this app, this time"), and if allowed brokers the connection to the application. The application can sit anywhere - on-prem, in a VPC, in another cloud - and is not reachable except through the proxy. The user never gets a network-level handle on the resource.

ZTNA vs VPN, in practice

The product landscape

• Cloudflare Access - part of Cloudflare One. Browser-first; strong DX; integrates with Cloudflare's WARP client for non-HTTP apps.
• Zscaler Private Access (ZPA) - enterprise heavyweight. Strong on app discovery and segmentation; complex pricing.
• Tailscale - WireGuard-based mesh with an IdP-backed control plane. Engineer-favorite for its DX; ACLs as code; lighter on policy depth than Cloudflare / Zscaler but moving fast.
• Twingate - split-tunnel, agent-based, similar engineer-DX positioning to Tailscale.
• Google Cloud Identity-Aware Proxy (IAP) - the BeyondCorp pattern, productized. Works for HTTPS apps in GCP and on-prem (via the connector); integrates natively with Google identity.
• Microsoft Entra Application Proxy (formerly Azure AD App Proxy) - publishes on-prem apps via Entra ID; tight integration with Conditional Access for policy.
• Palo Alto Prisma Access, Netskope Private Access, Appgate SDP - broader SSE / SASE platforms with ZTNA as a component.
• Open-source - Pomerium, Ory Oathkeeper, HashiCorp Boundary. Right when you have engineering capacity and want full control.

Vendor-neutral take: ZTNA is the easiest entry point to a Zero Trust program because the user-visible win is real (no more VPN). Just remember: shipping ZTNA gets you one pillar - Identity + Networks for human-to-app traffic. The east-west, workload-to-workload, and data tiers remain untouched.

Microsegmentation

If ZTNA handles the north-south (user → app) traffic, microsegmentation handles the east-west (workload → workload). The goal is the same - no implicit trust based on network location - but the mechanics are different. The enforcement point is at the workload itself, or at a service-mesh sidecar, not a centralized proxy.

Three flavors

How to choose

The three flavors are complementary, not exclusive. A mature program runs cloud-native segmentation at the VPC/subnet level for blast-radius, Kubernetes NetworkPolicies (Calico / Cilium) for pod-to-pod, and a service mesh for L7 authorization on the most sensitive services. Layer them, with the same naming and identity scheme across layers.

The hardest part of microsegmentation is not the enforcement - it is discovery. You cannot write a deny-by-default rule until you know what the legitimate east-west flows are. Most projects start with audit-mode policies for 60-90 days, build the dependency map, then ratchet to enforce. Tools like Illumio, Guardicore, and Cilium Hubble exist primarily to make this discovery tractable.

Continuous verification & device posture

The "every device verified on every request" tenet only works if there's a real-time posture signal. The device-posture stack is what produces it.

• MDM / UEM - Jamf (macOS / iOS), Microsoft Intune (Windows / mixed), VMware Workspace ONE, Kandji, Fleet (open-source, osquery-based). Enrolls the device, applies configuration policy, attests management state.
• EDR - CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint. Real-time telemetry on process behavior; produces the trust score that feeds the PDP. CrowdStrike's Falcon Zero Trust Assessment (ZTA) score is a notable example of an EDR vendor surfacing posture explicitly for ZT decisions.
• Posture-only / honest-endpoint tools - Kolide (now part of 1Password) is the standout: lightweight posture checks, surfaced to the user via Slack rather than IT enforcement. Strong fit for engineer-heavy orgs.
• Browser-as-endpoint - Island, Talon (now Palo Alto), Chrome Enterprise. Treats the browser as the controlled endpoint, useful for contractor and BYOD scenarios where you don't own the OS.
• Device-bound credentials - FIDO2 / WebAuthn, platform passkeys, Windows Hello, Touch ID, hardware tokens (YubiKey, Google Titan). Cryptographically binds the credential to the device; phishing-resistant; the gold standard for the auth half of the device + identity check.

The posture data is only useful if your PDP can consume it. Microsoft Conditional Access pulls device-compliance state from Intune natively; Okta, Ping, and others pull from EDR / MDM via the Continuous Access Evaluation Protocol (CAEP, an OpenID Foundation spec, formerly Shared Signals and Events) so a device falling out of compliance can revoke an active session in seconds. CAEP is the most underappreciated piece of plumbing in the modern Zero Trust stack - without it, "continuous verification" is "verified at login, hopefully still true an hour later."

Workload-to-workload Zero Trust

The piece most ZT writeups under-cover. Once you accept that the network is not a trust boundary, every service-to-service call needs an authenticated, authorized identity - and that identity cannot be an IP address.

SPIFFE / SPIRE

SPIFFE (Secure Production Identity Framework For Everyone) defines a standard for workload identity: a SPIFFE ID (a URI like spiffe://example.com/ns/payments/sa/api) issued as an X.509 certificate (SVID) or JWT, attestable from runtime metadata (Kubernetes service account, AWS instance role, etc.). SPIRE is the reference implementation: a server that issues identities and an agent on each node that attests workloads and delivers SVIDs. SPIFFE is the CNCF graduated standard; Istio, Linkerd, Consul, and several proprietary platforms either embed it or interoperate with it.

mTLS as the default transport

Mutual TLS - both parties present certificates, both verify the other - is the data-plane mechanic. In a service mesh, sidecars terminate plaintext from the application and re-emit it as mTLS to the next hop. The application code doesn't change; the mesh handles identity, encryption, and policy. Outside a mesh, mTLS is configurable at any modern HTTP client / server, just with more boilerplate.

Cloud-provider workload identity

• AWS - IAM Roles, IAM Roles for Service Accounts (IRSA) for EKS, EKS Pod Identity. Every API call to AWS is already identity-authenticated via SigV4 - the AWS data plane has been zero-trust-aligned for service-to-AWS calls since the beginning.
• Azure - Managed Identities for Azure resources, Azure AD Workload Identity for AKS, federated with Entra ID.
• GCP - Workload Identity Federation, GKE Workload Identity. Federate external workload identities (AWS, Azure, on-prem, OIDC) into Google service-account impersonation without long-lived keys.

The principle in all three: short-lived, attestable credentials per workload, no long-lived secrets, every call cryptographically tied to a known identity. The patterns differ; the goal is the same. For service-to-service calls between clouds or between cloud and on-prem, SPIFFE is the lingua franca; for service-to-cloud-API calls, the provider's native workload identity is usually the right answer.

Applying Zero Trust in cloud

Concrete patterns that map the architecture to the three major clouds. None of these is "the Zero Trust button" - they are the pieces you assemble.

AWS

• IAM Identity Center + external IdP - federate workforce identity, enforce permission sets per account / role with session duration tied to risk. Pair with permissions boundaries and SCPs for guardrails.
• VPC Lattice - application-layer networking with identity-aware policies; service-to-service authentication using IAM. The closest AWS-native analog to a managed service mesh for workload Zero Trust across accounts and VPCs.
• PrivateLink + Verified Access - Verified Access is AWS's ZTNA-style identity-aware proxy for corporate apps; PrivateLink eliminates network reachability between accounts / VPCs.
• IRSA / Pod Identity - short-lived workload credentials for EKS, OIDC-trust to IAM. Pair with IAM Access Analyzer for least-privilege policy recommendation.
• Verified Permissions (Cedar) - externalized fine-grained authorization for your own apps. Cedar is AWS's policy language; pairs well with a custom Zero Trust authorization layer.

Azure

• Conditional Access - the canonical Microsoft Zero Trust enforcement point. Per-app policies considering user risk, device compliance (from Intune), location, sign-in risk; supports phishing-resistant authentication enforcement and CAEP-driven session revocation. The most mature out-of-the-box Trust Algorithm in the major clouds.
• Private Link + private endpoints - service reachability without public endpoints; pair with Managed Identities for caller identity.
• Entra Application Proxy + Conditional Access - identity-aware proxy for on-prem web apps with Conditional Access policy enforcement.
• Entra ID Workload Identities + AKS Workload Identity - federated workload identity, no client secrets in code.
• Defender for Cloud - posture and runtime signals into the trust algorithm.

GCP

• BeyondCorp Enterprise - productized BeyondCorp. Identity-aware proxy (IAP) + Chrome integration for posture + threat / data-loss protection. Closest thing to "BeyondCorp in a box" any cloud sells.
• Identity-Aware Proxy (IAP) - the building block. HTTPS apps and (via IAP TCP forwarding) SSH/RDP/arbitrary TCP, fronted by Google identity and Access Context Manager policy.
• VPC Service Controls - a perimeter around managed-service APIs (BigQuery, GCS, etc.) that prevents data exfiltration even by authenticated identities outside the perimeter. The most powerful and least-imitated control in any cloud for data-tier Zero Trust.
• Access Context Manager - defines access levels (device, location, identity attributes) consumed by IAP and VPC SC. The Policy Engine input layer.
• Workload Identity Federation + GKE Workload Identity - short-lived credentials for workloads, federate AWS / Azure / OIDC identities into Google IAM.
• Cloud Service Mesh (managed Istio) - east-west mTLS and L7 authorization.

Common thread: every cloud now ships a credible Zero Trust toolkit. None of them ships a complete Zero Trust program - the policy decisions, the cross-pillar telemetry, the device-posture coupling, the human workflows around exceptions, those are yours.

CISA Zero Trust Maturity Model

CISA's Zero Trust Maturity Model (v2.0, April 2023) is the most useful planning document in the public domain. Built for federal civilian agencies, it has been widely adopted in the private sector because it does what NIST 800-207 doesn't: it gives you a road map.

The five pillars

The three cross-cutting capabilities

• Visibility & Analytics - telemetry across all five pillars, fed to a SIEM / detection pipeline. The signal layer the Trust Algorithm needs.
• Automation & Orchestration - automated response to policy violations and posture changes. Where SOAR and CAEP-driven session revocation live.
• Governance - policy, exception management, audit, compliance mapping. The GRC layer for the program.

The four maturity stages

Each pillar moves through four stages independently. You will not be at the same stage in every pillar - most orgs are Advanced in Identity, Initial in Devices, and Traditional in Data simultaneously.

The model's practical value: it gives you per-pillar maturity scores that surface where to invest next. A pillar two stages behind the rest is usually the right next project.

DoD Zero Trust Reference Architecture & the seven pillars

The U.S. Department of Defense's Zero Trust Reference Architecture v2.0 (September 2022) - and the accompanying DoD Zero Trust Strategy - define their own model with seven pillars. CISA's five pillars are a simplification of this; the DoD version goes deeper.

1. User - identity, behavior, authentication.
2. Device - endpoint, IoT, mobile, posture.
3. Application & Workload - apps and the services they invoke.
4. Data - classification, tagging, encryption, rights management.
5. Network & Environment - segmentation, encryption, software-defined.
6. Automation & Orchestration - SOAR, dynamic policy.
7. Visibility & Analytics - telemetry, SIEM, behavioral analytics.

The DoD model lists 152 capabilities across the seven pillars and assigns each to a target year (target / advanced) for adoption across the department. If you work in defense, federal, or contracting, this is the document your customer is grading you against. If you don't, CISA's model is more accessible - but the DoD's enumeration of capabilities is useful as a checklist when you want to be sure you haven't missed something.

AWS, Azure, and GCP side-by-side

Native Zero Trust capabilities each cloud ships, reduced to a one-screen reference. Every cell here is one of multiple options; the table is for orientation, not procurement.

Reading the table: Azure has the most mature out-of-the-box Trust Algorithm via Conditional Access + Intune + CAE; GCP has the strongest data-tier control via VPC Service Controls and the cleanest BeyondCorp lineage; AWS gives you the richest set of primitives with the most assembly required. Multi-cloud Zero Trust is most easily anchored on a common identity layer (Okta, Entra ID, or similar) and an SPIFFE / workload-identity-federation backbone for workloads.

Maturity stages

A practitioner staging model for a Zero Trust program in a cloud-native org, mapped to CISA's stages but with concrete deliverables:

The skip-stage cost is real: a program that buys microsegmentation before fixing identity has built a fortress with the front door open. Sequence the pillars in order of risk reduction per dollar; Identity is almost always first because every other decision depends on it.

Common pitfalls

• "We bought ZTNA, so we have Zero Trust." The single most common mistake. ZTNA covers human-to-app north-south traffic. It does nothing for workload-to-workload, nothing for the data tier, and only as much for device posture as your vendor's integrations permit. Shipping ZTNA is one project; calling it the program is a category error.
• Treating Zero Trust as a one-time project. The CISA model has four maturity stages per pillar for a reason. A "Zero Trust initiative" with an end date is a transformation; what comes after is the operating model. Plan for the operating model from day one.
• Ignoring east-west. The north-south story - ZTNA replaces VPN - is easy to sell. The east-west story - microsegmentation, service-mesh authorization, workload identity - is where the actual attacker lateral movement happens. Skipping east-west because it's hard is the most expensive shortcut in the field.
• Vendor "Zero Trust solution" theater. Every vendor in the market now claims Zero Trust support. Ask which 800-207 components their product implements, what it expects from elsewhere, and whether it integrates with your existing IdP and EDR. Anyone who can't answer those questions cleanly is selling marketing.
• Authentication without authorization. Making every request authenticated is necessary; making every request authorized against a meaningful policy is the goal. mTLS everywhere without per-call authz is encrypted trust, not Zero Trust.
• Skipping the discovery phase before enforcing microsegmentation. Day-one deny-by-default policies break production. Run audit mode for 60-90 days, build the dependency map, ratchet to enforce. Plan for the cycle to repeat each time you add a major service.
• Policy without telemetry. Dynamic policy needs current signals. Without device posture, behavioral analytics, and threat-intel feeds, your Trust Algorithm is a static rule set with a fancy name. Build the telemetry pipeline alongside the policy engine, not after.
• Forgetting the human session lifecycle. Authentication at login plus a 12-hour token without continuous evaluation is not Zero Trust - it's session-aware-once trust. CAEP, short-lived tokens, and step-up auth on risk are what make the architecture continuous.
• Long-lived static credentials in workloads. Any hard-coded API key, any AWS access key embedded in a pod, any long-lived service-account JSON file is a single-credential-equals-network-position artifact from the pre-ZT era. Replace with workload identity. If a credential exists on disk for more than a few minutes, redesign.
• Compliance-first framing. Adopting Zero Trust to check a regulator's box (OMB M-22-09, DoD strategy) produces compliance-flavored architecture: heavy on documentation, light on actual posture change. The frameworks are useful as scaffolding; the security outcome is the goal. Map for the auditor, but optimize for the attacker.

Further reading

Foundational documents

• NIST SP 800-207 - Zero Trust Architecture
• CISA Zero Trust Maturity Model v2.0
• DoD Zero Trust Reference Architecture v2.0
• DoD Zero Trust Strategy
• OMB M-22-09 - Federal Zero Trust Strategy
• NSA - Embracing a Zero Trust Security Model
• NIST NCCoE Zero Trust Architecture project

Origin papers

• Google - BeyondCorp papers
• Google - BeyondCorp overview

Standards & protocols

• SPIFFE - Secure Production Identity Framework For Everyone
• SPIRE - SPIFFE Runtime Environment
• OpenID - Continuous Access Evaluation Profile (CAEP)
• OpenID Shared Signals Working Group
• FIDO Alliance - phishing-resistant authentication

Provider Zero Trust docs

• AWS - Zero Trust on AWS
• Microsoft - Zero Trust guidance
• Google Cloud - What is Zero Trust
• Google Cloud - BeyondCorp Enterprise

Related CSOH pages

• IAM & Identity - the foundational pillar every Zero Trust program starts with.
• Kubernetes - service mesh, NetworkPolicy, and workload-identity patterns.
• CSPM vs CNAPP - the posture pipeline behind the device-and-workload pillars.
• Cloud SOC - the detect/respond side that telemetry feeds.
• Landing zones - the architectural foundation a Zero Trust deployment sits on.
• GRC - how Zero Trust controls show up in your compliance program.
• Glossary - every term on this page, defined.

FAQ

What is Zero Trust in plain terms?

Zero Trust is an architectural approach in which no user, device, or workload is implicitly trusted because of where it sits on the network. Every request - human to app, app to app, service to service - is authenticated, authorized against a dynamic policy, and logged. The network is no longer the security boundary; identity, device posture, and per-request context are. It is a design pattern, not a product you buy.

Is Zero Trust the same as ZTNA?

No. ZTNA (Zero Trust Network Access) is one product category that applies Zero Trust principles to remote user access - typically an identity-aware proxy that replaces a VPN. Zero Trust Architecture is much broader and covers workload-to-workload communication, microsegmentation, device posture, data access, and the policy engine that ties it all together. Deploying ZTNA gets you one pillar; calling that "Zero Trust" is a category error vendors actively encourage.

What is NIST SP 800-207 and why does it matter?

NIST SP 800-207 (published August 2020) is the U.S. government's canonical definition of Zero Trust Architecture. It defines the seven tenets, the logical components (Policy Decision Point, Policy Enforcement Point, Policy Engine, Policy Administrator, Trust Algorithm), and three deployment variants (device-agent / gateway, enclave-gateway, resource portal). It is the vendor-neutral reference every serious zero-trust program maps to. Federal civilian agencies are required to align with it under OMB M-22-09.

Does Zero Trust replace the firewall?

Not entirely. Zero Trust shifts the primary enforcement point from the network perimeter to per-request, identity-aware decisions - but perimeter and egress controls still matter for defense in depth, blast-radius reduction, and regulatory compliance. The right framing: the firewall is no longer the trust boundary, but it is still a useful coarse-grained filter. East-west microsegmentation (VPC security groups, Calico, Cilium, Istio authorization policies) is the cloud-native evolution of the same idea, applied workload-to-workload.

How does Zero Trust work for workload-to-workload traffic?

Workload identity is the key. Each service gets a cryptographic identity - typically issued via SPIFFE/SPIRE, AWS IAM Roles for Service Accounts, Azure Workload Identity, or GCP Workload Identity Federation - and presents it on every call via mTLS or signed JWT. A policy engine (service mesh authorization policy, IAM, or a sidecar) decides whether identity A can call identity B for operation X. The IP address of the caller stops mattering. This is the workload-identity-as-the-perimeter pattern.

What is the CISA Zero Trust Maturity Model?

CISA's Zero Trust Maturity Model (v2.0, 2023) is a maturity framework for U.S. federal agencies but widely used in the private sector. It defines five pillars - Identity, Devices, Networks, Applications & Workloads, and Data - with three cross-cutting capabilities (Visibility & Analytics, Automation & Orchestration, Governance). Each pillar has four maturity stages: Traditional, Initial, Advanced, and Optimal. It is the most useful planning tool for sequencing a multi-year zero-trust program.

Can I claim Zero Trust by buying a single product?

No. Every credible standards body - NIST, CISA, NSA, DoD - explicitly says Zero Trust is a strategy and architecture, not a product. Vendors that brand their offering as "the Zero Trust solution" are selling one pillar (typically ZTNA or microsegmentation). A real zero-trust program touches identity, devices, networks, applications, workloads, and data, and it depends on the policy engine, telemetry pipeline, and operational discipline that no single product ships. Treat the marketing accordingly.