Zero Trust Architecture: Never Trust, Always Verify

For decades, network security worked like a medieval castle: a hard perimeter around a soft interior. Once you were inside — on the corporate LAN or the VPN — you were largely trusted. That model collapses in a world of cloud services, remote work, and mobile devices, where there is no clean "inside" anymore. Zero trust replaces location-based trust with continuous, evidence-based verification of every access request.

What zero trust actually means

Zero trust is a set of principles, not a product you can buy. Its core tenet is deceptively simple: never trust, always verify. No request is trusted because of its network origin. Instead, access is granted per-session, based on the strongest available evidence, and only to the specific resource requested — never to the network as a whole. The corollary is least privilege: an authenticated user gets exactly the access they need for that task, and nothing more.

The NIST SP 800-207 model

The most rigorous reference is NIST Special Publication 800-207, which defines zero trust architecture in vendor-neutral terms. It frames access as a decision made for every request, informed by dynamic policy and continuously reassessed. Two logical components sit at its heart, and understanding them is the key to the whole model.

Policy decision and enforcement points

The Policy Enforcement Point (PEP) sits directly on the path of the request. It is the gate: it either allows the connection to the resource or blocks it. The Policy Decision Point (PDP) is the brain: it evaluates the request against policy and tells the PEP what to do. Separating the two matters — the enforcement point can be lightweight and distributed, close to each resource, while the decision logic stays centralised and consistent.

Why the split matters operationally

Because the PDP renders a fresh decision for each request, policy can change instantly and take effect everywhere. Revoke a user, and the next request is denied. Detect a compromised device, and its sessions can be cut mid-stream. There is no standing trust to exploit between decisions.

The signals that drive a decision

A zero trust decision is only as good as the signals feeding it. Four categories matter most. Identity — who is making the request, proven with strong, phishing-resistant authentication. Device posture — is the endpoint managed, patched, and free of known compromise? Context — the time, location, network, and the sensitivity of the resource requested. Risk — a real-time score derived from behavioural analytics and threat intelligence. The PDP combines these into a single allow-or-deny outcome, and can demand step-up authentication when confidence is low.

Zero trust is not authentication at the front door and free rein thereafter. It is continuous verification — every request re-evaluated against current evidence.

Deny by default

The default posture is denial. Access is granted only when policy is affirmatively satisfied; anything unmatched, unrecognised, or ambiguous is refused. This inverts the legacy model, where connectivity was implicit and blocking was the exception. Combined with micro-segmentation — dividing the environment into small zones so that a foothold in one does not grant access to the rest — deny-by-default sharply limits how far an attacker who does get in can move.

A journey, not a switch

No organisation flips to zero trust overnight. In practice it is an incremental programme: start by putting strong identity and device checks in front of the most sensitive applications, replace flat network access with per-application access, and expand coverage outward as telemetry and confidence grow. Each step reduces implicit trust, and the architecture matures without a disruptive big-bang cutover.