Fundamentals

Zero Trust

An architecture that assumes the network is already compromised. No user, device or workload is trusted by virtue of its location; every request is authenticated, authorised and encrypted.

Why the perimeter model failed

The castle-and-moat model treated everything inside the corporate network as trusted. It fails for three reasons: data no longer lives in one datacentre (SaaS, multi-cloud), users no longer sit inside the walls (remote work, contractors, partners), and once an attacker gets in — via phishing, a stolen VPN credential or a vulnerable appliance — they move laterally with the trust the network grants them. A single compromised laptop becomes access to everything.

Core principles

1. Never trust, always verify

Every access request is authenticated and authorised regardless of where it originates. Network location conveys no privilege. Verification is continuous, not once at login: session risk is re-evaluated as context changes.

2. Least privilege

Grant the minimum access needed, for the minimum time. Just-in-time and just-enough access, scoped per application rather than per network segment. This directly limits blast radius.

3. Assume breach

Design as though an attacker is already present. Encrypt east-west traffic, log everything, alert on anomalies, and make lateral movement expensive.

4. Microsegmentation

Divide the environment into small zones with separate access policies — potentially per workload. A user or workload with access to one segment has no implicit access to any other, so a compromise of the marketing web server does not lead to the payments database.

5. Strong identity and device posture

Multi-factor authentication is table stakes, and phishing-resistant factors (FIDO2/WebAuthn, hardware keys) should be preferred over SMS or push, which are vulnerable to interception and MFA fatigue. Device posture — patch level, disk encryption, EDR presence, managed status — is evaluated as part of the access decision.

6. Continuous monitoring and validation

Sessions expire. Risk signals (impossible travel, new device, anomalous data volume, off-hours access) trigger re-authentication or termination. Comprehensive telemetry is what makes this possible.

Signals in an access decision

Signal category	Examples
Identity	User, group, role, authentication strength, recent credential change
Device	Managed/unmanaged, OS patch level, EDR health, certificate presence
Context	Geolocation, ASN, time of day, impossible travel, network reputation
Behaviour	Deviation from the user's normal application and data-access patterns
Resource sensitivity	Data classification, regulatory scope, blast radius of the target system

ZTNA versus VPN

	Traditional VPN	ZTNA
Unit of access	The network	A single application
Visibility of resources	Broad; internal hosts are reachable and scannable	Dark; apps are invisible until authorised
Trust duration	Session-long after login	Continuously re-evaluated
Lateral movement	Easy once connected	Blocked by default
Device posture	Rarely enforced	Part of every decision
Third-party/BYOD	High risk	Practical, clientless options

A pragmatic adoption path

Inventory — identities, devices, applications, data flows. You cannot protect what you have not enumerated; this is the same discovery problem that API Security solves for APIs.
Fix identity first — consolidate on a single IdP, enforce phishing-resistant MFA, remove standing admin privileges.
Move the highest-risk apps behind ZTNA — typically admin consoles, source control, finance and HR systems.
Segment — start with coarse segmentation between environments, then microsegment critical workloads. Run in visibility mode before enforcement, exactly as you would with a behavioural DDoS baseline.
Instrument and iterate — centralise logs, define the anomalies that matter, and tighten policy as confidence grows.

Note: Zero Trust is an architecture and an operating model, not a product. Any vendor claiming a single SKU delivers it is selling one component of it.