How should security teams use Zero Trust Segmentation alongside ZTNA to contain breaches inside the environment?

How ZTNA and Zero Trust Segmentation work together

ZTNA and Zero Trust Segmentation solve different parts of the access problem. ZTNA governs who can reach an application from outside the environment, while segmentation constrains what an already connected endpoint or server can talk to once it is inside. Used together, they reduce both initial access paths and the ability of compromise to spread.

That distinction matters because many breaches are not stopped by perimeter-style access controls alone. If an attacker lands on a device, gains a foothold in a server, or abuses a legitimate session, the limiting factor becomes east west movement, not remote entry.

What Zero Trust Segmentation adds after ZTNA has granted access

Zero Trust Segmentation is the containment layer. It applies granular allow rules between workloads, servers, users, and endpoints so that communication only occurs for explicitly approved flows. In practice, that means a compromise does not automatically become an environment-wide incident just because one application was reachable through ZTNA.

The strongest deployments treat the two controls as complementary, not interchangeable. ZTNA can authenticate and broker access to the front door of a service, but segmentation defines the internal trust boundaries that prevent a connected host from freely discovering, probing, or pivoting to adjacent systems. For teams building workload identity and trust boundaries, Guide to SPIFFE and SPIRE is useful background on how strong workload identity supports this model.

This is especially important in flat networks, shared service tiers, hybrid estates, and environments with legacy protocols. If east west rules are broad, ZTNA may still leave too much room for lateral movement after the first authenticated hop.

How to design containment so a breach stays small

Security teams should design segmentation around application and workload dependencies, not around general network convenience. The practical objective is to make every permitted communication path explicit, minimal, and observable. Where possible, segment by service tier, environment, tenant, or trust zone, and avoid broad subnet-level trust that lets one compromised host reach many peers.

Containment also depends on how well the rules reflect actual traffic patterns. If the policy is too coarse, teams keep “temporary” exceptions that quietly expand blast radius. If the policy is too strict, operations teams bypass it. Good designs balance enforcement with service discovery, change management, and exception review so the control remains usable under real production conditions.

For infrastructure that is especially sensitive to movement and trust collapse, NIST’s Zero Trust Architecture is the clearest external reference for the “never trust, always verify” model, and NIST SP 800-82 Rev 3 shows why segmentation is often essential when east west containment is a primary control objective.

Why breach containment fails in practice

Containment usually fails for a few repeatable reasons: too much shared trust, incomplete asset and dependency inventory, weak exception handling, and policies that do not match real application behavior. Once one path is exempted for troubleshooting or compatibility, that exemption often becomes the attacker’s shortest route to lateral spread.

Another common failure is assuming that authenticated access means safe access. ZTNA may prove a user or device before connection, but it does not guarantee the endpoint is uncompromised after entry. Segmentation is what limits the consequences when that assumption breaks.

Where segmentation is being implemented across workloads and service-to-service paths, SPIFFE workload identity specification is a useful reference for making internal trust more explicit, and The 52 NHI Breaches Report helps illustrate how quickly compromise can expand once credentials or service access are over-broad.

Risk and Threat Considerations

The main risk is not failed remote access, but failed containment. If an attacker gains one valid foothold, weak east west controls can turn a single endpoint or server compromise into broad internal reach, especially where service accounts, shared admin paths, or legacy ports are permitted too widely.

Failure mechanism: ZTNA authenticates entry, but broad internal connectivity, permissive allowlists, or unmanaged exceptions let the attacker move laterally, probe internal systems, and reach higher-value assets with the same foothold.

Impact: The breach radius increases, detection becomes harder, and recovery becomes more disruptive because teams must assume multiple internal systems may have been touched.

Practitioner Guidance

What to prioritise: Build segmentation around the internal attack path you want to break, not around the network topology you inherited. If a compromise of one workstation or server can still reach many peers, ZTNA is helping with entry control, but not with containment.

What to verify: Review whether every allowed east west flow maps to a real application dependency, whether exception rules expire, and whether logging shows denied movement attempts that indicate the policy is actually constraining spread.

Practitioner takeaway: Treat ZTNA as the front door control and Zero Trust Segmentation as the blast-radius control, because breach containment depends on both.

Related resources from NHI Mgmt Group

• How should public sector security teams use zero trust segmentation to reduce the impact of breaches and ransomware attacks?
• How should federal and enterprise security teams implement Zero Trust when they know breaches can already be inside the environment?
• How should security teams use cloud detection and segmentation together to contain breaches faster?
• How should security teams use AI and machine learning to improve zero trust segmentation without breaking applications?