Zero Trust Architecture: Never Trust, Always Verify
The traditional security model draws a hard perimeter around the network and trusts everything inside it. Zero trust architecture flips that assumption: never trust, always verify. Every request — whether it originates from the corporate office or a coffee shop — must prove its identity and authorization before accessing any resource.
Core Principles#
Zero trust rests on three pillars defined by NIST SP 800-207:
- Verify explicitly — Authenticate and authorize every request based on all available signals: identity, device health, location, resource sensitivity, and anomaly detection.
- Least-privilege access — Grant the minimum permissions needed, scoped by time (just-in-time) and by function (just-enough-access).
- Assume breach — Design every layer as though an attacker already has a foothold. Minimize blast radius through segmentation, encryption, and continuous monitoring.
Architecture Components#
A zero trust architecture is not a single product. It is a set of cooperating components:
┌─────────────┐ ┌──────────────┐ ┌────────────────────┐
│ Subject │─────▶│ Policy │─────▶│ Enforcement │
│ (User / │ │ Decision │ │ Point (PEP) │
│ Device) │◀─────│ Point (PDP) │◀─────│ — proxy / gw │
└─────────────┘ └──────┬───────┘ └────────────────────┘
│
┌────────▼────────┐
│ Policy Engine │
│ + Trust Algo │
└────────┬────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Identity │ │ Device │ │ Threat │
│ Provider │ │ Inventory │ │ Intel │
│ (IdP) │ │ / MDM │ │ / SIEM │
└────────────┘ └────────────┘ └────────────┘
Identity Provider (IdP): The single source of truth for who a subject is — Okta, Azure AD, Google Workspace. Every authentication flows through the IdP.
Policy Decision Point (PDP): Evaluates each request against policies, risk signals, and context. Outputs an allow/deny decision.
Policy Enforcement Point (PEP): A gateway, reverse proxy, or sidecar that intercepts traffic and enforces the PDP's verdict. No direct access to resources is permitted.
Continuous Diagnostics: Device posture, threat intelligence feeds, and behavioral analytics all feed into the policy engine in real time.
Google's BeyondCorp Model#
Google pioneered zero trust at scale with BeyondCorp after the 2009 Operation Aurora attacks. The key insights:
- No privileged network. The corporate LAN offers no more trust than the public internet.
- Device inventory is mandatory. Every device gets a certificate from a device inventory service. Unmanaged devices are denied access.
- Access proxy replaces VPN. All applications sit behind an access proxy that evaluates identity + device trust on every request.
- Access levels, not network zones. Policies map (user, device, resource) tuples to access tiers rather than relying on IP allowlists.
BeyondCorp demonstrated that enterprises can eliminate the VPN entirely without sacrificing security — and in fact improve it.
Micro-Segmentation#
Traditional flat networks let attackers move laterally after a single breach. Micro-segmentation breaks the network into fine-grained zones:
┌─────────────────────────────────────────────────┐
│ Data Center │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Segment A │ │ Segment B │ │ Segment C │ │
│ │ (Web Tier)│──▶│ (App Tier)│──▶│ (DB Tier) │ │
│ │ │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ▲ ▲ ▲ │
│ │ Firewall │ Firewall │ │
│ │ Rules │ Rules │ │
│ Per-workload policies enforced at each hop │
└─────────────────────────────────────────────────┘
Each segment has its own policy. Even if an attacker compromises the web tier, they cannot reach the database without passing through an additional enforcement point. In Kubernetes, network policies and service meshes (Istio, Linkerd) provide workload-level segmentation out of the box.
Mutual TLS (mTLS)#
In a zero trust network, encryption is not optional — and server-only TLS is not enough. Mutual TLS requires both sides of a connection to present certificates:
- Client sends its certificate to the server.
- Server validates the client certificate against a trusted CA.
- Server sends its certificate to the client.
- Client validates the server certificate.
mTLS guarantees identity in both directions and prevents man-in-the-middle attacks even inside the network. Service meshes automate mTLS certificate rotation so application code never touches crypto.
ZTNA vs VPN#
| Dimension | Traditional VPN | ZTNA |
|---|---|---|
| Trust model | Trust the network after connect | Trust nothing, verify per-request |
| Access scope | Full network access | Per-application access |
| Lateral movement | Easy once inside | Blocked by design |
| User experience | Slow tunnel, split routing issues | Direct connection via proxy |
| Scalability | VPN concentrator bottleneck | Distributed edge enforcement |
| Visibility | Limited — encrypted tunnel | Full request-level logging |
ZTNA replaces the "connect first, authenticate second" model with "authenticate first, connect only to what you need." The attack surface shrinks from the entire network to a single application endpoint.
Implementation Steps#
Rolling out zero trust is incremental, not big-bang:
Phase 1 — Identity Foundation#
- Deploy a centralized IdP with MFA for all users.
- Inventory every device; assign trust levels based on OS patch status, disk encryption, and MDM enrollment.
- Catalog all applications and data flows.
Phase 2 — Policy and Enforcement#
- Define access policies: (who, from what device, to which resource, under what conditions).
- Deploy enforcement points — reverse proxies for web apps, ZTNA agents for thick clients.
- Start in audit mode: log decisions but do not block traffic yet.
Phase 3 — Segment and Encrypt#
- Implement micro-segmentation at the network and workload levels.
- Enable mTLS between all services.
- Encrypt data at rest with key management tied to identity.
Phase 4 — Continuous Verification#
- Feed device posture, threat intel, and user behavior analytics into the policy engine.
- Implement session re-evaluation — downgrade or revoke access when risk signals change mid-session.
- Automate incident response: isolate compromised segments within seconds.
Tools and Platforms#
| Tool | Category | Notes |
|---|---|---|
| Zscaler ZPA | ZTNA | Cloud-native, app-level access without exposing the network |
| Cloudflare Access | ZTNA / Access Proxy | BeyondCorp-style proxy, integrates with any IdP |
| Tailscale | Mesh VPN / ZTNA | WireGuard-based, identity-aware, zero-config |
| WireGuard | Encrypted Tunnel | Lightweight kernel-level VPN, foundation for overlay networks |
| Istio / Linkerd | Service Mesh | mTLS, traffic policies, observability for Kubernetes |
| HashiCorp Boundary | Privileged Access | Session-based access to infrastructure, no static credentials |
| Okta / Azure AD | Identity Provider | Centralized authentication, conditional access policies |
Key Takeaways#
- Zero trust is an architecture, not a product. No single vendor delivers it end-to-end.
- Start with identity. If you do not know who is making a request, no policy can protect you.
- Micro-segmentation limits blast radius. Assume breach and design for containment.
- mTLS ensures both sides of every connection are authenticated and encrypted.
- ZTNA eliminates the VPN bottleneck and reduces attack surface to individual applications.
- Implementation is incremental — audit mode first, enforce later.
Zero trust is not about distrust. It is about building systems where trust is earned continuously rather than assumed once at the perimeter.
Build and explore system design concepts hands-on at codelit.io.
136 articles on system design at codelit.io/blog.
Try it on Codelit
Chaos Mode
Simulate node failures and watch cascading impact across your architecture
Related articles
Build this architecture
Generate an interactive Zero Trust Architecture in seconds.
Try it in Codelit →
Comments