Zero Trust Architecture: Never Trust, Always Verify

Introduction

Traditional perimeter-based security assumes everything inside the network is trustworthy. This model has become obsolete with cloud computing, remote work, and sophisticated supply-chain attacks. The 2024 average breach cost reached $4.88M (IBM), and perimeter-focused defenses failed to stop lateral movement in 70% of cases.

Zero Trust Architecture (ZTA) operates on a simple principle: never trust, always verify — regardless of whether access requests come from inside or outside the network. By 2026, 81% of organizations are actively transitioning to Zero Trust frameworks, and the global ZTA market is projected at $22.58B (GSDC). The US Department of Defense requested $14.5B for cybersecurity in FY2025, with $977M specifically allocated to Zero Trust adoption.

This article covers the NIST SP 800-207 framework, core implementation patterns, identity-centric access control, network micro-segmentation, continuous verification, and the emerging trends shaping ZTA through 2027.

Zero Trust Fundamentals

Core Principles

NIST SP 800-207 defines Zero Trust through seven fundamental tenets that every implementation must address:

1. All data sources and computing services are considered resources. Personal devices, SaaS platforms, IoT sensors — anything that can send or receive data is a resource requiring protection.

2. All communication is secured regardless of network location. Packets traversing the corporate data center get the same encryption and authentication as traffic from a public coffee shop — network location confers no trust.

3. Access to individual enterprise resources is granted on a per-session basis. No persistent “authenticated” state. Each request re-evaluates trust based on current context.

4. Access is determined by dynamic policy — identity, device, behavior, and risk. Static role-based checks alone are insufficient. The policy engine must assess device posture, geolocation, time, behavioral baselines, and threat intelligence feeds.

5. The enterprise monitors and measures the integrity of all owned and associated assets. Continuous device posture assessment feeds into every access decision. A device that falls out of compliance mid-session triggers automatic access revocation.

6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Re-authentication occurs on time expiry, new resource requests, behavioral anomalies, or any change in context.

7. The enterprise collects information on the state of assets, network infrastructure, and communications. Logs, telemetry, and real-time analytics are essential for detecting anomalies and tuning policy.

Traditional vs. Zero Trust

The NIST SP 800-207 Reference Architecture

NIST SP 800-207 (published August 2020) remains the foundational standard for ZTA. It defines three core logical components:

flowchart LR
    subgraph Policy["Policy Engine"]
        PDP[Policy Decision Point]
        PA[Policy Administrator]
    end

    subgraph Enforcement["Enforcement"]
        PEP[Policy Enforcement Point]
    end

    Subject[Subject\nUser / Device / Service] -->|Access Request| PEP
    PEP -->|Policy Query| PDP
    PDP -->|Decision| PA
    PA -->|Enforce| PEP
    PEP -->|Grant / Deny| Resource[Resource\nApp / Data / Service]

    CDM[Continuous\nDiagnostics] --> PDP
    TI[Threat\nIntelligence] --> PDP
    ID[Identity\nManagement] --> PDP

The Policy Decision Point (PDP) evaluates every access request against dynamic policy. The Policy Administrator (PA) generates session-specific credentials. The Policy Enforcement Point (PEP) sits in front of each resource, granting or blocking access based on the PDP’s decision.

In June 2025, NIST published SP 1800-35: Implementing a Zero Trust Architecture, which provides 19 example implementations built with commercial off-the-shelf technologies. These examples cover real-world scenarios including multi-cloud environments, branch offices, and remote workers connecting from untrusted networks like coffee shop WiFi.

Identity and Access Management

Identity is the new perimeter. In a Zero Trust model, every access decision starts with verifying who — or what — is making the request.

Identity Provider Integration

# OAuth 2.0 / OIDC provider configuration
issuer: https://auth.company.com
jwks_uri: https://auth.company.com/.well-known/jwks.json
authorization_endpoint: https://auth.company.com/authorize
token_endpoint: https://auth.company.com/oauth/token

