Security Architecture Essential

Zero Trust Architecture

Never trust, always verify: designing systems on the principle that no actor, workload, or network segment is inherently trustworthy, using the BeyondCorp model and NIST SP 800-207 as implementation guides.

⏱ 11 min read

What it is

Zero Trust Architecture (ZTA) is a security paradigm that eliminates implicit trust based on network location. The classical perimeter model assumed that traffic inside the corporate network was safe and only external traffic required scrutiny — the "castle and moat" approach. Zero Trust inverts this: no request is trusted by default regardless of origin. Every access decision is made dynamically based on the verified identity of the requester, the health and compliance posture of the device, the sensitivity of the resource, and the context of the request (time, location, behaviour).

Google's BeyondCorp initiative, published as a series of papers beginning in 2014, is the canonical real-world implementation. Google migrated its entire workforce away from a VPN-based perimeter model to one where access to internal resources is granted by an Access Proxy that enforces policy based on user identity (via certificates) and device inventory state — with no assumption of safety for traffic on the corporate LAN. NIST Special Publication 800-207, published in 2020, provides the US federal government's definition of Zero Trust and identifies seven tenets, including: all data sources and services are considered resources; all communication is secured regardless of network location; access to resources is granted on a per-session basis; and access policy is dynamic and informed by multiple data sources.

Why it exists

The perimeter security model has failed for three structural reasons. First, the perimeter has dissolved: employees work from home, contractors access resources from unmanaged devices, workloads run in public clouds, and SaaS applications mean that "the network" is no longer a well-defined boundary. A corporate VPN extending implicit trust to a home network connected to IoT devices achieves security theatre rather than actual security. Second, lateral movement is the primary attack vector: once an attacker compromises any foothold inside the perimeter (a phishing email, a misconfigured cloud storage bucket), they can move freely between internal systems. Microsegmentation and per-session authorization contain the blast radius of such breaches. Third, insider threat and credential compromise are among the most common causes of data breaches; a model that trusts anyone inside the perimeter by definition cannot defend against compromised insider credentials.

When to use

  • Organisations with distributed workforces where employees or contractors access resources from outside managed network perimeters.
  • Cloud-native or hybrid architectures where workloads span public cloud, on-premises, and SaaS environments without a meaningful network boundary.
  • High-security or regulated environments (financial services, healthcare, government) where per-session authorisation and audit trails are required.
  • Mergers and acquisitions: interconnecting two organisations without extending implicit trust between their networks.
  • Replacing legacy VPN infrastructure that has become a bottleneck or attack surface.

When not to use

  • Very small organisations: The operational overhead of maintaining a Zero Trust policy engine, identity provider, and device management system may exceed the risk it mitigates for a 5-person team.
  • Air-gapped systems: Systems with genuine physical isolation (classified networks, industrial control systems) use physical trust boundaries that may be more appropriate than software-defined Zero Trust.
  • Legacy systems that cannot authenticate: Network-level trust may be the only option for legacy devices or protocols (ICS/SCADA, old mainframes) that lack any cryptographic identity mechanism.

Typical architecture

ZERO TRUST REFERENCE ARCHITECTURE (NIST 800-207):

  ┌──────────────────────────────────────────────┐
  │           Policy Decision Point (PDP)         │
  │  Policy Engine (PE) + Policy Administrator   │
  │  - Identity Provider integration             │
  │  - Device compliance signals (MDM/EDR)       │
  │  - Threat intelligence feeds                 │
  │  - Context: time, location, risk score       │
  └──────────────────────────────────────────────┘
            ↑ evaluate    ↓ decision (allow/deny)
  ┌──────────────────────────────────────────────┐
  │         Policy Enforcement Point (PEP)        │
  │  - Identity-Aware Proxy (e.g., Google IAP)   │
  │  - ZTNA gateway (e.g., Cloudflare Access)    │
  │  - Service mesh (mTLS sidecar)               │
  └──────────────────────────────────────────────┘
            ↑ request     ↓ authenticated session
  Subject:  User / workload / device
            ↓
  Resource: Application / API / database

