Zero Trust Network Architecture¶

Zero Trust Network Architecture (ZTNA) eliminates implicit trust from every network interaction. Unlike traditional perimeter-based security — where anything inside the firewall is trusted — ZTNA treats every access request as if it originates from an untrusted network. This document provides a vendor-neutral reference architecture aligned with NIST SP 800-207 and the BeyondCorp model.

Core Principles¶

Zero Trust is built on three non-negotiable principles:

Zero Trust Network Reference Architecture¶

flowchart TB
    subgraph Users["Users & Devices"]
        EU[Enterprise User]
        RU[Remote User]
        SVC[Service Account]
        IOT[IoT / OT Device]
    end

    subgraph DeviceTrust["Device Trust Layer"]
        DA[Device Agent]
        DC[Device Compliance Check]
        CERT[Certificate Validation]
    end

    subgraph ControlPlane["Control Plane"]
        PAP[Policy Administration Point<br/>Policy authoring & lifecycle]
        PDP[Policy Decision Point<br/>Real-time access decisions]
        PIP[Policy Information Point<br/>Context aggregation]
    end

    subgraph DataSources["Context Sources → PIP"]
        IDM[Identity Provider / IdP]
        TI[Threat Intelligence Feed]
        SIEM_CTX[SIEM Risk Scores]
        CMDB[Asset Inventory / CMDB]
        UEBA[UEBA Behavioral Baseline]
    end

    subgraph DataPlane["Data Plane"]
        PEP[Policy Enforcement Point<br/>Inline gateway / proxy]
        MICRO[Microsegmentation Engine]
        ENCRYPT[mTLS / Encrypted Tunnels]
    end

    subgraph Resources["Protected Resources"]
        APP[Applications]
        DATA[Data Stores]
        INFRA[Infrastructure Services]
        CLOUD[Cloud Workloads]
    end

    EU --> DA
    RU --> DA
    SVC --> DA
    IOT --> DA
    DA --> DC
    DC --> CERT
    CERT --> PEP

    PEP -- "access request" --> PDP
    PDP -- "query context" --> PIP
    PIP --> IDM
    PIP --> TI
    PIP --> SIEM_CTX
    PIP --> CMDB
    PIP --> UEBA
    PAP -- "publish policy" --> PDP
    PDP -- "allow/deny" --> PEP

    PEP --> MICRO
    MICRO --> ENCRYPT
    ENCRYPT --> APP
    ENCRYPT --> DATA
    ENCRYPT --> INFRA
    ENCRYPT --> CLOUD

Core Components¶

The four pillars of a Zero Trust architecture, derived from NIST SP 800-207:

Policy Decision Point (PDP)¶

The PDP is the brain of the architecture. It receives access requests from enforcement points, evaluates them against policy, and returns an allow/deny decision.

Policy Enforcement Point (PEP)¶

The PEP sits inline with every access request and enforces the PDP's decision. It is the only path to protected resources.

PEP deployment patterns:

• Identity-aware proxy — Reverse proxy authenticating every HTTP/S request (BeyondCorp model)
• Software-defined perimeter (SDP) — Single-packet authorization before connection establishment
• Microsegmentation agent — Host-based firewall enforcing workload-to-workload policy
• API gateway — Token validation and scope enforcement for service-to-service calls

Policy Information Point (PIP)¶

The PIP aggregates contextual signals that feed PDP decisions:

Policy Administration Point (PAP)¶

The PAP is where policies are authored, tested, versioned, and published to PDPs.

Policy lifecycle:

Author policy → Peer review → Test in simulation mode → Staged rollout (5% → 25% → 100%) → Monitor → Iterate

Zero Trust Maturity Model¶

Organizations progress through maturity levels as they adopt Zero Trust. This model provides a self-assessment framework:

Implementation Roadmap¶

A six-phase adoption plan aligned with the Forrester ZTX and NIST frameworks:

Phase 1: Identify Protect Surfaces (Months 1–2)¶

Define what you are protecting. The protect surface is the inverse of the attack surface — it is small, well-defined, and defensible.

Deliverable: Prioritized register of protect surfaces ranked by business impact.

Phase 2: Map Transaction Flows (Months 2–3)¶

Understand how traffic flows to and from each protect surface. You cannot protect what you do not understand.

flowchart LR
    subgraph Sources["Traffic Sources"]
        ANALYST[Analysts]
        APPS[Applications]
        SVCS[Services]
        PARTNERS[Partners]
    end

    subgraph Flows["Transaction Flows"]
        AUTH[Authentication Flow]
        API_FLOW[API Call Flow]
        DATA_FLOW[Data Access Flow]
        ADMIN_FLOW[Admin Flow]
    end

    subgraph Surfaces["Protect Surfaces"]
        CRM_PS[CRM — Customer Data]
        SIEM_PS[SIEM — Security Logs]
        CICD_PS[CI/CD — Source Code]
        AD_PS[AD — Identity Infrastructure]
    end

    ANALYST --> AUTH --> CRM_PS
    APPS --> API_FLOW --> SIEM_PS
    SVCS --> DATA_FLOW --> CICD_PS
    PARTNERS --> ADMIN_FLOW --> AD_PS

