Is Zero Trust actually working?

The security industry spent the better part of two decades telling enterprise leaders a comfortable story: build a perimeter strong enough, and the inside stays safe. We installed firewalls, configured VPNs, and treated the local network like a medieval castle moat. If you possessed a valid IP address on the internal network, you were trusted.

That architecture was built for a world that no longer exists. Today, applications live across multi-cloud environments, employees connect from anywhere on an array of devices, and supply chain integrations mean your systems are constantly exchanging data with external entities. The moat didn't just shrink; it evaporated entirely.

To solve this, the technology sector embraced a new philosophy: Zero Trust. Built on the core principle of "never trust, always verify," Zero Trust abandons implicit trust based on network location. Every request, user, and device must be explicitly authenticated, authorised, and encrypted before access is granted.

Yet, as billions of pounds flow into Zero Trust deployments worldwide, an uncomfortable rift is forming across the technology landscape.

On one side, security architects and CISOs argue that Zero Trust is the only viable paradigm capable of preventing catastrophic lateral movement during a breach. On the other side, software engineers, IT administrators, and operational leads argue that Zero Trust has devolved into a multi-billion-pound marketing rebrand, one that delivers operational gridlock, degrades developer velocity, and replaces real risk reduction with an unmanageable stack of vendor tooling.

Is Zero Trust an essential architectural evolution, or is it the most expensive buzzword in modern enterprise technology?

The Promise: Why Implicit Trust Had to Die

To understand why Zero Trust gained such overwhelming momentum, you only have to look at how modern breaches unfold. Traditional perimeter security operates on binary trust. Once an attacker bypasses the edge, whether through a phishing campaign, a compromised credential, or an unpatched public-facing vulnerability, they gain unfettered access to the internal network.

From there, lateral movement is trivial. Attackers reconnaissance internal systems, escalate privileges, locate sensitive databases, and deploy ransomware or exfiltrate intellectual property at leisure. The average dwell time for an attacker inside a perimeter-defended network historically stretched into months, simply because internal systems lacked the mechanisms to question why a workstation in marketing was suddenly querying a production database in finance.

Zero Trust fundamentally shifts this posture through three core principles:

• Explicit Verification: Always authenticate and authorise based on all available data points, including user identity, location, device health, service or workload, data context, and anomalies.

• Least Privilege Access: Limit user and system access with Just-In-Time (JIT) and Just-Enough-Access (JEA) policies, protecting both data and productivity.

• Assume Breach: Minimise blast radius by segmenting access by network, user, devices, and application awareness. Encrypt all end-to-end communications and utilise analytics to gain visibility and drive threat detection.

  
  

When implemented as intended, Zero Trust turns a flat network into a series of isolated micro-environments. An attacker who steals a single set of user credentials finds themselves trapped in a digital room with no doors. They cannot scan the broader network, they cannot reach adjacent servers, and their unusual activity triggers automated isolation protocols before damage escalates.

For organisations facing sophisticated cyber threats, regulatory oversight, and complex hybrid environments, this model is not just attractive; it feels mathematically imperative.

The Frustration: Operational Gridlock and Vendor Hype

If the theoretical model of Zero Trust is so logically sound, why is pushback growing among technical teams?

The reality on the ground often looks starkly different from the vendor slide decks. While Zero Trust is fundamentally an architectural strategy, it has been aggressively commercialised by the vendor ecosystem. Organisations are bombarded with pitches claiming that buying a specific Secure Access Service Edge (SASE), Identity and Access Management (IAM), or Endpoint Detection and Response (EDR) platform will instantly render them "Zero Trust Compliant."

This product-first approach creates several severe operational friction points:

• Developer Velocity Takes a Hit: Software engineering teams thrive on low-friction environments. When accessing a staging environment, running a database query, or deploying a microservice requires multi-factor re-authentication, step-up verification, and complex jump-host routing every twenty minutes, productivity plummets. Engineers naturally begin searching for workarounds, creating shadow IT systems that are far less secure than the legacy network they replaced.

