---
# === IDENTITY ===
id: software/security/zero-trust-architecture/2026
canonical_question: "What is Zero Trust Architecture and how to implement it?"
aliases:
  - "zero trust security model"
  - "ZTA implementation guide"
  - "never trust always verify architecture"
  - "NIST 800-207 zero trust"
  - "BeyondCorp zero trust"
  - "CISA zero trust maturity model"
  - "microsegmentation zero trust"
  - "zero trust network access ZTNA"
entity_type: software_reference
domain: software > security > Zero Trust Architecture
region: global
jurisdiction: global
temporal_scope: 2020-2026

# === VERIFICATION ===
last_verified: 2026-02-27
confidence: 0.93
version: 1.0
first_published: 2026-02-27

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: stable
  last_breaking_change: "CISA Zero Trust Maturity Model v2.0 (April 2023); NIST SP 800-207A cloud-native ZTA extension (August 2023); OMB M-22-09 federal mandate deadline September 2024"
  next_review: 2026-08-26
  change_sensitivity: medium

# === CONSTRAINTS ===
constraints:
  - "Zero Trust is a strategy, NOT a single product -- it requires coordinating identity, device, network, application, and data controls"
  - "NEVER rely solely on network location (VPN, firewall) for trust -- every request must be authenticated and authorized regardless of origin"
  - "mTLS certificates MUST be rotated automatically -- manual rotation leads to outages and security gaps"
  - "Legacy systems that cannot support modern authentication MUST be isolated in restricted network segments with proxy-based authentication translation"
  - "Policy decisions MUST use multiple signals (identity, device health, location, behavior) -- single-factor decisions are insufficient"
  - "Start with identity pillar before microsegmentation -- identity is the control plane for all other pillars"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "Need to prevent specific web vulnerabilities like XSS or CSRF"
    use_instead: "software/security/xss-prevention/2026"
  - condition: "Need API authentication patterns (OAuth2, JWT) without broader architecture"
    use_instead: "software/patterns/jwt-implementation/2026"
  - condition: "Need network firewall rules only, not full zero trust"
    use_instead: "software/devops/firewall-configuration/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: "environment"
    question: "What is your deployment environment?"
    type: choice
    options: ["Cloud-native (Kubernetes)", "Hybrid (on-prem + cloud)", "Fully on-premises", "Multi-cloud"]
  - key: "maturity_level"
    question: "What is your current zero trust maturity?"
    type: choice
    options: ["Traditional (perimeter-only)", "Initial (MFA deployed)", "Advanced (microsegmentation started)", "Optimal (continuous verification)"]
  - key: "primary_pillar"
    question: "Which zero trust pillar are you implementing first?"
    type: choice
    options: ["Identity", "Devices", "Network", "Applications", "Data", "Visibility & Analytics"]

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/software/security/zero-trust-architecture/2026"
suggested_citation: "Source: knowledgelib.io -- AI Knowledge Library (verified 2026-02-27)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to:
    - id: "software/security/xss-prevention/2026"
      label: "XSS Prevention Guide"
    - id: "software/patterns/jwt-implementation/2026"
      label: "JWT Implementation Guide"
  solves: []
  alternative_to: []
  often_confused_with:
    - id: "software/devops/vpn-configuration/2026"
      label: "VPN Configuration (perimeter security, not zero trust)"

# === SOURCES (7 authoritative sources) ===
# Types: official_docs, technical_blog, rfc_spec, academic_paper, community_resource, industry_report
# Reliability: high, moderate_high, moderate, moderate_low, low, authoritative
sources:
  - id: src1
    title: "NIST Special Publication 800-207: Zero Trust Architecture"
    author: NIST
    url: https://csrc.nist.gov/pubs/sp/800/207/final
    type: official_docs
    published: 2020-08-11
    reliability: authoritative
  - id: src2
    title: "CISA Zero Trust Maturity Model v2.0"
    author: CISA
    url: https://www.cisa.gov/zero-trust-maturity-model
    type: official_docs
    published: 2023-04-11
    reliability: authoritative
  - id: src3
    title: "Zero Trust Strategy & Architecture"
    author: Microsoft
    url: https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-overview
    type: official_docs
    published: 2025-02-27
    reliability: high
  - id: src4
    title: "BeyondCorp: A New Approach to Enterprise Security"
    author: Google
    url: https://cloud.google.com/beyondcorp
    type: official_docs
    published: 2014-12-01
    reliability: high
  - id: src5
    title: "Istio Security: mTLS and Authorization Policies"
    author: Istio Project
    url: https://istio.io/latest/docs/concepts/security/
    type: official_docs
    published: 2025-01-15
    reliability: high
  - id: src6
    title: "Zero Trust Architecture Cheat Sheet"
    author: OWASP Foundation
    url: https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html
    type: community_resource
    published: 2024-09-01
    reliability: authoritative
  - id: src7
    title: "Implementing a Zero Trust Architecture"
    author: NIST NCCoE
    url: https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
    type: official_docs
    published: 2024-06-01
    reliability: authoritative