Deliverable: Transaction flow map showing all access paths to each protect surface, including ports, protocols, and identity context.

Phase 3: Build Zero Trust Architecture (Months 3–6)¶

Deploy the core components (PDP, PEP, PIP, PAP) starting with the highest-priority protect surfaces.

Priority order:

1. Identity infrastructure (IdP, AD, certificate services)
2. Security tooling (SIEM, SOAR, EDR consoles)
3. Developer infrastructure (CI/CD, source control, artifact repositories)
4. Business-critical applications (ERP, CRM)
5. General enterprise applications
6. IoT and OT environments

Phase 4: Create Zero Trust Policy (Months 5–8)¶

Define granular access policies using the Kipling Method — who, what, when, where, why, and how:

Phase 5: Monitor and Maintain (Months 8–12)¶

Deploy continuous monitoring to validate Zero Trust controls:

• Policy violation monitoring — Alert on every denied access attempt; investigate repeated denials
• Configuration drift detection — Automated checks that PEP configurations match PAP-published policy
• Access pattern analytics — Baseline normal access patterns; alert on deviations (UEBA)
• Control effectiveness metrics — Track the metrics defined in the Metrics section below

Phase 6: Automate and Orchestrate (Months 10–18)¶

Mature from manual policy management to automated orchestration:

Technology Components¶

Software-Defined Perimeter (SDP)¶

SDP implements a "dark cloud" — protected resources are invisible to unauthorized users. Connection is established only after authentication and authorization.

1. SDP Controller authenticates user + device
2. Controller validates against PDP
3. Controller provisions encrypted tunnel to specific resource
4. Resource is never exposed to unauthenticated scanning

Zero Trust Network Access (ZTNA)¶

ZTNA replaces VPN by providing per-application access rather than full network access:

Microsegmentation¶

Microsegmentation enforces security policy at the individual workload level rather than the network perimeter:

Implementation approaches:

• Agent-based — Host-level firewall managed by central policy (most granular)
• Network-based — SDN controller programs switches/routers (infrastructure-dependent)
• Hypervisor-based — Virtual firewall between VMs (virtualized environments only)
• Cloud-native — Security groups, network policies (Kubernetes NetworkPolicy, AWS SGs)

Identity-Aware Proxy (IAP)¶

IAP authenticates and authorizes every request at the proxy layer before forwarding to the backend application:

sequenceDiagram
    participant U as User
    participant IAP as Identity-Aware Proxy
    participant IDP as Identity Provider
    participant PDP as Policy Decision Point
    participant APP as Application

    U->>IAP: HTTPS request to app.example.com
    IAP->>IDP: Validate session / redirect to auth
    IDP-->>IAP: Identity token (user, groups, MFA status)
    IAP->>PDP: Authorize (identity + device + context)
    PDP-->>IAP: Allow (scoped permissions)
    IAP->>APP: Forward request with identity headers
    APP-->>IAP: Response
    IAP-->>U: Response (logged with full context)

Secure Access Service Edge (SASE)¶

SASE converges networking and security into a cloud-delivered service:

Vendor-Neutral Reference Architecture¶

This architecture is aligned with NIST SP 800-207 and the BeyondCorp model. It does not depend on any single vendor.

NIST SP 800-207 Deployment Models¶

BeyondCorp Reference¶

Google's BeyondCorp model demonstrates that enterprise applications can be accessed securely without a VPN:

1. Access depends on device and user credentials — not network location
2. All access to enterprise resources is authenticated, authorized, and encrypted
3. Access is granted on a per-request basis — no persistent trust
4. Policy is dynamic and sourced from multiple contextual signals

Integration Points¶

Zero Trust architecture does not exist in isolation. It integrates with the broader security operations stack:

flowchart LR
    PDP[Policy Decision Point]

    SIEM[SIEM] <-->|risk scores ↔ access logs| PDP
    SOAR[SOAR] <-->|incidents ↔ policy updates| PDP
    EDR[EDR] -->|device posture| PDP
    NDR[NDR] -->|network anomalies| PDP
    CASB[CASB] <-->|SaaS policy| PDP
    IAM[IAM] <-->|identity context| PDP

Metrics and KPIs¶

Track these metrics to measure Zero Trust effectiveness and maturity:

Coverage Metrics¶

Effectiveness Metrics¶

Operational Metrics¶

Common Zero Trust Network Mistakes¶

Nexus SecOps Control Mapping¶

See Zero Trust SOC | Reference Architecture | Integration Patterns Related chapters: Chapter 13: Governance | Chapter 33: Identity & Access Security | Chapter 22: Network Security