# Token validation rules
validation:
  claims:
    - sub        # User identifier
    - tenant_id  # Multi-tenant isolation
    - roles      # RBAC roles
  audience: api.company.com

Strong Authentication with Risk Assessment

class AuthenticationService {
  async authenticate(credentials: Credentials): Promise<AccessToken> {
    const user = await this.identityProvider.lookup(credentials.email);

    // Verify password or passkey
    const primaryValid = await this.verifyPrimaryFactor(credentials);

    // Evaluate if MFA is required based on context
    const risk = await this.assessRisk({
      user: user.id,
      ip: credentials.ip,
      deviceId: credentials.deviceId,
      location: credentials.geo,
      time: new Date(),
      recentFailures: user.recentFailedAttempts
    });

    if (risk.requiresMfa) {
      const mfaValid = await this.verifyMFA(user, credentials.mfaCode);
      if (!mfaValid) {
        await this.auditLog.failedMfa(user.id, credentials.ip);
        throw new AuthenticationError("MFA required but verification failed");
      }
    }

    // Issue a short-lived token scoped to the specific resource being accessed
    return this.tokenService.issue({
      sub: user.id,
      scope: credentials.requestedScope,
      exp: "5m",           // Short expiry forces re-verification
      deviceTrust: risk.deviceScore,
      sessionId: crypto.randomUUID()
    });
  }
}

Attribute-Based Access Control (ABAC)

RBAC assigns permissions based on job function. ABAC goes further by evaluating attributes of the user, resource, environment, and context at request time.

{
  "policy": {
    "name": "engineering-document-access",
    "rules": [
      {
        "effect": "permit",
        "actions": ["read", "list"],
        "conditions": {
          "all": [
            {"user.department": "engineering"},
            {"resource.classification": {"lte": "confidential"}},
            {"device.postureScore": {"gte": 70}},
            {"time.withinBusinessHours": true}
          ]
        }
      },
      {
        "effect": "deny",
        "actions": ["delete", "export"],
        "conditions": {
          "any": [
            {"user.clearance": {"lt": "level3"}},
            {"network.isManaged": false}
          ]
        }
      }
    ]
  }
}

Network Security

Micro-Segmentation with Kubernetes NetworkPolicy

Divide the network into isolated segments so a compromised workload cannot reach other workloads laterally.

# Only API pods can reach the database, and only on port 5432
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-database-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      component: database
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              component: api
      ports:
        - protocol: TCP
          port: 5432
  egress:
    - to:
        - podSelector:
            matchLabels:
              component: backup-service
      ports:
        - protocol: TCP
          port: 443

Service Mesh Authorization with Istio

A service mesh provides identity-based authorization at the application layer, decoupled from the network.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
    # Only the ingress gateway can reach payment endpoints
    - from:
        - source:
            principals:
              - cluster.local/ns/istio-system/sa/istio-ingressgateway
      to:
        - operations:
            methods: ["POST"]
            paths: ["/api/v1/charge"]
    # Order service can query payment status
    - from:
        - source:
            principals:
              - cluster.local/ns/production/sa/order-service
      to:
        - operations:
            methods: ["GET"]
            paths: ["/api/v1/status/*"]
  action: ALLOW

Mutual TLS for All Service Communication

Every service-to-service communication must be encrypted and mutually authenticated.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api-service-mtls
spec:
  host: "*.production.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Device Trust and Posture Assessment

Device Trust Scoring

Every device connecting to enterprise resources must be evaluated for compliance. A trust score aggregates multiple factors into a single decision metric.

interface DeviceTrustScore {
  score: number;
  factors: string[];
  lastAssessed: Date;
}