• The "Shelfware" and Complexity Trap: Zero Trust is'nt a single tool you can buy off the shelf. Achieving true micro-segmentation and continuous identity verification across legacy legacy applications, on-premises servers, and cloud infrastructure requires painstaking mapping of every data flow within an enterprise. Most organisations lack the resources or visibility to complete this mapping. The result? Companies buy expensive Zero Trust platforms, implement them partially over top-level services, and leave core legacy assets untouched, creating a complex, fragile tech stack that frustrates users without actually eliminating systemic risk.

• Administrative and Policy Fatigue: Maintaining dynamic, context-aware access policies across tens of thousands of workloads, users, and third-party vendors creates massive administrative overhead. Security operations teams find themselves overwhelmed by policy management, false-positive alerts, and ticket queues from employees who cannot access the tools they need to do their jobs.

When security controls actively impede business operations, the business eventually forces security to compromise. The strict Zero Trust policies get softened, exceptions are granted for executives and key developers, and the architecture reverts to a patched-up version of the old model, just with a much higher price tag.

The Supply Chain Variable: Is Internal Zero Trust Missing the Point?

The debate becomes even more complex when evaluating where modern enterprise risk actually originates.

Much of the internal friction caused by Zero Trust implementations stems from locking down trusted internal users. However, recent data highlights that a substantial portion of critical security incidents do not begin with a rogue insider or a brute-forced employee login. They originate through third-party vendor connections, software supply chains, and unpatched public-facing vulnerabilities.

If an organisation spends two years and millions of pounds implementing granular, micro-segmented identity verification for its internal staff, but relies on third-party software that contains an unmonitored zero-day vulnerability or missing DMARC controls, the zero-trust perimeter still fails.

Opponents of rigid Zero Trust strategies point out that zero-trust models often over-index on user identity and access management while under-investing in basic attack surface management, exposure triage, and third-party risk mitigation. Securing access to an application is meaningless if the application itself contains vulnerabilities that allow remote code execution, bypassing identity controls entirely.

Finding the Middle Ground: Pragmatic Security Architecture

The tension between security advocates and operational leaders isn't going away, but the path forward requires moving past all-or-nothing dogmatism. Zero Trust is neither a useless marketing myth nor a flawless silver bullet. It's an ideal target state that must be balanced against operational realities.

To make security architecture work without crippling productivity, technical leadership must adopt a pragmatic framework:

• Decouple Philosophy from Procurement: Acknowledge that you cannot buy "Zero Trust in a box." Before purchasing additional tooling, focus on fundamental security hygiene: vulnerability management, rigorous patch cycles, and visibility into existing assets.

• Prioritise Friction Based on Risk: Not every system requires the same level of verification. A public marketing website does not need the same zero-trust controls as the production database containing customer financial records. Applying heavy-handed authentication barriers universally destroys user trust and productivity. Focus zero-trust controls where the blast radius of a breach would be fatal to the business.

• Treat Developer Experience (DX) as a Core Security Metric: If a security policy makes a developer's job twice as hard, it's a bad security policy. Security teams must collaborate with engineering leads to build zero-trust controls directly into existing developer workflows, using automated identity tokens, frictionless single sign-on (SSO), and transparent network routing.

• Focus on continuous, passive monitoring over disruptive active barriers: Verification doesn't always have to mean prompting a user for a push notification or password. Modern risk engines can continuously assess user behaviour, device posture, and network telemetry in the background, intervening only when an actual anomaly or elevated risk score is detected.

  
  

The Verdict

Is Zero Trust actually working?

As a conceptual model, yes. The core premise that network location equals trust is demonstrably dead, and continuing to rely on perimeter defences in a cloud-first, hybrid world is negligence.

However, as an operational reality in many organisations, Zero Trust is struggling under the weight of vendor hype, architectural over-engineering, and user friction. When implemented as a rigid, tool-heavy mandate without regard for operational workflow, it frequently fails to deliver the promised security gains while actively harming business performance.

The future of enterprise security belongs not to those who blindly buy into every vendor's Zero Trust narrative, nor to those who cling to outdated perimeter moats. It belongs to pragmatic leaders who understand that true resilience lies in balancing continuous risk mitigation with seamless operational execution.

What is your organisation's experience with Zero Trust? 

Has it successfully reduced your attack surface, or has it introduced unsustainable operational friction for your technical teams?