The phrase "Zero Trust" has been so thoroughly co-opted by marketing teams that it has almost lost meaning. Vendors claim their products are Zero Trust. Government frameworks mandate Zero Trust adoption. Executives ask for Zero Trust roadmaps. And yet, in most organisations, "Zero Trust" in practice means forcing employees to re-authenticate every few hours and adding a second factor to their VPN login.

That is not Zero Trust. That is perimeter security with more friction.

Zero Trust is an architectural philosophy, not a product category. Its foundational premise — articulated by John Kindervag at Forrester and later refined by NIST in SP 800-207 — is that no entity, whether a user, device, or service, should be inherently trusted based on its network location. Trust must be established continuously, explicitly, and based on verified context.

What Zero Trust Actually Requires

A genuine Zero Trust architecture operates across three planes simultaneously:

The Identity Plane. Every access request originates from an identity — a user, a service account, a workload. The identity plane is responsible for strongly authenticating those identities, enriching them with context (device health, location, time, role), and making that context available to policy evaluation. This requires a mature identity provider — Microsoft Entra ID, Okta, or equivalent — with rich signal ingestion and conditional access capabilities.

The Policy Plane. The policy engine is the architectural centrepiece of Zero Trust. It evaluates access requests against policy in real time — not at authentication time, but continuously. Who is requesting access? What device are they on? What is the risk score of this session? What data are they attempting to reach? Every access decision should be evaluated against policy, with the answer being a contextual yes or no — not a permanent grant from a group membership.

The Enforcement Plane. Policy decisions must be enforced consistently — in the network, in the application, and at the data layer. This is where Zero Trust intersects with network architecture. ZTNA solutions replace VPN with identity-aware proxies. Micro-segmentation replaces flat network zones with workload-level controls. API gateways enforce policy at the application boundary.

The Five Failure Modes

Most Zero Trust programmes fail not because the technology is wrong, but because the architecture is incomplete. Here are the five failure modes Ergotech encounters most frequently:

  • Identity without device context. Enforcing strong authentication but ignoring device health signals. A user with a valid credential on an unmanaged, compromised device still gets access. Identity must be correlated with device posture continuously.
  • Policy without data classification. Without knowing what data a resource contains, you cannot write meaningful access policy. Zero Trust at the network layer is ineffective if the application layer grants broad access based on role alone.
  • Enforcement gaps in legacy systems. Zero Trust frameworks designed for cloud-native applications often hit a wall with legacy on-premises systems that do not support modern authentication. These gaps are frequently underestimated.
  • Static group membership as proxy for policy. Active Directory groups are not Zero Trust policy. Conditional access should evaluate dynamic attributes — session risk, device compliance state, and time of access — not static role assignments made months ago.
  • Treating ZTNA as the destination, not the journey. Deploying a ZTNA product and declaring Zero Trust achieved is a common mistake. ZTNA is a network enforcement mechanism. Without the identity and policy planes operating correctly, it is a VPN with a better user interface.

What a Mature Zero Trust Architecture Looks Like

In a mature implementation, the experience of a legitimate user is seamless — they authenticate once, their device posture is verified automatically, and access is granted dynamically based on their current context. High-risk actions trigger step-up authentication. Access to sensitive data requires additional verification. Sessions are continuously re-evaluated, not just at the point of login.

The goal of Zero Trust is not to make access harder for legitimate users. It is to make lateral movement and privilege escalation catastrophically difficult for adversaries who have already crossed the perimeter.

For adversaries, a mature Zero Trust environment is radically more hostile. Credential theft alone is insufficient — the device must also be compliant. Lateral movement is constrained by micro-segmentation. Privileged access requires just-in-time elevation with full session logging. There is no "inside the network" from which an attacker can operate freely.

Getting Started

Zero Trust is a multi-year architectural journey, not a project with a go-live date. The sequence matters enormously. Ergotech recommends starting with identity and working outward — get your identity plane right before you attempt to enforce policy at the network or data layers. A common and expensive mistake is to start with network segmentation, which is disruptive, complex, and ultimately ineffective without a functioning identity and policy layer underneath it.

Assess your current state honestly. Where does implicit trust exist in your environment today? VPN-connected devices with broad LAN access? Service accounts with domain admin privileges? These are the attack surfaces Zero Trust is designed to eliminate. Start there.

If you would like to discuss a Zero Trust assessment or architecture programme for your organisation, get in touch.