class DeviceTrustService {
  async evaluate(deviceId: string): Promise<DeviceTrustScore> {
    const device = await this.deviceRegistry.get(deviceId);
    if (!device.registered) {
      return { score: 0, factors: ["unregistered"], lastAssessed: new Date() };
    }

    let score = 0;
    const factors: string[] = [];

    // OS is patched within the last 30 days
    if (this.isOSUpToDate(device.osVersion, device.lastPatchDate)) {
      score += 25;
      factors.push("os-patched");
    }

    // Full-disk encryption enabled
    if (device.encryptionEnabled) {
      score += 25;
      factors.push("encrypted");
    }

    // Enrolled in MDM with compliance profile
    if (device.mdmEnrolled) {
      score += 20;
      factors.push("mdm-enrolled");
    }

    // EDR agent running and reporting
    if (device.edrActive) {
      score += 20;
      factors.push("edr-active");
    }

    // No recent security incidents
    if (!device.recentCompromise) {
      score += 10;
      factors.push("clean-record");
    }

    return { score, factors, lastAssessed: new Date() };
  }

  async checkAccess(userId: string, resource: string): Promise<boolean> {
    const device = await this.deviceRegistry.findByUser(userId);
    const trust = await this.evaluate(device.id);
    const sensitivity = await this.resourceClassify(resource);
    return trust.score >= sensitivity.minimumTrustScore;
  }
}

Trust thresholds determine access levels:

Continuous Device Monitoring

apiVersion: v1
kind: ConfigMap
metadata:
  name: device-monitor-policy
data:
  policy.yaml: |
    monitoring:
      interval: 5m
      checks:
        - type: os_version
          minVersion: "15.0"
        - type: encryption
          required: true
        - type: jailbreak_detection
          expectedValue: false
        - type: screen_lock
          maxTimeout: 5m
        - type: edr_heartbeat
          maxAge: 60s
      actions:
        - trigger: score_below_threshold
          action: revoke_access
        - trigger: jailbreak_detected
          action: quarantine_device
        - trigger: encryption_disabled
          action: notify_admin

Data Protection

Encryption Everywhere

Data must be encrypted at rest and in transit. TLS 1.3 is the minimum acceptable protocol; mTLS ensures mutual authentication.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  annotations:
    encryption.kubernetes.io/key-id: kms-key-001
type: Opaque
data:
  username: <encrypted>
  password: <encrypted>

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: universal-encryption
spec:
  host: "*.company.com"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
      minProtocolVersion: TLSV1_3

Data Classification and Handling

enum Classification {
  PUBLIC = "public",
  INTERNAL = "internal",
  CONFIDENTIAL = "confidential",
  RESTRICTED = "restricted"
}

interface DataHandler {
  classify(data: any): Classification {
    if (this.containsPII(data)) return Classification.RESTRICTED;
    if (this.containsPCI(data)) return Classification.RESTRICTED;
    if (this.containsBusinessSecret(data)) return Classification.CONFIDENTIAL;
    return Classification.INTERNAL;
  }

  async enforce(data: any): Promise<void> {
    const level = this.classify(data);
    switch (level) {
      case Classification.RESTRICTED:
        await this.encrypt(data);
        await this.dlpScan(data);
        await this.auditLog("restricted_access", data.id);
        break;
      case Classification.CONFIDENTIAL:
        await this.encrypt(data);
        await this.auditLog("confidential_access", data.id);
        break;
    }
  }
}

Adaptive Access and Continuous Verification

Static access decisions — checked once at login — are insufficient. Zero Trust requires continuous re-evaluation of trust for every request.

Signal-Based Access Flow

sequenceDiagram
    actor U as User
    participant P as PEP (Proxy)
    participant PDP as Policy Decision Point
    participant ID as Identity Provider
    participant DEV as Device Registry
    participant BEH as Behavioral Analytics

    U->>P: Request /api/v1/orders
    P->>PDP: Evaluate access
    PDP->>ID: Verify identity token
    PDP->>DEV: Check device posture score
    PDP->>BEH: Score current behavior vs baseline
    BEH-->>PDP: Risk score: 12 (low)
    DEV-->>PDP: Trust score: 85
    PDP-->>P: Allow (token scoped to orders:read)
    P->>U: Response + new session token (exp: 5min)

    Note over U,BEH: 3 minutes later — user requests /api/v1/admin/users
    U->>P: Request /api/v1/admin/users
    P->>PDP: Re-evaluate
    PDP-->>P: Deny (insufficient scope, step-up required)
    P->>U: 403 + MFA challenge required

