What you'll take away
Zero Trust is the most over-marketed concept in cybersecurity. Ask any vendor and they will tell you their product delivers Zero Trust. Ask any enterprise security leader and you will hear about a Zero Trust strategy they are implementing. But probe beneath the surface and you will find that most organisations have bought products without understanding principles — and as a result, they remain fundamentally exposed.
Zero Trust is not a firewall, an identity product, or a segmentation tool. It is an architectural philosophy: never trust, always verify. Every user, every device, every workload, and every request must authenticate and be authorised for every interaction — regardless of whether it originates inside or outside the corporate network. The perimeter is dead. The question is whether your architecture knows it.
Why the Perimeter Model Failed
Traditional network security was built on a fortress model. Build a strong wall, trust everything inside it. For decades, that was sufficient because most sensitive systems sat in on-premise data centres and most employees worked within physical offices on managed devices.
Cloud infrastructure, remote work, SaaS applications, and contractor access destroyed this model in under a decade. Today, the inside of a corporate network is a fiction. Data lives in dozens of SaaS platforms. Employees connect from unmanaged home networks. Third-party integrations reach directly into production systems. Adversaries have learned that once they breach the perimeter, they can move laterally through a flat, trusted internal network almost without friction.
The result is that perimeter investments — next-generation firewalls, VPNs, network segmentation — provide a front door that attackers increasingly bypass entirely. In 2024, 68% of confirmed data breaches involved the human element, including credential theft, social engineering, and exploitation of trusted third parties (Verizon DBIR 2024). None of these attacks required breaking the perimeter. They walked through it with legitimate credentials.
What Zero Trust Actually Means
Zero Trust Architecture (ZTA) is built on three core principles, first formalised by John Kindervag at Forrester in 2010 and codified in NIST SP 800-207:
- Verify Explicitly — Always authenticate and authorise based on all available data points: identity, location, device health, service or workload, data classification, and anomaly signals. Trust is earned per request, not granted by network location.
- Use Least Privilege Access — Limit access rights to the minimum necessary for each user, device, and workload. Reduce blast radius. Time-bound privileges where possible. Never grant standing administrative access.
- Assume Breach — Design and operate as if adversaries are already inside. Segment networks. Encrypt all traffic. Monitor for lateral movement. Practice containment, not just prevention.
These principles sound straightforward. Implementing them across a heterogeneous enterprise environment — mixing legacy on-premise systems, multi-cloud workloads, SaaS applications, and thousands of human and machine identities — is one of the most complex engineering challenges in modern enterprise IT.
The 3 Most Expensive Zero Trust Mistakes
1. Treating Zero Trust as a Single Product Purchase
Vendors are delighted when you treat Zero Trust as a purchasing decision. Buy their identity platform or their micro-segmentation tool and you can check the Zero Trust box. The problem: Zero Trust is an architecture, not a point solution. No single product implements it. A new identity platform without enforced device health checks and without data classification creates a Zero Trust veneer over a fundamentally permissive environment.
A component is not an architecture. An identity gateway that authenticates every login but grants blanket access to every resource once authenticated is not Zero Trust. It is perimeter security rebranded. You have moved the trust boundary from the network edge to the identity layer — which is progress, but not Zero Trust.
2. Ignoring East-West Traffic
Most Zero Trust programmes start at the north-south perimeter — securing access from users to applications. What they consistently under-invest in is east-west traffic: the communication between workloads, services, and systems inside the network.
In the SolarWinds supply chain attack, the entry vector was not a user credential failure. Once inside, the attacker moved laterally through east-west paths that no one was monitoring or restricting. Flat internal networks remain the norm in the majority of enterprise environments — even those running Zero Trust user access programmes at the front door.
Micro-segmentation of east-west traffic is not optional in a genuine Zero Trust architecture. If your implementation stops at the user access layer, you have addressed only one dimension of a multi-dimensional problem.
3. Missing Machine Identities
Human identities are the obvious starting point. But in a modern cloud environment, machine identities — service accounts, API keys, workload certificates, container credentials — outnumber human identities by orders of magnitude. Most organisations have no centralised inventory of machine identities, let alone lifecycle management or access controls for them.
This is where attackers increasingly focus. Compromising a service account with excessive permissions — a common finding in Cloud Security Posture Management assessments — can yield lateral movement paths that bypass every human identity control in the architecture.
Is your security posture audit-ready?
48-hour turnaround. No obligation.
The Five Pillars — And Where to Start
NIST and CISA define Zero Trust across five interdependent pillars. Each must mature in parallel for the architecture to hold:
- Identity — Centralised identity management, MFA everywhere, conditional access policies, privileged access management (PAM), and just-in-time access. Identity is where every Zero Trust journey should start. It is the new perimeter.
- Devices — Continuous device health verification before access is granted. Every endpoint — managed or unmanaged — must pass a posture check covering OS patch level, EDR presence, and disk encryption before accessing sensitive resources.
- Network — Micro-segmentation, encryption of all internal traffic, and DNS security. East-west traffic treated with the same scrutiny as external traffic.
- Applications & Workloads — Application-level access control rather than network-level. WAAP (Web Application and API Protection), OAuth/OIDC for every service-to-service call, workload identity federation.
- Data — Data classification, DLP (Data Loss Prevention), and encryption at rest and in transit. Access rights governed by data sensitivity labels, not role alone.
The practical sequence for most enterprises: start with Identity — it delivers the fastest risk reduction. Implement Device trust in parallel, then move to Network segmentation, Application access controls, and Data classification as each prior pillar matures.
What a Zero Trust Maturity Assessment Looks Like
A Zero Trust Maturity Model maps current state across each of the five pillars on a scale from Traditional to Initial to Advanced to Optimal. Most enterprises land at Initial on two or three pillars and Traditional on the remaining two — meaning they have some controls but not the systematic verification and least-privilege enforcement that makes Zero Trust meaningful.
The output of a maturity assessment is a sequenced remediation roadmap: which controls to implement first, the risk reduction impact at each step, and what implementation cost and timeline looks like. The goal is not to reach Optimal on every pillar simultaneously. It is to eliminate the highest-risk gaps systematically, quarter by quarter.
The most common finding in Zero Trust assessments: organisations have strong perimeter controls and weak east-west segmentation. The gap is almost always in machine identity management and lateral movement paths — which are also the vectors attackers exploit most reliably.
Zero Trust in Practice — What Changes Day to Day
For end users, a mature Zero Trust environment is barely visible — until access is denied. Conditional access policies mean that a login from an unmanaged device or an anomalous location is challenged with MFA or denied access to sensitive resources until trusted context is established. The experience is deliberately frictionless for low-risk access and deliberately challenging for high-risk access.
For engineering teams, Zero Trust is a development constraint. Service-to-service communication requires mutual TLS and workload identity certificates. Database access is managed through a secrets manager, not hardcoded credentials. Infrastructure-as-code pipelines must pass security policy checks before deployment. These are not obstacles — they are architectural disciplines that reduce the blast radius of every future incident.
Where GYSP Starts
GYSP's Cyber Security practice begins every Zero Trust engagement with a maturity assessment across all five pillars. We identify the highest-risk gaps, sequence the remediation roadmap around risk reduction rather than vendor preference, and implement controls that work within existing tooling investments wherever possible.
The goal is not to declare Zero Trust implementation complete. It is to make the blast radius smaller than it was last quarter — and to be able to prove it.
“Zero Trust is not a destination. It is a discipline. The organisations that get it right do not ask 'are we Zero Trust?' — they ask 'what can we verify today that we could not verify last quarter?'”
— Dhaval S, Network & Security Lead — GYSP.tech
