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.
• 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.

Further Reading

• Official documentation: check the current reference for the framework or tool used.
• Related guides: explore the zero-trust and security guides for deeper coverage.
• Complementary patterns: review design patterns applicable to your technology stack.
• Public postmortems: study real incidents from teams that faced similar production issues.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply zero trust architecture — never trust, always verify when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

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.