Session Verifier Implementation

class SessionVerifier {
  private readonly reverifyIntervalMs = 300_000; // 5 minutes
  private readonly anomalyLockoutMs = 60_000;     // 1 minute

  async verify(sessionId: string): Promise<SessionStatus> {
    const session = await this.sessionStore.get(sessionId);

    // Enforce absolute session lifetime
    if (Date.now() - session.createdAt > session.maxAgeMs) {
      await this.revoke(sessionId);
      return { valid: false, reason: "session_expired" };
    }

    // Re-verify periodically
    if (Date.now() - session.lastVerified > this.reverifyIntervalMs) {
      const reAuth = await this.identityProvider.reverify(session.userId);
      if (!reAuth.success) {
        await this.revoke(sessionId);
        return { valid: false, reason: "reverification_failed" };
      }
      session.lastVerified = Date.now();
    }

    // Detect behavioral anomalies
    const anomaly = await this.anomalyDetector.check(session);
    if (anomaly.detected) {
      await this.flagSession(sessionId, anomaly);
      session.requiresStepUp = true;
      return { valid: true, stepUp: true, reason: anomaly.description };
    }

    return { valid: true, stepUp: false };
  }
}

ZTNA: Zero Trust Network Access

ZTNA replaces traditional VPNs by connecting users directly to specific applications — never to the network. The market for ZTNA grew 87% year-over-year between 2021 and 2022, with sustained 51% growth projected through 2024.

VPN Model: User → VPN Gateway → Entire Network (over-privileged)
ZTNA Model: User → Identity Verification → App-Specific Tunnel (least privilege)

Key ZTNA characteristics:

• App-centric: Users connect to applications, not subnets
• Default deny: No access until explicitly authorized
• Outbound-only: No inbound ports, no exposed attack surface
• Continuous verification: Trust re-evaluated per request, not per session

Implementation Roadmap

Zero Trust is a journey, not a product. NIST recommends a phased approach to minimize disruption.

Phase 1: Foundation (Months 1-3)

1. Identify protect surfaces (crown jewel data, critical applications)
2. Map transaction flows (who talks to whom, over what protocols)
3. Architect a Zero Trust network (segment by protect surface)
4. Create the Zero Trust policy (rules for who can access what, when)

Key activities:

• Inventory all identities, devices, services, and data stores
• Classify data sensitivity and map access patterns
• Establish an identity provider with MFA enforcement
• Deploy endpoint detection and response (EDR) on all managed devices

Phase 2: Pilot (Months 4-6)

Select one application or workload for the initial implementation:

# Pilot scope: one critical application
pilot:
  application: "customer-portal"
  users: "engineering-team"
  controls:
    - identity: "OIDC + MFA"
    - device: "posture check + MDM enrollment"
    - network: "app-specific tunnel (ZTNA)"
    - monitoring: "full session logging + anomaly detection"
  success_criteria:
    - mean_auth_time < 2s
    - user_friction_score < 3/10
    - zero_security_incidents

Phase 3: Enterprise Rollout (Months 7-18)

Expand incrementally across the organization:

Phase 4: Continuous Improvement (Ongoing)

• Automate policy enforcement through CI/CD pipelines
• Integrate threat intelligence feeds for dynamic risk scoring
• Conduct quarterly access reviews and policy audits
• Track maturity against the CISA Zero Trust Maturity Model

Emerging Trends: AI-Driven Trust and Beyond

AI-Driven Adaptive Trust

Static trust thresholds are giving way to AI-powered behavioral baselines. The policy engine learns normal patterns per user and adapts access decisions in real time.

User: Sarah (Engineering Manager)
Baseline: 9am-6pm, office network, company laptop, office location
Current: 2am, unknown ISP, personal device, 500km from office

Traditional ZT: Block or force MFA
AI-Driven ZT:
  - Allow read-only access to email and calendar
  - Block file downloads and admin panels
  - Require re-auth every 2 minutes
  - Alert SOC for live monitoring
  - Auto-restore full access when context normalizes

