At some point in the last few years, "zero trust" became the kind of phrase that appears in board presentations without anyone in the room being sure what it means. Vendors use it to mean their product. Frameworks use it to mean an architectural principle. Neither definition is wrong, exactly, but the gap between the two creates a specific kind of confusion: organisations that believe they have implemented zero trust because they purchased something.
What the principle actually says
The core idea is straightforward. In a traditional perimeter model, systems inside the network are implicitly trusted once they have passed the edge. In a zero trust model, trust is not granted based on network location. Every request — regardless of where it originates — must be authenticated, authorised, and continuously validated.
That is the whole thing. It is not a product category, it is a stance on how access decisions should be made. The practical implications of that stance are substantial, and that is where most implementations run into trouble.
Where implementations break down
The most common failure we see is partial implementation. An organisation installs a product that handles identity-aware access for its SaaS tools but leaves the internal network operating on flat trust. An attacker who compromises a machine on that internal network then has lateral movement options that zero trust architecture was meant to eliminate.
The second failure is identity depth. Zero trust depends on robust identity infrastructure — multi-factor authentication, device health checks, short-lived credentials. These are not hard to implement individually, but they require coordination across identity providers, endpoint management, and application configuration. Organisations with Active Directory environments that have grown organically over a decade often find the identity cleanup project takes longer than anticipated.
"We kept finding systems that authenticated over the VPN but bypassed MFA because they used a legacy authentication protocol that pre-dated the policy. Zero trust assumes you have a complete inventory of how things authenticate."
The inventory problem
You cannot apply consistent policy to systems you do not know about. Every zero trust implementation project we have observed — either as part of an assessment or in post-incident reviews — has hit the same obstacle: an incomplete inventory of systems, services, and their authentication methods.
This is not a security-specific problem. It is an operational one. Shadow IT, systems installed by contractors years ago, services that still run on internal servers because migration was always deprioritised — these create gaps in any zero trust policy regardless of how well-designed that policy is.
The practical advice is to treat the inventory work as a prerequisite, not as something that happens in parallel with implementation. Policy applied to an incomplete map of your environment is not zero trust; it is partial trust with gaps you cannot see.
What a realistic path looks like for a 200-person company
Complete zero trust implementation is a multi-year programme for most organisations. For a company in the 50–500 employee range that does not have dedicated security architecture staff, the question is where to start and what actually reduces risk in the near term.
Based on what we see in assessments, the highest-value starting points are usually: enforce MFA everywhere, with no exceptions for legacy protocols; implement conditional access policies that check device health for sensitive resources; and segment the network so that a compromised machine cannot reach everything. These three things do not require calling it zero trust. They just reduce the impact of a successful attack.
The rest — microsegmentation at the application layer, continuous trust evaluation, full SIEM integration — is worth working toward, but starting there without the basics creates an expensive project with gaps in the foundation.