---

# Zero Trust Architecture: Principles and Implementation Guide

## TL;DR

- **Bottom line**: Zero Trust Architecture (ZTA) replaces perimeter-based security with continuous verification of every user, device, and workload -- "never trust, always verify" -- using identity as the new control plane.
- **Key tool/command**: NIST SP 800-207 defines the reference architecture; implement via Policy Engine + Policy Administrator + Policy Enforcement Points (e.g., Istio mTLS + OPA + identity-aware proxy).
- **Watch out for**: Treating ZTA as a product purchase rather than an architectural strategy -- it requires coordinating identity, device, network, application, and data controls together.
- **Works with**: Any cloud provider (AWS, Azure, GCP), Kubernetes service meshes (Istio, Linkerd), identity providers (Entra ID, Okta, Google Workspace), and on-premises environments via ZTNA proxies.

## Constraints
<!-- Agents: read this section before recommending any action from this unit.
     These are hard constraints that must not be violated. -->

- Zero Trust is a strategy, NOT a single product -- it requires coordinating identity, device, network, application, and data controls
- NEVER rely solely on network location (VPN, firewall) for trust -- every request must be authenticated and authorized regardless of origin
- mTLS certificates MUST be rotated automatically -- manual rotation leads to outages and security gaps
- Legacy systems that cannot support modern authentication MUST be isolated in restricted network segments with proxy-based authentication translation
- Policy decisions MUST use multiple signals (identity, device health, location, behavior) -- single-factor decisions are insufficient
- Start with identity pillar before microsegmentation -- identity is the control plane for all other pillars

## Quick Reference

**NIST SP 800-207 Architecture Components:**

| Component | Role | Technology Options | Scaling Strategy |
|---|---|---|---|
| Policy Engine (PE) | Makes access/deny decisions based on multiple signals | OPA/Rego, Azure AD Conditional Access, Google BeyondCorp | Stateless, horizontally scalable |
| Policy Administrator (PA) | Translates PE decisions into enforcement actions | SPIFFE/SPIRE, Istio Pilot, cloud IAM | Federated across regions |
| Policy Enforcement Point (PEP) | Executes access decisions at runtime | Envoy proxy, Istio sidecar, API gateway, identity-aware proxy | Per-workload sidecar or per-node ambient |
| Identity Provider (IdP) | Authenticates users and issues tokens | Entra ID, Okta, Google Workspace, Keycloak | Multi-region with failover |
| Device Trust Agent | Assesses endpoint health and compliance | Microsoft Intune, Google Endpoint Verification, CrowdStrike | Agent per device |
| SIEM/Analytics | Collects signals, detects anomalies | Microsoft Sentinel, Splunk, Google Chronicle, Elastic | Tiered retention |

**CISA Zero Trust Maturity Model -- Five Pillars:**

| # | Pillar | Traditional | Initial | Advanced | Optimal |
|---|---|---|---|---|---|
| 1 | Identity | Passwords, limited MFA | MFA everywhere, centralized IdP | Risk-adaptive auth, FIDO2/phishing-resistant MFA | Continuous identity verification, just-in-time access |
| 2 | Devices | Managed devices only, basic AV | Device registration, health checks | Real-time compliance enforcement, auto-remediation | Continuous posture assessment, zero-standing access |
| 3 | Networks | Perimeter firewall, VPN | Basic segmentation, encrypted tunnels | Microsegmentation, encrypted east-west traffic | Software-defined perimeter, per-workload isolation |
| 4 | Applications | On-prem apps, VPN access | Identity-aware proxy for cloud apps | Per-app policies, API gateway with auth | Continuous app behavior analysis, runtime protection |
| 5 | Data | Classification labels, DLP at egress | Automated classification, encryption at rest | Dynamic access based on sensitivity, DRM | Real-time data-level access control, automated response |

