What Zero Trust Actually Means

Zero Trust originated as a reaction to the perimeter security model — the idea that everything inside the corporate network is trusted and everything outside isn't. That model made sense in 2005 when employees worked in offices on company machines. It completely breaks down in a world of remote work, BYOD, cloud services, and supply chain attacks.

The Zero Trust model, popularised by John Kindervag at Forrester and operationalised by Google as BeyondCorp, replaces network location as a trust signal with identity, device health, and context.

Never trust, always verify — regardless of where a request originates.

The Three Pillars

1. Identity as the Perimeter

In Zero Trust, the question is not whether a request comes from inside the network — it is who is making the request and whether they are who they claim to be. Every access request requires strong authentication, ideally MFA, and increasingly passwordless via FIDO2 and WebAuthn.

This means the identity provider (Okta, Azure AD, Google Workspace) becomes the most critical piece of infrastructure. Compromise the IdP and you compromise everything.

2. Least Privilege Access

Users and services should have the minimum permissions required to do their job, and those permissions should expire. Just-in-time (JIT) access, where elevated permissions are granted for a specific time window and revoked automatically, is the practical implementation. This applies to service-to-service communication too.

3. Assume Breach

Zero Trust assumes that breaches have already occurred or will occur. The architecture is designed to limit blast radius: segment networks, monitor east-west traffic (not just perimeter), and log everything. The goal is to detect and contain, not just prevent.

BeyondCorp — The Reference Implementation

Google published BeyondCorp in a series of papers starting in 2014. Their insight: move access controls from the network perimeter to individual devices and users. Employees access internal apps through an access proxy that checks device compliance, user authentication, and role-based permission — regardless of network location.

ZTNA vs VPN

Traditional VPN gives users network-level access — once connected, they can reach anything on the subnet. ZTNA grants application-level access only. A contractor with ZTNA access to the HR portal cannot pivot to the database server. A compromised VPN credential gives you the whole network; a compromised ZTNA credential gives you only what that identity was permitted to access.

Micro-segmentation

In a perimeter model, once inside the network, lateral movement is relatively easy. Micro-segmentation divides the internal network into isolated zones — even east-west traffic between workloads must be explicitly permitted and authenticated. In cloud environments, this maps to security groups, VPC peering rules, and service mesh mTLS.

A Realistic Maturity Roadmap

  • Year 1: Deploy phishing-resistant MFA everywhere. Implement SSO. Start device inventory.
  • Year 2: Enforce device compliance checks. Deploy ZTNA for remote access. Start least-privilege access reviews.
  • Year 3: Micro-segmentation for critical workloads. JIT elevated access. Continuous session monitoring.

The Hard Parts

The technical implementation of Zero Trust is solvable. The hard parts are organisational: legacy apps that can't support modern auth protocols, user friction from continuous verification, and getting leadership buy-in for a multi-year investment.

Takeaway

Zero Trust is the right model for modern enterprise security. The perimeter is gone — remote work, cloud, and supply chain attacks dissolved it. Identity is the new perimeter. Ask not whether a request comes from inside the network, but whether you know who this is, on what device, in what context, and whether they should have this access right now.