Quantum-Resistant Cryptography

Quantum computing threatens current asymmetric encryption (RSA, ECDSA, Curve25519). NIST has standardized CRYSTALS-Kyber (key encapsulation) and CRYSTALS-Dilithium (digital signatures) as post-quantum cryptographic algorithms. Zero Trust implementations should begin evaluating hybrid certificate schemes that combine current and quantum-resistant algorithms.

Zero Trust for Operational Technology

IT/OT convergence means manufacturing floors, power grids, and medical devices now face internet-based threats. The Purdue model’s implicit trust between OT layers is being replaced by identity-based micro-segmentation for industrial control systems.

CISA Zero Trust Maturity Model

CISA’s ZTMM defines five pillars (Identity, Devices, Networks, Applications/Workloads, Data) across three maturity stages:

1. Traditional: Manual, mostly perimeter-based
2. Advanced: Automated, some cross-pillar visibility
3. Optimal: Fully automated, real-time, cross-pillar orchestration

For each pillar, the maturity model describes the capabilities required at each stage. This provides a concrete measurement framework for organizations tracking their Zero Trust progress.

NSA Zero Trust Implementation Guidelines (January 2026)

The NSA released comprehensive Zero Trust implementation guidelines in January 2026, providing a phased activity framework organized across the CISA maturity pillars. Key recommendations include:

• Deny by default: All access decisions default to deny unless explicitly granted by policy
• Periodic re-authentication: Sessions require re-verification at defined intervals, not just on initial login
• Non-Person Entity (NPE) security: Service accounts, bots, and automated processes must follow the same ZT rules as human users
• Enterprise PKI integration: All device and service identities anchored to a Public Key Infrastructure
• Data tagging and classification: Manual and automated data classification feeds into access policies

The NSA framework provides detailed activity checklists for each maturity stage, making it one of the most actionable implementation guides available.

Zero Trust for CI/CD and Software Supply Chain

The software supply chain is now a primary attack surface. In March 2026, the TeamPCP campaign (tracked as UNC6780) compromised five major open-source projects in twelve days — starting with security scanners and cascading through PyPI tokens to backdoor widely used libraries. The 2026 ReversingLabs supply chain report found open-source malware up 73% year-over-year, with attackers increasingly targeting CI/CD tooling and developer credentials.

NIST SP 800-204D explicitly recommends Zero Trust principles for CI/CD pipelines. Zero Trust applies to four domains within the software supply chain:

1. Developer Workstations

Developer machines are high-value targets. Compromised IDE extensions (72 malicious VS Code extensions with 9 million installs were found in 2025-2026) can exfiltrate credentials before code ever reaches a pipeline.

ZT Control: Developer workstations must pass device posture checks
before being allowed to commit code or access CI/CD systems.

- Hardware-backed credentials (TPM, YubiKey) for code signing
- EDR on all development machines
- Just-in-time access to production CI/CD systems

2. CI/CD Pipelines

Build pipelines must treat every step as untrusted — artifacts pulled from registries, environment variables, and even the CI runner itself.

# Policy-as-code for CI/CD using Open Policy Agent (OPA)
apiVersion: v1
kind: ConfigMap
metadata:
  name: cicd-policy
data:
  policy.rego: |
    package cicd.zero_trust

    # Every build must use signed base images
    deny[msg] {
      input.image.signature != "verified"
      msg = sprintf("Image %v has no valid signature", [input.image.name])
    }

    # SAST/SCA scans must pass before deployment
    deny[msg] {
      input.stage == "deploy"
      not input.scan_results.sast.passed
      msg = "Deploy blocked: SAST scan did not pass"
    }

    # Secrets must come from a vault, not environment variables
    deny[msg] {
      input.secrets.source == "env_var"
      msg = "Secrets must be fetched from vault, not environment variables"
    }