**Microsoft Zero Trust Principles:**

| Principle | Description | Implementation |
|---|---|---|
| Verify explicitly | Authenticate and authorize using all available signals | MFA + device compliance + location + risk score |
| Least privilege access | JIT/JEA, risk-based adaptive policies | Conditional access, PIM, time-boxed admin |
| Assume breach | Minimize blast radius, segment access | Microsegmentation, end-to-end encryption, analytics |

## Decision Tree

```
START: What is your current security posture?
|-- Perimeter-only (VPN + firewall)?
|   |-- YES --> Phase 1: Deploy MFA everywhere + centralized identity (IdP)
|   +-- NO v
|-- MFA deployed but no microsegmentation?
|   |-- YES --> Phase 2: Implement device trust + network segmentation
|   +-- NO v
|-- Running Kubernetes workloads?
|   |-- YES --> Deploy Istio/Linkerd service mesh with STRICT mTLS + AuthorizationPolicy
|   +-- NO v
|-- Running traditional VMs/bare metal?
|   |-- YES --> Deploy identity-aware proxy (oauth2-proxy, Ory Oathkeeper) + host-based firewall rules
|   +-- NO v
|-- Need to protect legacy systems?
|   |-- YES --> Isolate in restricted zone + deploy authentication proxy + enhanced monitoring
|   +-- NO v
|-- Multi-cloud environment?
|   |-- YES --> Use SPIFFE/SPIRE for cross-cloud workload identity + Terraform for policy-as-code
|   +-- NO v
+-- DEFAULT --> Implement CISA maturity model: Identity > Devices > Networks > Apps > Data
```

## Step-by-Step Guide

### 1. Establish identity as the control plane

Deploy centralized identity with MFA as the foundation of all access decisions. NIST SP 800-207 defines identity governance as the first deployment model. [src1]

```bash
# Example: Configure Azure AD Conditional Access via CLI
az ad conditional-access policy create \
  --display-name "Require MFA for all users" \
  --conditions '{"applications":{"includeApplications":["All"]},"users":{"includeUsers":["All"]}}' \
  --grant-controls '{"builtInControls":["mfa"],"operator":"OR"}' \
  --state "enabled"
```

**Verify**: `az ad conditional-access policy list --query "[].{name:displayName, state:state}" -o table` --> shows policy as "enabled"

### 2. Deploy device trust and compliance

Register all devices and enforce health checks before granting access. Non-compliant devices must be blocked or given limited access. [src2]

```bash
# Example: Check device compliance status (Microsoft Graph API)
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?\$filter=complianceState eq 'noncompliant'" \
  | jq '.value[] | {deviceName, complianceState, lastSyncDateTime}'
```

**Verify**: Non-compliant devices should be listed and blocked from accessing sensitive resources.

### 3. Enable mTLS across service mesh

Deploy Istio with STRICT mTLS to encrypt and authenticate all east-west traffic between services. [src5]

```yaml
# istio-strict-mtls.yaml -- mesh-wide strict mTLS
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
# Workload-level authorization policy -- deny by default
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  action: DENY
  rules:
  - {}
---
# Allow specific service-to-service communication
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-server
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/v1/*"]
```

**Verify**: `istioctl analyze -n production` --> should show no configuration issues. `kubectl exec -it $POD -c istio-proxy -- openssl s_client -connect api-server:8080` --> should show mTLS certificate chain.

### 4. Implement identity-aware proxy for application access

Replace VPN with identity-aware proxy (IAP) that authenticates users before granting access to internal applications. [src4]

```yaml
# oauth2-proxy deployment (Kubernetes)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: oauth2-proxy
  namespace: auth
spec:
  replicas: 2
  selector:
    matchLabels:
      app: oauth2-proxy
  template:
    metadata:
      labels:
        app: oauth2-proxy
    spec:
      containers:
      - name: oauth2-proxy
        image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
        args:
        - --provider=oidc
        - --oidc-issuer-url=https://login.microsoftonline.com/TENANT_ID/v2.0
        - --client-id=$(CLIENT_ID)
        - --client-secret=$(CLIENT_SECRET)
        - --email-domain=*
        - --upstream=http://internal-app:8080
        - --cookie-secure=true
        - --cookie-httponly=true
        - --cookie-samesite=lax
        - --set-xauthrequest=true
        - --pass-access-token=true
        ports:
        - containerPort: 4180
        env:
        - name: CLIENT_ID
          valueFrom:
            secretKeyRef:
              name: oauth2-proxy-secrets
              key: client-id
        - name: CLIENT_SECRET
          valueFrom:
            secretKeyRef:
              name: oauth2-proxy-secrets
              key: client-secret
```

