Who is accountable when a breach expands because east-west traffic was left open?

Accountability sits with the teams that own identity policy, segmentation design, and privileged access governance. Frameworks such as NIST CSF and Zero Trust Architecture expect organisations to define and enforce boundaries, not assume internal traffic is safe by default.

Why This Matters for Security Teams

When east-west traffic is left open, the breach rarely stays at the point of entry. Lateral movement turns a single compromise into a domain-wide incident because internal trust is assumed instead of continuously verified. Accountability therefore lands on the teams that define segmentation, identity policy, and privileged access boundaries, not only on the responders who discover the spread after the fact.

This is exactly why NIST SP 800-53 Rev. 5 treats access enforcement and boundary protection as ongoing control obligations, not one-time architecture decisions, and why NIST’s Zero Trust guidance rejects “inside equals trusted” as a security model. NHIMG’s breach research has shown how quickly stolen credentials can be operationalized once attackers gain a foothold, as seen in TruffleNet BEC Attack — Stolen AWS Credentials and the broader patterns catalogued in The 52 NHI breaches Report.

In practice, many security teams encounter the true cost of open east-west paths only after an attacker has already moved from one workload to several others, rather than through intentional segmentation testing.

How It Works in Practice

Accountability becomes clearer when the control chain is broken down into ownership domains. Network teams typically own segmentation design, identity teams own how workloads authenticate to each other, and PAM teams own whether privileged paths can be abused once an attacker lands. If east-west traffic is unrestricted, those controls fail together: an exposed service account, a reused token, or a poorly scoped machine identity can all become a bridge into adjacent systems.

For practitioners, the practical question is not just “who allowed it?” but “who was responsible for preventing internal trust from becoming default trust?” That answer is usually shared across architecture, platform engineering, IAM, and governance. NIST SP 800-53 Rev. 5 emphasizes control families that map directly to this problem, especially boundary protection and access control. Zero Trust Architecture, as described by NIST, is built around continuously evaluated access decisions rather than implicit trust based on network location.

• Define ownership for east-west segmentation rules at the same level as firewall policy ownership.
• Require workload identity for service-to-service calls so access is tied to the workload, not the subnet.
• Use privileged access boundaries for admin channels, break-glass paths, and orchestration systems.
• Review internal traffic paths after every material application or infrastructure change.

NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now explains why non-human identities become the practical attack path once network boundaries are porous, and the 52 NHI Breaches Analysis shows that credential exposure often becomes an access expansion problem, not a single-system event. These controls tend to break down when legacy flat networks, shared service accounts, and exception-heavy change processes make internal reachability broader than the team’s actual policy model.

Common Variations and Edge Cases

Tighter east-west controls often increase operational overhead, requiring organisations to balance blast-radius reduction against deployment friction, troubleshooting complexity, and service dependency drift. That tradeoff is real, especially in hybrid environments where older systems cannot easily support workload identity or fine-grained policy enforcement.

Best practice is evolving, but current guidance suggests using phased segmentation rather than all-at-once isolation. High-value paths such as identity providers, secrets stores, CI/CD runners, and admin tooling should be prioritized first because those are the routes attackers most often use to widen access. In mixed environments, some teams still rely on network zones alone, but that is increasingly seen as insufficient without accompanying identity-based checks.

There is no universal standard for this yet, but mature programmes usually document exception handling explicitly: who can approve open east-west paths, how long the exception lasts, what compensating controls apply, and when the risk is revalidated. Accountability becomes hardest to assign when platform teams own the routing layer, app teams own the services, and security owns the policy, yet no one owns the end-to-end outcome.

That is why practitioners should treat open east-west traffic as a governance issue as much as a technical one, and why breach expansion often reflects control drift rather than a single missed rule. In environments with rapid microservice churn, security ownership gaps, or unmanaged machine identities, the guidance breaks down because policy cannot keep pace with the rate of change.

Related resources from NHI Mgmt Group

• Who is accountable when material impact thresholds are not defined before a breach?
• Who is accountable when lateral movement leads to a breach?
• Who is accountable for resilience when internal access paths remain open?
• Who is accountable for breach-ready zoning and survivability planning?