Segmentation often fails because it separates machines and subnets, while attackers pivot through stolen tokens, forged identities, and trusted sessions. Once the attacker can operate inside a valid authentication context, many network controls cannot distinguish legitimate traffic from hostile reuse of trust.
Why This Matters for Security Teams
Segmentation is still useful, but it is not a complete answer to lateral movement because most modern attacks do not rely on raw network traversal alone. They reuse trusted identity, tokens, and sessions to move inside environments without triggering simple subnet boundaries. That is why controls built around where traffic is coming from often miss what the workload is actually authorized to do.
For security teams, the real issue is that trust has shifted upward from packets to identities. Once an attacker steals an API key, cloud token, service account credential, or browser session, the perimeter can remain technically intact while the attacker operates as an approved caller. The pattern is visible in breach research such as the 52 NHI Breaches Analysis, where compromised machine identities repeatedly become the path of least resistance. The same failure mode appears in broader control guidance from the NIST Cybersecurity Framework 2.0, which treats access control as an identity and governance problem, not only a network one.
In practice, many security teams encounter lateral movement only after a valid credential has already been reused across multiple systems, rather than through intentional boundary testing.
How It Works in Practice
Modern lateral movement succeeds because the attacker follows legitimate paths after compromise. Instead of scanning every host, the attacker pivots through cloud consoles, CI/CD runners, service accounts, SSH keys, OAuth tokens, and internal APIs. Network segmentation can slow noisy movement, but it rarely stops an actor who already has a trusted identity and can call the same services a real workload uses.
That is why segmentation has to be paired with identity-aware controls. The practical stack usually includes strong workload identity, short-lived credentials, token binding where available, and policy decisions evaluated at request time. In NHI environments, the best practice is to reduce the value of any single stolen secret and make each credential narrowly scoped, short-lived, and revocable. NHIMG research on Ultimate Guide to NHIs — Standards consistently frames this as a control-plane problem: protect the identity that workload uses, not just the segment it lives in.
- Use workload identity for services, agents, and automation rather than long-lived shared secrets.
- Issue just-in-time credentials for specific tasks and revoke them on completion.
- Apply policy at request time with context such as workload, destination, time, and action.
- Restrict token reuse and monitor abnormal session chaining across systems.
- Assume internal traffic can be hostile once identity is compromised.
When segmentation is still helpful, it should be used as a containment layer, not the primary trust boundary. Guidance from the NIST Cybersecurity Framework 2.0 aligns with this layered approach: reduce blast radius, but do not treat network location as proof of legitimacy. These controls tend to break down in flat cloud estates and service-mesh-heavy environments because service-to-service trust is automated faster than policy teams can manually update boundaries.
Common Variations and Edge Cases
Tighter segmentation often increases operational overhead, requiring organisations to balance blast-radius reduction against deployment speed and troubleshooting complexity.
The tradeoff is especially sharp in environments with ephemeral workloads, multi-account cloud estates, and automated delivery pipelines. In those settings, static segmentation rules age quickly because services scale, relocate, and rotate identities faster than firewall or ACL updates can follow. Best practice is evolving toward identity-first containment, but there is no universal standard for this yet, especially across legacy on-prem networks and modern cloud control planes.
There are also edge cases where segmentation still matters more than usual. High-risk legacy systems, unmanaged endpoints, and crown-jewel databases often benefit from stricter network isolation because identity controls may be weaker or unavailable. But even there, segmentation only reduces exposure if the attacker cannot inherit a trusted session. NHIMG’s DeepSeek breach illustrates the broader danger of exposed credentials and overbroad trust: once secrets leak, lateral movement often becomes a question of reuse, not exploitation.
For most organisations, the practical answer is to treat segmentation as one layer in a larger zero trust design, not as a substitute for workload identity, secret hygiene, and real-time authorization.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets reduce lateral movement after credential compromise. |
| NIST CSF 2.0 | PR.AC-4 | Identity-aware access control is needed when segmentation cannot distinguish trusted reuse. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust limits reliance on network location as proof of legitimacy. |
Tie access decisions to identity context and continuously review entitlements across internal services.
