Why do legacy segmentation approaches create risk for Zero Trust programmes?

Legacy segmentation often locks security into network-centric boundaries that are harder to scale, less visible, and less aligned to modern workload movement. That makes continuous verification and application-centric control harder to achieve. In practice, the result is weaker containment, more operational friction, and a slower path to consistent Zero Trust enforcement across growing technology stacks.

Why legacy segmentation creates a Zero Trust gap

Legacy segmentation was designed to carve up a network, not to continuously verify every request. That matters because zero trust assumes trust must be earned at the point of access, using policy, identity, device, and context, not inferred from a subnet or VLAN. When segmentation is the main control, the programme can look modern while still relying on outdated boundary assumptions.

The practical weakness is that network zones are coarse, static, and often built around infrastructure ownership rather than application behavior. As workloads move across cloud, containers, remote access paths, and shared platforms, the old boundary becomes a poor proxy for risk. NIST’s Zero Trust Architecture guidance is explicit that access decisions should be made per request and per policy, not because traffic came from a trusted place, which is why NIST SP 800-207 Zero Trust Architecture is the clearest baseline for the shift.

For practitioners, the key issue is not that segmentation is useless, but that it is usually only one control layer. If it becomes the primary security model, teams tend to overestimate containment, underinvest in identity-centric policy, and miss east-west paths that are still allowed by design. In effect, the environment may be partitioned, but not truly verified.

What makes legacy boundaries operationally brittle

Legacy approaches tend to assume that “inside” is safer than “outside.” That assumption breaks down when applications are distributed, dependencies are dynamic, and lateral movement can happen through allowed channels. The more the estate depends on manually maintained rules, the more segmentation becomes a change-management problem instead of a security-control problem.

This is especially visible in hybrid estates where a simple business flow may cross data centres, cloud services, and third-party platforms. A network rule that once matched a stable application path can become stale after refactoring, autoscaling, or cloud migration. The result is either overblocking, which drives operational friction, or exceptions and broad allowlists, which quietly weaken containment.

Modern Zero Trust programmes usually replace coarse network trust with finer-grained controls such as application identity, request policy, and authenticated workload-to-workload access. That is why the workload identity model in Guide to SPIFFE and SPIRE is useful here: it shows how segmentation can be supplemented by strong workload identity rather than treated as a substitute for it.

Legacy segmentation also creates blind spots for service-to-service access. When teams cannot easily see which applications talk to which other applications, they often preserve broad network access for safety. That keeps systems working, but it slows the move toward application-centric enforcement and makes policy reviews harder to evidence.

Why Zero Trust programmes need identity-centric containment instead

Zero Trust programmes work best when the control point follows the subject being protected, meaning the user, workload, device, or agent, rather than the network segment. That is the central design difference. A segment can reduce exposure, but it does not by itself answer whether a specific request should be allowed now, from this context, for this resource.

Identity-centric segmentation is therefore more adaptive than legacy network zoning. It can express who or what is allowed to talk, under what conditions, and for which actions. That is also why a broader identity roadmap matters: if identity governance, access lifecycle, and privilege boundaries are weak, the programme will still inherit the limitations of old segmentation even if the tooling changes.

Zero Trust Identity Guide is relevant because it frames the programme around continuous access evaluation, identity-centric policy, and phased adoption across people, workloads, and devices. For organisations with mixed environments, that is the more durable pattern than trying to make legacy subnet design do a job it was never built to do.

Where workload and machine access are part of the picture, the identity question becomes even more important. A control that only knows source IP or network location will struggle to distinguish a legitimate service from a compromised one moving laterally from a permitted zone. Identity and access governance, not just segmentation, is what keeps the boundary meaningful as the stack grows.

Risk and Threat Considerations

Legacy segmentation can create a false sense of containment, especially when attackers exploit allowed east-west paths or when administrators widen rules to keep fragile systems running. The risk is not just that a perimeter is bypassed, but that the organisation thinks it has contained movement while the policy still permits broad internal reach.

Failure mechanism: Static zones, rule exceptions, and infrastructure-centric boundaries make it easier for lateral movement, misconfiguration, and stale access paths to survive as systems change. Once trust is anchored to location instead of verified identity and request context, compromised systems can often reach more than the design intended.

Impact: Containment weakens, blast radius grows, and the Zero Trust programme becomes harder to enforce consistently across cloud, remote access, and application layers. Operationally, teams spend more time maintaining exceptions and less time tightening policy.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	PR.AA-05 — Identity Management, Authentication and Access Control	Zero Trust access must be verified per request, not by network location.
Recommendation — Move access decisions from segmentation trust to policy enforced on each request.
NIST SP 800-53 Rev 5	SC-7 — Boundary Protection	Legacy segmentation is a boundary-control problem that affects containment and lateral movement.
Recommendation — Review boundary controls to ensure they support, rather than replace, identity-based access policy.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Zero Trust segmentation gaps are closed by stronger identity and access governance.
Recommendation — Align segmentation with IAM to enforce authenticated, least-privilege access paths.
ISO/IEC 27001:2022	A.8.22 — Segregation of networks	Segmentation design and review are directly relevant when legacy network boundaries shape access control.
Recommendation — Document and review network segregation so it does not conflict with modern access control requirements.
NIST CSF 2.0	PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited for authorized users, services, and devices	Zero Trust gaps arise when access still depends on the network instead of managed identities.
Recommendation — Use managed identities and access governance to replace implicit trust from network placement.

Practitioner Guidance

What to prioritise: Treat segmentation as a supporting control, then identify which access decisions still rely on network position instead of authenticated identity and policy. Those are the highest-value places to redesign first.

What to verify: Check whether east-west traffic is constrained by request-level policy, or only by boundary rules. If the answer depends on broad allowlists, the programme still has a legacy trust problem.

Common mistake: Replacing one set of firewall rules with another and calling it Zero Trust. If the control model still assumes the segment is trusted, the operating model has not changed enough.

Practitioner takeaway: The real test is whether access decisions still remain valid when the network boundary is removed, because that is when you know Zero Trust is being enforced rather than merely described.