Zero Trust Architecture — Never Trust, Always Verify

Overview

Zero Trust is a security model that eliminates the concept of a trusted network perimeter. Instead of assuming that traffic inside the network is safe, Zero Trust verifies every request as if it came from an untrusted network. Every user, device, and application must be authenticated, authorized, and continuously validated before gaining access to resources.

When to Use

• For alternatives, see Complete Guide to LLM Security.

• You have a distributed workforce with remote access needs

• You are migrating from a perimeter-based network to cloud-native architecture

• You need to comply with stringent regulatory requirements (SOC 2, ISO 27001, NIST)

• You want to minimize the blast radius of compromised credentials

Core Principles

Verify Explicitly

Authenticate and authorize every access request based on all available data points: identity, device health, location, and anomaly detection.

Use Least Privilege Access

Grant only the minimum permissions required for the specific task and time-bound them where possible.

Assume Breach

Design systems as if an attacker is already inside. Minimize blast radius through segmentation and encryption.

Architecture Components

Identity Provider (IdP)

The foundation of Zero Trust. All access decisions start with strong identity verification.

┌─────────────┐
│   User      │
└──────┬──────┘
       │
       ▼
┌─────────────────┐
│   MFA + Biometric│  ◀── Step 1: Verify identity
│   Device Attestation│
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Identity      │
│   Provider      │
│   (OAuth/OIDC)  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Policy Engine │  ◀── Step 2: Evaluate context
│   (OPA, Cedar)  │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   Resource      │  ◀── Step 3: Grant limited access
└─────────────────┘

Device Trust

Ensure only healthy, managed devices can access corporate resources.

Signal	What It Checks	Tool Example
Endpoint detection	AV running, no malware	CrowdStrike, SentinelOne
OS patch level	Latest security updates	Intune, Jamf
Disk encryption	BitLocker/FileVault enabled	Device compliance policy
Certificate	Device is corporate-managed	MDM-issued certificate

Micro-Segmentation

Divide the network into small, isolated zones so a breach in one cannot spread.

┌─────────────────────────────────────────────┐
│                    VPC                        │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │  Web    │  │  API    │  │  DB     │     │
│  │  Tier   │──│  Tier   │──│  Tier   │     │
│  │         │  │         │  │         │     │
│  └─────────┘  └─────────┘  └─────────┘     │
│       │            │            │         │
│  ┌────┴────┐  ┌────┴────┐  ┌────┴────┐     │
│  │  L7 FW  │  │  L7 FW  │  │  L7 FW  │     │
│  │  + WAF  │  │  + AuthZ│  │  + AuthZ│     │
│  └─────────┘  └─────────┘  └─────────┘     │
└─────────────────────────────────────────────┘

Continuous Validation

Trust is not a one-time event. Re-evaluate access based on behavior.

# Pseudocode for continuous access evaluation
def evaluate_access(user, resource, context):
    risk_score = 0
    
    if context.location != user.usual_location:
        risk_score += 30
    if context.device_trust_score < 0.8:
        risk_score += 40
    if context.time_of_day not in user.working_hours:
        risk_score += 20
    
    if risk_score > 50:
        return Deny("High risk session detected")
    if risk_score > 20:
        return StepUpAuth("Additional verification required")
    
    return Allow()

Implementation Patterns

BeyondCorp (Google’s Zero Trust Model)

• All access is mediated by an access proxy
• Device inventory and health are prerequisites
• User identity is tied to a corporate identity provider
• No VPN required; access is location-agnostic

Software-Defined Perimeter (SDP)

• The network is dark until authentication succeeds
• A trust broker validates identity before revealing resource IPs
• All connections are encrypted (mTLS)

Zero Trust Network Access (ZTNA)

• Replaces VPN with application-level access
• Users get access only to specific apps, not the entire network
• Agent-based or agentless deployment options

Practical Implementation Steps

1. Inventory assets — data, applications, devices, and network segments
2. Map transaction flows — how users and services interact
3. Architect Zero Trust — design policy enforcement points
4. Deploy identity provider — with MFA and conditional access
5. Implement micro-segmentation — at the application and network layers
6. Monitor and improve — use SIEM and UEBA for anomaly detection

Common Mistakes

• Buying a product and calling it Zero Trust — it is an architecture, not a SKU
• Ignoring user experience — excessive friction leads to shadow IT
• Focusing only on users, not services — service-to-service traffic also needs identity
• Over-segmenting — too many zones create operational complexity
• No visibility — you cannot validate what you cannot monitor

Troubleshooting

• Authentication bypass in tests: ensure test users cannot reach production endpoints. Use separate credentials and environments for CI.
• False positives in scanning tools: tune rules against the risk profile. Distinguish between reachable vulnerabilities and theoretical issues.
• Secrets appear in logs: configure log filters to redact tokens, passwords, and keys. Audit log sinks for sensitive patterns.
• CSP breaks legitimate functionality: use report-only mode first, then enforce. Iterate on allowed sources based on real violations.
• Incident response stalls: run tabletop exercises. Document escalation paths, evidence collection steps, and communication templates in advance.