MICROSEGMENTATION:
  Traditional: subnet-level firewall rules
  Zero Trust:  workload-to-workload mTLS with
               identity-based policy
               (e.g., "service A can call service B
                only if it presents cert from CA X")

CONTINUOUS AUTHORIZATION:
  Session-level:  re-evaluate policy on each request
  Risk-adaptive:  step-up MFA if risk score spikes
                  (new location, anomalous behaviour)

Pros and cons

Pros

  • Lateral movement is contained: a compromised credential or workload cannot freely access unrelated resources.
  • Enables secure remote work and cloud-native architectures without VPN bottlenecks.
  • Per-session authorisation provides a detailed audit trail of who accessed what, when, and from where.
  • Microsegmentation reduces blast radius of breaches significantly.
  • Aligns with regulatory requirements (NIST, FedRAMP, HIPAA) for least-privilege access.

Cons

  • Significant identity infrastructure investment required: IdP, PKI, device management, policy engine.
  • Per-session authorization adds latency if the policy evaluation path is not optimised.
  • Legacy applications that cannot present machine identities are difficult to integrate.
  • Policy management complexity grows with scale; incorrect policy rules can deny legitimate access (false positives causing outages).
  • Full ZTA maturity is a multi-year journey; partial adoption can create gaps if not carefully sequenced.

Implementation notes

The BeyondCorp migration path typically follows four stages: (1) establish a strong identity foundation — federated SSO with MFA for all users and workloads via OIDC/SAML; (2) gain device visibility — enroll all devices in MDM (Jamf, Intune, Google Endpoint Management) and generate device compliance signals; (3) deploy an identity-aware proxy or ZTNA gateway in front of all internal applications and begin replacing VPN access; (4) extend Zero Trust to workload-to-workload communication using mTLS with service mesh (Istio, Linkerd) or cloud-native workload identity (AWS IAM roles, GCP Workload Identity). Begin with the most critical, highest-risk applications rather than attempting a "big bang" migration. Use a phased approach: monitor mode first (log access denials without blocking) to understand policy impact before enforcing.

For cloud-native deployments, use cloud-provider native Zero Trust services: Google BeyondCorp Enterprise, AWS Verified Access, Azure Zero Trust network access, and Cloudflare Access all provide identity-aware proxy capabilities with minimal infrastructure overhead. For workload identity in Kubernetes, SPIFFE/SPIRE provides platform-agnostic cryptographic workload identity that integrates with service meshes and secret managers.

Common failure modes

  • VPN replacement without policy change: Replacing a VPN with a ZTNA gateway that grants the same broad access as the VPN achieves nothing; Zero Trust requires per-resource, per-session policy.
  • Orphaned service accounts: Shared, long-lived service account credentials bypass device-level trust signals; all workload identities should be short-lived and scoped.
  • Incomplete device coverage: Contractor or BYOD devices not enrolled in MDM create blind spots in device posture signals, weakening access decisions.
  • Policy sprawl: Organisations that create thousands of fine-grained policies without a governance model end up with unmanageable rule sets that no one understands or audits.
  • No fallback for policy engine outages: If the PDP/PEP goes down, what happens? Fail-open grants all access (unsafe); fail-closed blocks all access (operational disaster). Design for high availability.

Decision checklist

  • Is there a federated identity provider with MFA for all users and service accounts?
  • Are device posture signals (compliance, patch level, EDR status) integrated into access decisions?
  • Is per-resource, per-session authorisation enforced at a Policy Enforcement Point?
  • Is all communication encrypted in transit (TLS/mTLS) regardless of network location?
  • Is the Policy Decision Point highly available with defined fail-behavior?
  • Are legacy systems that cannot adopt Zero Trust documented with compensating controls?

Example use cases

  • Remote workforce access: Engineers access internal tools via Cloudflare Access (ZTNA), which validates their Okta identity and Intune device compliance before proxying each request — no VPN client required.
  • Microservices security: Kubernetes workloads communicate only over mTLS; Istio enforces that the payment service can only be called by services presenting valid SPIFFE SVIDs from the same trust domain.
  • Contractor access: External contractors receive time-limited access to specific internal applications via ZTNA, scoped to their project, with no lateral visibility to other services.

Further reading