Why does relying on ZTNA alone leave organisations exposed to lateral movement risk?

ZTNA primarily controls north south access, so it can reduce exposure at the entry point without addressing what happens inside the network after initial access is granted. If an endpoint is breached or a user is tricked into harmful action, an attacker may still move laterally unless internal traffic is tightly constrained. That is why segmentation is needed to cover the internal attack path.

Why ZTNA reduces entry-point exposure but not internal movement

ZTNA is strongest at controlling who can reach a protected application or resource from the outside. That does not automatically restrict what an authenticated endpoint or user can do once inside the trusted boundary. If an attacker lands on a device, steals a session, or abuses a legitimate identity, the remaining risk is often east-west movement, which ZTNA alone does not fully contain.

How lateral movement happens after the first connection

Once initial access exists, attackers look for reachable internal services, weak segmentation, reused credentials, and permissive trust between systems. That is why compromise often spreads beyond the original foothold. Enterprise attack patterns in MITRE ATT&CK Enterprise Matrix consistently show credential access, remote service use, and lateral movement as separate phases, not a single control problem.

ZTNA can reduce exposure to the entry path, but lateral movement is a different control plane. The internal question becomes whether one compromised device, account, or token can reach additional systems. If the answer is yes, the organisation still has a containment problem even if the front door is tightly controlled.

Why segmentation and identity controls must complement ZTNA

Segmenting internal networks and tightening service-to-service trust narrows the blast radius after compromise. In practice, this means limiting which internal systems can talk to each other and enforcing least privilege between zones, not just at the perimeter. NIST’s zero trust model reinforces that posture: NIST SP 800-207 Zero Trust Architecture treats continuous verification and least privilege as runtime controls, not one-time access checks.

That is also why environment design matters as much as authentication design. Guide to SPIFFE and SPIRE is useful here because workload identity and mutual TLS are often the practical tools that reduce east-west trust between services. In other words, ZTNA may decide who enters, but segmentation and workload identity help decide how far a compromise can travel.

Risk and Threat Considerations

The main exposure is blast-radius expansion. A user, endpoint, or credential that is allowed to establish a valid session can still become a pivot point if internal systems trust that foothold too broadly. Attackers do not need to defeat ZTNA everywhere if they can exploit the internal trust that remains after first access.

Failure mechanism: Internal reachability, shared credentials, overbroad service trust, or flat network paths let an attacker reuse the first compromise to access additional systems, even when north-south access is well controlled.

Impact: The compromise can spread laterally, increase the number of affected systems, and turn a single session or endpoint breach into broader data theft, privilege escalation, or operational disruption.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	TA0008 — Lateral Movement	Lateral movement is the exact post-compromise risk described by the question.
Recommendation — Map internal pivot paths and constrain techniques that enable an attacker to move between systems.
NIST Zero Trust (SP 800-207)	PR.AA-05 — Network Segmentation	Segmentation is the stated complement to ZTNA for limiting internal attack paths.
	PR.AA-01 — Verify Explicitly	ZTNA depends on continuous verification of access requests, not implicit trust after entry.
Recommendation — Enforce segmentation so a single compromise cannot freely traverse internal zones. Verify each access request dynamically instead of trusting prior network location.
NIST SP 800-53 Rev 5	AC-4 — Information Flow Enforcement	Information flow control directly addresses limiting east-west movement after initial access.
	IA-2 — Identification and Authentication (Organizational Users)	Authenticated user access can still be abused for pivoting if identity is compromised.
	IA-9 — Identification and Authentication (Non-Organizational Users)	External or non-organizational access paths are relevant where ZTNA brokers access for users and devices.
Recommendation — Enforce information flow restrictions between internal systems and trust zones. Harden user authentication to reduce account takeover as an initial pivot point. Apply strong authentication for externally originating access paths and sessions.
OWASP API Security Top 10	API5 — Broken Function Level Authorization	Internal east-west movement often succeeds when functions remain reachable beyond intended privilege.
Recommendation — Check that internal functions cannot be invoked beyond the caller's authorised role.
CIS Controls v8	CIS-12 — Network Infrastructure Management	Network segmentation and controlled internal routing are the core mitigation for lateral movement risk.
Recommendation — Segment internal networks and restrict routes between sensitive zones.

Practitioner Guidance

What to prioritise: Treat ZTNA as one control layer, not the containment strategy. The first design question should be which internal paths would still remain open if a single authenticated endpoint were compromised.

What to verify: Validate that segmentation, service identity, and internal authorization actually restrict east-west traffic between applications, admin planes, and sensitive data zones. If you can move from one compromised workload or user context to another without a second policy decision, containment is too weak.

Practitioner takeaway: ZTNA reduces exposure at the edge, but only internal restriction turns that reduced exposure into real containment.