# Enforce SLSA compliance in CI/CD
# Verify artifact provenance before deployment
slsa-verifier verify-artifact \
    --provenance-path build.provenance \
    --source-uri github.com/org/repo \
    --source-tag v1.2.3 \
    dist/artifact.bin

3. Artifact Repositories

Package registries (npm, PyPI, Docker Hub) and internal artifact stores must verify integrity before supplying artifacts to builds.

• Sign all artifacts with Sigstore/Cosign
• Verify SBOMs (Software Bill of Materials) before deployment
• Scan every dependency for known vulnerabilities before inclusion
• Use attestations (SLSA provenance) to verify where and how each artifact was built

4. Deployment and Runtime

Production workloads must validate identity and integrity continuously:

# Verify deployment artifact integrity in Kubernetes
apiVersion: cosign.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: enforce-signed-images
spec:
  images:
    - glob: "registry.company.com/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: ".*"

SASE and SSE Convergence

Secure Access Service Edge (SASE) converges networking (SD-WAN) and security (SSE) into a single cloud-delivered service. SSE combines four security functions: Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and Firewall-as-a-Service (FWaaS).

The Zero Trust market is converging with SASE because both are identity-driven, cloud-delivered, and policy-centric. By 2026, most major ZTNA vendors also offer SASE platforms.

┌─────────────────────────────────────────────────────┐
│                   SASE Architecture                  │
├─────────────────────────────────────────────────────┤
│  ┌─────────────────┐  ┌──────────────────────────┐  │
│  │    SD-WAN       │  │  Security Service Edge    │  │
│  │  (Networking)   │  │        (SSE)              │  │
│  │                 │  │  ┌────────────────────┐   │  │
│  │  - WAN          │  │  │  ZTNA              │   │  │
│  │  optimization   │  │  │  SWG               │   │  │
│  │  - Last-mile    │  │  │  CASB              │   │  │
│  │    connectivity │  │  │  FWaaS             │   │  │
│  │  - Traffic      │  │  └────────────────────┘   │  │
│  │    steering     │  │                            │  │
│  └─────────────────┘  └──────────────────────────┘  │
│                                                     │
│  All policy: Cloud-delivered, identity-based,        │
│  centrally managed, globally distributed            │
└─────────────────────────────────────────────────────┘

Key benefits of SASE for Zero Trust:

• Single-pass inspection: Threat detection, DLP, URL filtering, and access control in one flow
• Unified policy: Identity-driven rules apply consistently regardless of user location
• Edge enforcement: Security inspection happens at the closest cloud edge, not a central data center
• Outbound-only architecture: No inbound ports needed for remote access

Compliance Mapping

Zero Trust Architecture maps directly to major compliance frameworks. Implementing ZTA controls satisfies requirements across multiple standards simultaneously.

For organizations subject to CMMC (Cybersecurity Maturity Model Certification for defense contractors), ZTA controls map to NIST SP 800-171 requirements across access control, audit and accountability, and system and communications protection families. CMMC Level 2 and Level 3 requirements align naturally with ZTA capabilities — identity-first access, behavioral analytics, and micro-segmentation.

The NSA’s January 2026 Zero Trust Implementation Guideline Primer provides the most direct mapping between ZTA activities and federal compliance frameworks, including specific control identifiers from NIST SP 800-53.

Incident Response in a Zero Trust Model

Zero Trust fundamentally changes incident response. Instead of relying on perimeter logs and VPN access records, responders have rich identity-aware telemetry.

Advantages for Incident Response

• Explicit deny logging: Every denied access attempt is logged with identity, device, and context — revealing attacker reconnaissance
• Micro-segmentation containment: Compromised workloads cannot pivot laterally without hitting deny policies, which generate alerts
• Session revocation: Identities can be instantly revoked across all resources — no waiting for VPN termination
• Behavioral baselines: Anomalous access patterns are detected at the PDP before damage occurs

Incident Response Workflow

1. Detect: PDP flags anomalous behavior (e.g., service account accessing
   resources at 3am from an unknown IP)

2. Verify: SOC reviews session logs with full identity, device posture,
   and risk score context