**Verify**: Access internal app URL --> should redirect to IdP login page. After authentication, `X-Auth-Request-User` header should contain authenticated identity.

### 5. Implement network microsegmentation with Terraform

Define network policies as code to enforce least-privilege network access between tiers. [src6]

```hcl
# terraform/network-segmentation.tf -- AWS VPC microsegmentation
resource "aws_security_group" "web_tier" {
  name_prefix = "zt-web-"
  vpc_id      = aws_vpc.main.id

  # Only allow inbound HTTPS from ALB
  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  # Only allow outbound to API tier on specific port
  egress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.api_tier.id]
  }

  tags = { "zero-trust" = "web-tier" }
}

resource "aws_security_group" "api_tier" {
  name_prefix = "zt-api-"
  vpc_id      = aws_vpc.main.id

  # Only accept from web tier
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web_tier.id]
  }

  # Only allow outbound to database tier
  egress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.db_tier.id]
  }

  tags = { "zero-trust" = "api-tier" }
}

resource "aws_security_group" "db_tier" {
  name_prefix = "zt-db-"
  vpc_id      = aws_vpc.main.id

  # Only accept from API tier
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.api_tier.id]
  }

  # No outbound internet access
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = []
  }

  tags = { "zero-trust" = "db-tier" }
}
```

**Verify**: `terraform plan` --> shows security group rules. `aws ec2 describe-security-groups --group-ids $SG_ID --query 'SecurityGroups[].IpPermissions'` --> confirms ingress restricted to expected sources only.

### 6. Deploy policy-as-code with Open Policy Agent

Define and enforce authorization policies centrally using OPA/Rego for consistent policy evaluation across all services. [src6]

```rego
# policy/authz.rego -- Zero Trust authorization policy
package authz

import rego.v1

default allow := false

# Allow if: authenticated user + compliant device + authorized role + within business hours
allow if {
    input.identity.authenticated == true
    input.device.compliant == true
    input.identity.roles[_] == required_role
    within_allowed_hours
}

required_role := role if {
    some grant in data.role_grants
    grant.resource == input.resource
    role := grant.role
}

within_allowed_hours if {
    hour := time.clock(time.now_ns())[0]
    hour >= 6
    hour <= 22
}

# Deny if device risk score exceeds threshold
deny if {
    input.device.risk_score > 7
}

# Deny if accessing sensitive data without step-up auth
deny if {
    input.resource.classification == "confidential"
    not input.identity.step_up_auth
}
```

**Verify**: `opa eval -d policy/ -i input.json 'data.authz.allow'` --> returns `true` only when all conditions are met.

## Code Examples

### Istio: Service Mesh mTLS with Authorization Policy

> Full script: [istio-service-mesh-mtls-with-authorization-policy.yml](scripts/istio-service-mesh-mtls-with-authorization-policy.yml) (40 lines)

```yaml
# Input:  Kubernetes cluster with Istio installed
# Output: Strict mTLS + deny-by-default + explicit allow rules
# 1. Enable strict mTLS mesh-wide
apiVersion: security.istio.io/v1
kind: PeerAuthentication
# ... (see full script)
```

### Python: SPIFFE Workload Identity Verification

```python
# Input:  SPIFFE trust bundle + peer certificate
# Output: Verified workload identity (SPIFFE ID)
# Requires: pyspiffe >= 0.7.0

from pyspiffe.spiffe_id.spiffe_id import SpiffeId
from pyspiffe.workloadapi.default_workload_api_client import DefaultWorkloadApiClient

def verify_workload_identity(expected_spiffe_id: str) -> bool:
    """Verify peer workload identity using SPIFFE Workload API."""
    client = DefaultWorkloadApiClient()

    # Fetch X.509 SVIDs from SPIRE agent
    svid_response = client.fetch_x509_svid()
    svid = svid_response.svid

    # Verify the SPIFFE ID matches expected identity
    actual_id = str(svid.spiffe_id)
    expected = SpiffeId.parse(expected_spiffe_id)

    if actual_id != str(expected):
        raise PermissionError(
            f"Workload identity mismatch: got {actual_id}, "
            f"expected {expected_spiffe_id}"
        )

    return True

# Usage: verify calling service before processing request
# verify_workload_identity("spiffe://example.org/ns/prod/sa/checkout")
```

