Zero Trust Architecture: Never Trust, Always Verify

Zero Trust Is an Architecture, Not a Product

Zero Trust is a design principle: never trust, always verify. Every request — internal or external, human or service — re-establishes identity, device posture, and authorization before access is granted. There is no “inside the corporate network” bonus trust. The 2026 reality is that most networks are already inside someone else's cloud anyway.

The Five Principles (NIST 800-207)

1. All data sources and computing services are resources.
2. All communication is secured, regardless of network location.
3. Access is granted on a per-session basis.
4. Access is determined by dynamic policy — identity, device, behavior.
5. The enterprise monitors and measures the integrity of all owned assets.

The Reference Architecture

flowchart LR
    U[User / Workload] -->|request| PEP[Policy Enforcement Point<br/>(gateway, sidecar, proxy)]
    PEP -->|evaluate| PDP[Policy Decision Point<br/>(OPA, Cedar, IAM)]
    PDP -.->|inputs| ID[Identity Provider]
    PDP -.->|inputs| DEV[Device Trust]
    PDP -.->|inputs| RISK[Risk Signals<br/>(IP, behavior, MFA)]
    PEP -->|allow + scoped token| R[Resource]
      

Every request flows through a Policy Enforcement Point (PEP) — could be Envoy, an API gateway, a service mesh sidecar, or application middleware. The PEP asks a Policy Decision Point (PDP) — OPA, Cedar, IAM — using identity, device, and risk inputs.

Identity-Centric, Not Network-Centric

In a Zero Trust system, the IP address is metadata, not authorization. The principal identity carries through every hop: user via OIDC, workload via SPIFFE/SPIRE, device via certificate. Every request is signed in some form.

# SPIFFE identity for a workload — used by Istio, Linkerd, mTLS gateways
spiffe://prod.example/ns/payments/sa/processor

# The cert presented by every payments-processor pod includes this URI in SAN
# Other services authorize on the SPIFFE ID, never on IP / hostname / port

Microsegmentation

Default-deny between every workload pair. Only explicit allow rules let traffic through. Kubernetes NetworkPolicy, AWS security groups scoped per service, Azure NSG + Application Security Groups, or a service mesh with mTLS + authorization policies.

# Kubernetes NetworkPolicy — orders pod can only call payments
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: orders-egress, namespace: prod }
spec:
  podSelector: { matchLabels: { app: orders } }
  policyTypes: [Egress]
  egress:
    - to:
        - podSelector: { matchLabels: { app: payments } }
      ports: [{ protocol: TCP, port: 8443 }]
    - to:
        - namespaceSelector: { matchLabels: { kube-system: 'true' } }
          podSelector: { matchLabels: { k8s-app: kube-dns } }
      ports: [{ port: 53, protocol: UDP }]

Continuous Verification

Authentication isn't a one-time event. Token lifetimes are short (5–15 min); refresh requires re-evaluating risk. If the user's IP changes country mid-session, step-up auth fires. If device posture degrades (root detected, MDM beacon lost), tokens revoke.

BeyondCorp — The Pragmatic Implementation

Google's BeyondCorp ditched the VPN entirely. Every internal app sits behind an identity-aware proxy. The user authenticates with their Google identity + device certificate. The proxy enforces per-app, per-user policy. No network membership grants trust.

Cloud equivalents: Google IAP, Cloudflare Access, AWS Verified Access,Microsoft Entra Private Access. All implement the same shape: identity-aware reverse proxy in front of every internal app.

Cloud Zero Trust Building Blocks (2026)

A Migration Order That Works

1. Inventory and identity baseline. Every workload gets a stable identity (managed identity, IRSA, SPIFFE). Every user has MFA and a managed device.
2. mTLS everywhere. Deploy a service mesh or sidecar proxies; default-deny without a valid client cert.
3. Identity-aware proxy in front of internal apps; retire the VPN one app at a time.
4. Microsegmentation: NetworkPolicy + per-service security groups, default-deny.
5. Policy as code: OPA / Cedar bundles, peer-reviewed, deployed via CI.
6. Continuous monitoring: behavioral baselines, alerting on policy denies, regular access reviews.

Pitfalls

Buying a “Zero Trust Platform” without changing how you build

Tools enforce policies; they don't write them. If apps still trust the network because “the firewall handles auth”, the appliance you bought is a $200k VPN replacement, nothing more.

Identity inconsistency between humans and workloads

Humans get OIDC, workloads get long-lived API keys in environment variables. That asymmetry is where the next breach starts. Use workload identity federation so services authenticate to clouds and to each other without static credentials.

Policy sprawl with no review

Three years in, you'll have 12,000 IAM policies and nobody knows which are still needed. Tag every policy with an owner and a review date; auto-flag stale ones. Access reviews quarterly, minimum.