3. Contain: Policy engine revokes the identity's tokens across all sessions.
   Micro-segmentation prevents lateral movement to adjacent resources

4. Investigate: All access attempts (including blocked ones) are logged
   with identity context, providing a complete forensic trail

5. Recover: On resolution, issue new credentials with stepped-up
   authentication and reduced session lifetime

Forensics in a Zero Trust Environment

-- Query PEP logs for a compromised identity
SELECT
    timestamp,
    action,           -- 'allow' or 'deny'
    identity,
    target_resource,
    risk_score,
    device_trust_score,
    geolocation,
    session_id
FROM pep_audit_log
WHERE identity = 'svc-build-agent'
  AND timestamp >= '2026-05-01'
ORDER BY timestamp;

Common Pitfalls

1. Technology-First without Architecture

Buying ZTNA tools, SASE gateways, and micro-segmentation platforms without first mapping protect surfaces and transaction flows leads to tool sprawl, not security.

Fix: Start with the NIST SP 800-207 framework. Identify protect surfaces first, then select technologies that enforce the policy.

2. Neglecting User Experience

Excessive MFA prompts, slow authentication, and frequent session drops drive users to find workarounds — shadow IT, credential sharing, or disabling security controls.

Fix: Measure user friction scores during the pilot phase. Use step-up authentication only when contextually warranted.

3. Ignoring Legacy Systems

Many organizations have systems that cannot support modern authentication (mainframes, SCADA, COTS appliances). Leaving them outside Zero Trust creates blind spots attackers will exploit.

Fix: Place legacy systems behind a ZTNA gateway or application proxy that terminates authentication and forwards authorized traffic. Air-gap where proxying is impossible.

4. Insufficient Telemetry

Without comprehensive logging, you cannot detect anomalies, tune policies, or respond to incidents. Many Zero Trust deployments under-invest in the data pipeline.

Fix: Ingest logs from identity providers, ZTNA gateways, endpoints, and cloud APIs into a SIEM. Set up dashboards for the seven NIST tenets and alert on deviations.

5. Overlooking Third-Party Access

Supply chain access remains a primary attack vector (see SolarWinds, MOVEit, 2023-2025 campaigns). Vendor access must follow the same Zero Trust rules.

Fix: Just-in-time (JIT) access for vendors, time-bound credentials, session recording, and revocation on contract termination.

Best Practices

1. Start with Identity

Identity is the control plane of Zero Trust. Implement strong identity and access management (IAM) before any other pillar:

• Phishing-resistant MFA (FIDO2/WebAuthn, passkeys) for all users
• Just-in-time (JIT) and just-enough-access (JEA) for privileged roles
• Automated provisioning and deprovisioning via SCIM

2. Encrypt Everything

• TLS 1.3 minimum for all in-transit data
• mTLS for service-to-service communication
• Encrypt data at rest using envelope encryption with automated key rotation

3. Micro-Segment by Sensitivity

• Segment workloads by data classification and blast radius
• Default deny egress between segments
• Monitor and log all east-west traffic

4. Verify Continuously

• Re-authenticate on context changes (new IP, new location, new device)
• Use behavioral analytics to detect anomalous access patterns
• Automatically revoke access when trust score drops below threshold

5. Automate Response

• Integrate policy enforcement with SIEM/SOAR
• Automate containment of compromised identities and devices
• Schedule quarterly policy reviews and pen tests

Resources

• NIST SP 800-207: Zero Trust Architecture — Foundational ZTA framework
• NIST SP 1800-35: Implementing a Zero Trust Architecture — 19 example implementations (June 2025)
• CISA Zero Trust Maturity Model — Government maturity framework
• NSA Zero Trust Implementation Guideline Primer (January 2026) — NSA phased implementation guidelines
• Google BeyondCorp Whitepaper — Foundational zero trust implementation at scale
• NIST SP 800-204D: Software Supply Chain Security in DevSecOps CI/CD Pipelines — ZT for CI/CD pipelines
• DoD Zero Trust Strategy — US Department of Defense strategy and reference architecture