### Terraform: AWS Network Microsegmentation

```hcl
# Input:  AWS VPC ID, subnet CIDRs
# Output: Microsegmented security groups with least-privilege rules

variable "vpc_id" { type = string }

resource "aws_security_group" "app" {
  name_prefix = "zt-app-"
  vpc_id      = var.vpc_id
  description = "Zero Trust: app tier - only accepts from LB"

  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.lb.id]
    description     = "Allow from load balancer only"
  }

  egress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    cidr_blocks     = ["0.0.0.0/0"]
    description     = "Allow HTTPS to external APIs"
  }
}
```

### Go: Zero Trust Middleware (JWT + Device Posture)

> Full script: [go-zero-trust-middleware-jwt-device-posture.go](scripts/go-zero-trust-middleware-jwt-device-posture.go) (33 lines)

```go
// Input:  HTTP request with Bearer token + X-Device-ID header
// Output: Authorized request or 403 Forbidden
package middleware
import (
    "context"
# ... (see full script)
```

## Anti-Patterns

### Wrong: VPN as zero trust

```
# BAD -- VPN grants broad network access after authentication
# Once inside the VPN, lateral movement is unrestricted
User --> VPN --> [Full network access to all internal resources]
```

### Correct: Per-resource access with identity verification

```
# GOOD -- Each resource requires independent authentication and authorization
User --> IdP (MFA) --> Policy Engine --> PEP (per-app proxy) --> [Single resource]
         ^                ^
         |                |
    Device health    Risk signals (location, behavior, time)
```

### Wrong: Flat network with perimeter-only security

```hcl
# BAD -- single security group allows all internal traffic
resource "aws_security_group" "internal" {
  ingress {
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]  # All internal IPs trusted
  }
}
```

### Correct: Microsegmented network with explicit allow rules

```hcl
# GOOD -- each tier only communicates with adjacent tiers
resource "aws_security_group" "api_tier" {
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web_tier.id]
  }
  # No blanket internal trust
}
```

### Wrong: Static API keys for service-to-service auth

```yaml
# BAD -- long-lived API key, no rotation, no identity verification
env:
  - name: API_KEY
    value: "sk-hardcoded-never-rotated-key-12345"
```

### Correct: mTLS with automatic certificate rotation

```yaml
# GOOD -- Istio manages certificates automatically (24h expiry, 12h rotation)
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
# Certificates provisioned by Istio CA, rotated automatically
```

### Wrong: Overly permissive authorization policy

```yaml
# BAD -- allows all authenticated traffic (no least privilege)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all-authenticated
spec:
  rules:
  - from:
    - source:
        principals: ["*"]
```

### Correct: Least-privilege authorization per service

```yaml
# GOOD -- specific source, method, and path restrictions
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-checkout-to-payment
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/prod/sa/checkout"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/charge"]
```

## Common Pitfalls

- **VPN-only zero trust**: Organizations deploy ZTNA but keep VPN as fallback with broad access, negating zero trust benefits. Fix: Decommission VPN after ZTNA migration; enforce per-app access policies. [src1]
- **Identity without device trust**: Deploying MFA without device compliance checks allows compromised devices with valid credentials. Fix: Combine identity verification with device health (patch level, disk encryption, EDR status). [src2]
- **Permissive-mode mTLS left indefinitely**: Istio's PERMISSIVE mode (accepts plaintext + mTLS) deployed as "temporary" but never upgraded to STRICT. Fix: Set migration deadline; use `istioctl analyze` to verify all workloads support mTLS before switching to STRICT. [src5]
- **Microsegmentation without visibility**: Implementing network segmentation without traffic flow visibility leads to broken applications. Fix: Deploy network flow logging (VPC Flow Logs, Cilium Hubble) first, analyze dependencies, then segment. [src6]
- **Legacy system carve-outs that expand**: Exceptions for legacy systems grow over time until they dominate the network. Fix: Isolate legacy systems in restricted zones with proxy authentication; set decommission timelines. [src7]
- **Tool sprawl across pillars**: Buying separate point solutions for each ZTA pillar creates integration gaps and operational complexity. Fix: Choose platforms that cover multiple pillars; use SPIFFE/SPIRE for cross-platform workload identity. [src6]
- **Ignoring data pillar**: Securing identity/network/devices but leaving data classification and access controls unimplemented. Fix: Deploy automated data classification + DLP policies; encrypt sensitive data with key management. [src2]
- **Big-bang deployment**: Attempting to implement ZTA across entire organization simultaneously. Fix: Start with high-value assets (crown jewels), prove the model, expand incrementally per CISA maturity model stages. [src2]

