Zero Trust Network Architecture Guide

Traditional network security assumes that once a device or user is inside the corporate network — behind the firewall, on the VPN — it is trusted to reach a broad range of internal resources. Zero Trust rejects that assumption entirely. Every access request, whether it originates from a laptop on the corporate LAN or a phone on public Wi-Fi, is evaluated on its own merits: who is the subject, what device are they using, what is being requested, and does the current context justify granting it.

This matters because the perimeter model fails precisely at the moment it's needed most: after an attacker has already gained a foothold via phishing, a compromised credential, or a vulnerable VPN endpoint. Lateral movement inside a flat, implicitly trusted network is what turns a single compromised laptop into a domain-wide breach.

NIST's Zero Trust Architecture publication defines the logical components that implement policy decisions and enforcement. These are logical roles, not necessarily separate physical products:

• •Policy Engine (PE) — the decision-maker; evaluates a request against policy and threat intelligence and produces an allow/deny decision, sometimes with a trust score
• •Policy Administrator (PA) — executes the PE's decision by establishing or terminating the communication path (e.g., issuing a session token, configuring the enforcement point)
• •Policy Enforcement Point (PEP) — sits inline with the traffic (a gateway, proxy, or agent) and actually permits, monitors, or blocks the connection based on the PA's instruction
• •Additional inputs the PE draws on: identity provider/directory, device posture/compliance system, SIEM and threat intelligence feeds, and data classification/policy repositories

Access decisions in a mature Zero Trust deployment aren't a static allow-list — they're evaluated per-session or even per-request against a combination of signals:

• •Identity — authenticated user or workload identity, ideally via strong MFA and short-lived credentials
• •Device posture — is the endpoint managed, patched, running EDR, disk-encrypted, and free of known compromise indicators
• •Context — source location/network reputation, time of day, behavioral baseline relative to that user's normal pattern
• •Resource sensitivity — the classification of what's being requested; higher-sensitivity resources demand stronger assurance

Zero Trust at the network layer is implemented largely through microsegmentation: instead of broad VLANs or subnets where any host can reach any other host, policy is defined per-workload or per-application, often enforced by host-based agents, next-gen firewalls, or a service mesh sidecar rather than by network topology alone.

This is a meaningful shift from traditional segmentation (see the companion article on network segmentation): microsegmentation policy travels with the workload rather than being tied to a subnet, which matters heavily in dynamic environments like Kubernetes clusters or auto-scaling cloud workloads where IP addresses are not stable identifiers.

A common PEP implementation pattern is an identity-aware reverse proxy sitting in front of an internal application, replacing a traditional site-to-site VPN. Below is a representative policy fragment (illustrative syntax, not tied to a specific vendor) enforcing device posture plus group membership before proxying to a backend.

access_policy "internal-finance-app" {
  backend = "https://10.20.5.15:8443"

  require {
    identity.mfa_verified   == true
    identity.group          in ["finance-team", "finance-admin"]
    device.managed          == true
    device.disk_encrypted   == true
    device.os_patch_age_days <= 14
  }

  session {
    max_duration = "8h"
    reauth_on_risk_change = true
  }

  log_decision = true
}

• •Treating Zero Trust as a single product purchase rather than an architecture — buying an identity-aware proxy without addressing device posture or east-west segmentation still leaves lateral movement paths open
• •Applying strict verification only at the perimeter (initial login) and reverting to implicit trust for everything after — this is just perimeter security with an extra login step
• •Ignoring machine-to-machine and service-to-service traffic; Zero Trust principles apply to workload identity, not just human users
• •Underestimating the identity and device-posture infrastructure required before network enforcement can actually be risk-aware — jumping to microsegmentation without reliable device/identity signal produces brittle, overly broad policy

Few organizations can or should attempt a big-bang Zero Trust cutover. A staged approach that tracks with CISA's Zero Trust Maturity Model looks like:

• •Inventory identities, devices, and data flows — you cannot enforce policy on what you haven't mapped
• •Strengthen identity: enforce MFA everywhere, move toward short-lived credentials, integrate device posture into authentication decisions
• •Replace implicit-trust remote access (traditional full-tunnel VPN) with per-application, identity-aware access for a pilot group of applications
• •Introduce microsegmentation incrementally, starting with the highest-value or most exposed workloads rather than the entire estate at once
• •Build continuous monitoring and automated policy adjustment (risk-based reauthentication) as the final maturity stage