FAQ

Is Zero Trust only for large enterprises? No. Small teams can implement core principles: MFA, least privilege, and micro-segmentation with cloud-native tools.

Does Zero Trust replace the firewall? Firewalls become one enforcement point among many. The perimeter dissolves; every resource becomes its own perimeter.

How do I measure Zero Trust maturity? Use the CISA Zero Trust Maturity Model or Forrester’s Zero Trust eXtended framework. Both provide clear stages from legacy to advanced.

How do I get started with this in an existing project?

Start with a small, isolated part of your codebase. Apply the concepts from this guide to one module or service. Measure the impact, then expand to other areas.

What tools do I need?

The tools mentioned throughout this guide are listed in each section. Most are open-source and widely adopted. Check the related resources for setup instructions.

How do I measure success after implementing this?

Define clear metrics before starting: performance benchmarks, error rates, or maintainability indicators. Compare before and after. Iterate based on the data, not on assumptions.

Advanced Topics

Scenario: Zero Trust Implementation for Microservices

System: 15 microservices on Kubernetes, 500 users
Goal: Zero Trust architecture (no implicit trust)

Principles:
  1. Never trust, always verify
  2. Least privilege access
  3. Assume breach
  4. Verify explicitly

Architecture layers:
  | Layer | Component | Implementation |
  |-------|-----------|----------------|
  | Identity | OIDC + MFA | Keycloak + WebAuthn |
  | Device | Device posture check | Tanium / Intune |
  | Network | mTLS between services | SPIFFE/SPIRE |
  | Application | RBAC + ABAC | OPA (Open Policy Agent) |
  | Data | Encryption at rest + in transit | KMS + TLS 1.3 |
  | Monitoring | Audit log + SIEM | ELK + Falco |

mTLS between services (SPIFFE):
  # Cada servicio obtiene una identidad criptografica
  # SPIRE agent en cada nodo emite SVID (SPIFFE Verifiable Identity Document)
  # Los servicios se autentican mutuamente via mTLS
  # No hay IPs confiables: la identidad es criptografica

  Service A -> mTLS -> Service B
    A presenta su SVID
    B verifica SVID contra trust bundle
    B presenta su SVID
    A verifica SVID contra trust bundle
    Comunicacion cifrada con TLS 1.3

Policy enforcement (OPA):
  # Reglas declarativas en Rego
  allow {
    input.user.role == "admin"
    input.action == "read"
    input.resource.environment == "production"
  }

  allow {
    input.user.team == input.resource.team
    input.action == "update"
  }

  # Denegar por defecto, permitir explicitamente
  # Cada request pasa por OPA sidecar

Access flow:
  User -> IdP (OIDC + MFA) -> Token JWT
  User -> API Gateway (valida JWT) -> Service A
    Service A -> OPA (policy check) -> autoriza?
    Service A -> mTLS -> Service B
    Service B -> OPA (policy check) -> autoriza?
    Service B -> DB (conexiones cifradas, least privilege)

Migration phases:
  Phase 1: Identity (OIDC + MFA para todos los usuarios)
  Phase 2: Network segmentation (network policies en K8s)
  Phase 3: mTLS entre servicios (SPIFFE/SPIRE)
  Phase 4: Policy enforcement (OPA sidecars)
  Phase 5: Continuous monitoring (audit log + SIEM)

Lessons:
  - Zero Trust es un viaje, no un switch
  - Empieza con identity y MFA
  - mTLS elimina la confianza basada en red
  - OPA centraliza las politicas de autorizacion
  - Monitoreo continuo: asume que estas comprometido

How long does a Zero Trust migration take?

For a mid-size organization (50-200 services), expect 12-18 months. Phase 1 (identity + MFA) takes 1-3 months. Phase 2 (network segmentation) takes 2-4 months. Phase 3 (mTLS) takes 3-6 months. Phase 4 (policy enforcement) takes 2-4 months. Phase 5 (monitoring) is ongoing. Start with the most critical services first.

End of document. Review and update quarterly.

Common Production Pitfalls

• Treating the guide as a checklist to complete once rather than a practice to evolve.
• Adopting every recommendation at once instead of starting with one measured change.
• Skipping the maturity assessment and forcing advanced practices on an unprepared team.
• Not updating runbooks and on-call expectations as new practices are introduced.
• Ignoring real incident data when prioritizing which parts of the guide to apply first.
• Failing to assign an owner who reviews decisions quarterly.
• Copying examples without adapting them to the team’s actual tooling and constraints.
• Forgetting to measure outcomes before adding the next improvement.