## Diagnostic Commands

```bash
# Check Istio mTLS status across all namespaces
istioctl x authz check <pod-name> -n <namespace>

# Verify mTLS is active between services
istioctl proxy-config secret <pod-name> -n <namespace> | head -20

# Check PeerAuthentication policies
kubectl get peerauthentications --all-namespaces

# Check AuthorizationPolicy enforcement
kubectl get authorizationpolicies --all-namespaces -o wide

# Verify SPIFFE workload identity
spire-agent api fetch x509 -socketPath /run/spire/sockets/agent.sock

# Test network segmentation (should fail if properly segmented)
kubectl exec -n web-tier web-pod -- curl -s -o /dev/null -w "%{http_code}" http://db-service.db-tier:5432

# Check AWS security group rules for microsegmentation
aws ec2 describe-security-groups --group-ids $SG_ID \
  --query 'SecurityGroups[].{Ingress:IpPermissions,Egress:IpPermissionsEgress}'

# Verify OPA policy decisions
opa eval -d policy/ -i request.json 'data.authz.allow'

# Check Azure Conditional Access policy status
az ad conditional-access policy list --query "[].{name:displayName, state:state}" -o table

# Monitor mTLS certificate expiry in Istio
istioctl proxy-config secret <pod> -o json | jq '.dynamicActiveSecrets[].secret.tlsCertificate.certificateChain.inlineBytes' | base64 -d | openssl x509 -noout -dates
```

## Version History & Compatibility

| Standard/Framework | Version | Status | Key Feature |
|---|---|---|---|
| NIST SP 800-207 | 1.0 | Current (Aug 2020) | Core ZTA reference architecture, 3 deployment models |
| NIST SP 800-207A | 1.0 | Current (Aug 2023) | ZTA for cloud-native apps, multi-cloud extension |
| CISA ZTMM | v2.0 | Current (Apr 2023) | 5 pillars, 4 maturity stages (Traditional/Initial/Advanced/Optimal) |
| OMB M-22-09 | 1.0 | Active mandate | US federal ZTA mandate, September 2024 deadline |
| Istio | 1.24.x | Current | Ambient mesh (sidecar-less mTLS), STRICT mode |
| SPIFFE/SPIRE | 1.9.x | Current | Cross-platform workload identity, X.509 SVIDs |
| OPA | 0.68.x | Current | Rego v1 syntax, Wasm compilation |
| Google BeyondCorp | Enterprise | GA | Identity-Aware Proxy, Access Context Manager |

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Multi-cloud or hybrid environment with distributed workloads | Single isolated application with no network connectivity | Standard application security controls |
| Remote/hybrid workforce accessing internal resources | Fully air-gapped network with no external access | Network segmentation + physical security |
| Compliance requirements mandate ZTA (NIST, CISA, OMB M-22-09) | Small team (<10) with single SaaS app and SSO | SSO + MFA is sufficient |
| Post-breach remediation requiring reduced blast radius | Proof-of-concept or prototype with no sensitive data | Basic authentication only |
| Kubernetes/microservices with east-west traffic patterns | Monolithic application with single database | Application-level auth + WAF |

## Important Caveats

- Only 8% of organizations have implemented Zero Trust across their entire enterprise (2025) -- most are implementing in specific areas (49%) or still planning (34%)
- Zero Trust does NOT mean zero risk -- it reduces attack surface and blast radius but cannot prevent all breaches
- Legacy systems (46% of respondents cite as top barrier) may require proxy wrappers or restricted zone isolation -- not all systems can be modernized
- mTLS adds latency (~1-3ms per hop) and requires certificate management infrastructure -- plan for the operational overhead
- CISA ZTMM is designed for US federal agencies but the framework applies to any organization; maturity stages help prioritize investments
- Istio ambient mesh (sidecar-less mTLS) is production-ready since Istio 1.22 but still evolving -- evaluate for new deployments, keep sidecar mode for existing

## Related Units
<!-- Generated from related_kos frontmatter -->

- [XSS Prevention Guide](/software/security/xss-prevention/2026)
- [JWT Implementation Guide](/software/patterns/jwt-implementation/2026)
- [VPN Configuration](/software/devops/vpn-configuration/2026)