Why Enterprise Zero-Trust Initiatives Stall at the Access Layer

Zero-trust security has been the stated direction of enterprise network architecture for several years. The premise is sound. Instead of trusting traffic because it originates inside the corporate network, every request is authenticated, authorised, and logged at the application layer. Network location stops being a proxy for identity. The mandate travels easily through procurement documents and board presentations. The execution does not.

Most large organisations can describe a zero-trust end state. Few can reach it. The programmes stall in the same places across industries, finance, healthcare, manufacturing, and government. The stalls are not caused by a single technology gap. They accumulate at the boundary between the new identity-driven model and the legacy systems that still carry the actual business traffic.

The perimeter was never the hard part

Zero-trust initiatives are often framed as replacing the perimeter. In practice, the perimeter firewall was the easiest component to reconfigure. Next-generation firewalls already inspect traffic at the application layer and integrate with identity providers. Security teams have years of operational experience with them. Replacing rule sets and migrating inspection policies is slow work, but it is bounded work with a clear owner.

The hard part is the network behind the firewall. Inside most corporate environments, the internal network is flat. Decades of growth have produced address ranges that were assigned for convenience, overlapping subnets that cannot be summarised, and applications that communicate by hardcoded IP addresses rather than DNS. A zero-trust model assumes that traffic between any two points can be intercepted, identified, and authorised. In a flat network with undocumented dependencies, that assumption breaks immediately.

Legacy applications hold the network hostage

The single largest cause of zero-trust stalls is the application portfolio. Internal tools, line-of-business applications, and vendor-supplied management consoles were built on the assumption that the internal network was trusted. They communicate over fixed ports, expect direct database connections, and authenticate using protocols that predate modern identity federation. They cannot be wrapped in an identity-aware proxy without a rewrite.

Rewriting them is rarely an option. The original vendor no longer exists, or the application is past its support window but still in daily use. The business unit that depends on it has no budget for a replacement. The security team has no authority to force a migration. The application stays, and the zero-trust policy carves out an exception for it. One exception becomes a pattern. Within a year, the policy is a list of exceptions surrounding a small core of compliant traffic.

This is how a zero-trust initiative degrades into a VPN with extra steps. The identity-aware proxy handles the modern applications. The legacy estate continues to sit on the flat internal network, reachable through a tunnel that bypasses the new controls entirely. The architecture diagram shows zero trust. The traffic capture shows something closer to the network that existed before the project started.

The VPN becomes the unresolved dependency

Virtual private networks were supposed to disappear under zero trust. They have not. In most enterprises, the remote access VPN is still the primary way employees reach internal resources. The reason is practical. A VPN gives broad network access with minimal configuration. An identity-aware proxy gives narrow application access but requires every application to be catalogued, registered, and configured.

Cataloguing applications is the work that does not get done. No team owns a complete inventory of internal applications, their dependencies, and their user populations. The discovery exercise that precedes a zero-trust deployment usually surfaces hundreds of undocumented services, many of them running on servers that nobody remembers provisioning. Each one becomes a decision: enrol it, block it, or leave it on the VPN. Under operational pressure, the default choice is to leave it on the VPN.

The VPN therefore survives as a bridge to the flat internal network. Every device that connects through it re-enters the trusted zone that zero trust was meant to eliminate. The security model now has two regimes, one for applications that have been onboarded onto the identity-aware proxy, and one for everything that still flows through the tunnel. The split is rarely documented, which means incidents that cross the boundary are hard to investigate.

Device posture is assumed, not verified

Zero-trust architecture calls for device posture checks at every access decision. The system should refuse to grant access to a managed application from a device that is unmanaged, unpatched, or non-compliant. The principle is clear. The implementation depends on having a reliable inventory of devices, a working posture agent, and a consistent policy for exceptions.

Device inventories are unreliable in most enterprises. Laptops are reimaged without being deregistered. Virtual machines are spun up for testing and forgotten. Personal devices appear on the network through bring-your-own-device channels that were opened during a past remote-work transition and never closed. The posture agent that is supposed to report on each device depends on an enrolment process that does not cover the full fleet.

When posture cannot be verified, the policy falls back to user identity alone. A valid login from an unknown device is treated the same as a valid login from a managed laptop. This collapses zero trust back toward the model it replaced, where a single credential grants broad access. The device posture layer that was supposed to add assurance instead becomes a formality that is acknowledged but not enforced.

Logging is collected but not connected

A zero-trust model generates a richer audit trail than a perimeter model. Every access decision produces a record of the user, the device, the application, and the policy that allowed or denied the request. In theory, this gives investigators a complete picture of who did what. In practice, the logs are collected but not correlated.

Identity providers, proxy gateways, endpoint agents, and application logs each write to separate stores. A request that passes through four systems produces four records that do not share a common identifier. Reconstructing a session requires joining logs across time zones, clock skew, and retention boundaries. Most security operations teams do not have the engineering capacity to build that join, so they fall back on the proxy log alone, which shows the decision but not the context behind it.

The result is that zero-trust deployments often improve the granularity of access control without improving the quality of investigation. More data is captured, but the data is harder to use. Incidents that would have been traceable in a simpler architecture become diffuse across a larger surface, and the response depends on manual correlation that happens too slowly to matter.

What successful programmes do differently

The organisations that make genuine progress on zero trust share a few traits. They start with the application inventory rather than the firewall, accepting that the hard work is understanding what runs on the network and who uses it. They narrow the VPN deliberately, removing one application at a time, rather than attempting a single cutover. They accept that some legacy applications will never be compliant and plan a managed retirement rather than an indefinite exception.

They also treat device posture as an operational programme, not a checkbox. That means funding the enrolment work, the exception review, and the quarterly reconciliation between the inventory and the real fleet. Without that funding, the posture layer is decorative, and the access decisions rest on identity alone.

Most importantly, they communicate that zero trust is a multi-year programme of network hygiene, not a product deployment. The stalls described here are not failures of architecture. They are failures of scope. Programmes that scope zero trust as a firewall project discover the flat network too late. Programmes that scope it as an application and identity programme start where the actual work is, and they make slower but real progress toward a network where location no longer implies trust.