Zero Trust is the right model. It is also reliably failing to take hold in most large enterprise environments. Those two things are not in conflict.
The model is correct: never trust the network, always verify the identity, enforce least privilege at the resource level, assume breach. The failure is not conceptual. It is structural. Organizations are trying to apply a policy framework designed around explicit verification to environments built on implicit trust as a design principle. That is not a rollout problem. That is an architecture problem.
Flat networks were built to trust everything inside them
The standard enterprise network of the 2000s and 2010s treated the perimeter as the control point. Once you were inside — VPN-connected, domain-joined, physically present in the office — the network extended implicit trust laterally. Systems talked to systems without meaningful verification at each hop. That was not carelessness. It was the intentional design.
That assumption is baked into the infrastructure itself. Flat RFC 1918 address space, permissive internal ACLs, broadcast-domain-level trust, legacy protocols that have no authentication layer at all — NTLM relay still works in plenty of enterprise environments because the network assumes internal hosts are cooperating participants, not adversaries.
Microsegmentation is the obvious fix. It is also expensive, slow, and politically difficult. Every segment boundary is a firewall rule change request. Every rule change touches application owners who may not know their own communication paths. In large environments, application teams have no reliable inventory of which hosts talk to which, over which ports, on what schedule. The remediation project for flat network segmentation can take years and still leave large trust islands intact.
Zero Trust doesn’t wait for you to finish that project. Adversaries don’t either.
Service accounts are the real lateral movement infrastructure
Human identity programs get most of the attention in Zero Trust conversations. MFA enforcement, conditional access policies, device compliance checks, SSO consolidation — organizations spend real budget on this layer.
Service accounts don’t.
Most large organizations have thousands of service accounts. Many are shared across systems, have non-expiring passwords, have no MFA enrollment path, and are never reviewed as part of the normal access certification cycle. They exist because an application needed a credential and someone created one ten years ago. They persist because nothing broke when they weren’t removed.
In a flat network with implicit lateral trust, a compromised service account is a high-value movement vehicle. It is credentialed, it is non-human (so it doesn’t behave in obviously anomalous ways), and it often has access scoped to infrastructure rather than user data — which means it can reach authentication stores, backup targets, and deployment pipelines.
Zero Trust architecture, on paper, should catch this. Workload identity, mutual TLS, short-lived credentials, machine identity attestation — the NIST SP 800-207 guidance is clear enough about what the model requires at the workload layer. In practice, most programs don’t reach workload identity until after years of human identity work, and service accounts remain largely uncontrolled throughout.
Procurement pace makes enforcement aspirational
Here is a structural problem that architecture discussions rarely address: in large organizations, procurement decisions arrive faster than enforcement can be extended.
A new SaaS platform gets approved, integrated via SAML, and in production before the Zero Trust policy engine has a connector for it. A cloud-hosted analytics tool gets shadow-purchased by a business unit, integrated with a service account credential, and is transmitting sensitive data before anyone has reviewed the access model. A network appliance gets installed at a branch location by a vendor who needed console access and created a management account no one in IT knows about.
Zero Trust enforcement is a policy state that has to be explicitly extended to each new surface. But new surfaces appear continuously, and the organizational processes for reviewing them are slower than the processes for deploying them. The result is a persistent gap: the officially enforced perimeter excludes a meaningful portion of actual network participants.
That gap is not visible on the Zero Trust maturity dashboard. It shows up after an incident, when an asset no one fully controlled turns out to have been the initial access point.
What Zero Trust progress actually looks like
Progress metrics in Zero Trust programs tend toward the optimistic. Percentage of workforce using MFA. Percentage of endpoints under MDM. Number of applications behind conditional access. These are real and useful metrics.
They are not the same as “the environment is difficult to compromise laterally.”
An adversary who obtains one valid credential — through phishing, password spray, or service account abuse — can still move laterally in most enterprise environments that describe themselves as Zero Trust in progress. The question is not whether MFA covers the workforce. It is whether the environment has eliminated or meaningfully constrained implicit trust at the hop level.
That requires a different set of questions: what hosts can reach what other hosts with zero authentication? What service accounts have stale, over-privileged access and no monitoring on their use? What does a segment boundary actually prevent versus what it nominally exists on a diagram? What new systems came online in the last 90 days that haven’t been reviewed for access model consistency?
Those questions are uncomfortable because the answers are usually worse than the maturity slide suggests.
Bottom Line
Zero Trust fails in flat enterprise networks because the model requires explicit verification at each trust decision, and most large environments have years of infrastructure and procurement decisions that bypassed that requirement by design.
The framework is not the problem. The problem is the assumption that declaring a Zero Trust strategy changes the actual enforcement posture. It does not. Enforcement changes the posture. Enforcement is slower, more expensive, and politically harder than writing a strategy document.
The adversary is not reading your Zero Trust roadmap. They are reading your ACLs.