What do security teams get wrong about lateral movement prevention?

Why This Matters for Security Teams

lateral movement prevention is often framed as a network segmentation problem, but that view is too narrow for modern identity-rich environments. Attackers do not need to “break out” in the old perimeter sense if they can reuse service accounts, abuse control-plane access, or pivot through trusted internal protocols. MITRE’s MITRE ATT&CK Enterprise Matrix treats lateral movement as a distinct phase because it relies on the trust relationships already present inside the environment.

That is especially true for non-human identities, where over-privileged credentials and long-lived secrets can turn one foothold into many. NHIMG research in the Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which means a single compromise can expose far more than the original workload. Security teams often miss that the attacker is not “moving across hosts” in isolation, but moving through identity, control, and automation paths that were never designed to be tight.

In practice, many security teams discover lateral movement only after a trusted credential has already been reused across multiple internal services, rather than through intentional containment.

How It Works in Practice

Effective prevention starts by shrinking the paths an attacker can take after the first compromise. That means limiting east-west connectivity, but it also means constraining which identities can reach which internal tools, APIs, and control planes. A service account with broad access to orchestration, secrets, or cloud management interfaces can be just as dangerous as an open subnet.

Practitioners increasingly combine network controls with identity controls, because transport restrictions alone do not stop a valid token from being used in the wrong place. In NHI programs, that usually means rotating secrets, scoping permissions tightly, and separating workloads so that one compromised agent or service cannot impersonate another. The NHI Mgmt Group’s 52 NHI Breaches Analysis and TruffleNet BEC Attack both show how stolen credentials can propagate far beyond the first entry point when internal trust is too broad.

• Use microsegmentation to reduce host-to-host reach, especially around admin services and management planes.
• Apply RBAC and service-scoped authorization so one identity cannot access unrelated internal systems.
• Rotate secrets aggressively and prefer short-lived credentials over static keys.
• Restrict access to orchestration, CI/CD, and secrets infrastructure, since these are common pivot points.
• Log and alert on unusual internal authentication paths, not just external perimeter events.

Current guidance from CISA’s Zero Trust Maturity Model and the MITRE ATT&CK Enterprise Matrix aligns on the same point: movement is easier when trust is implicit and identity is broad. These controls tend to break down in flat legacy networks, shared-kernel environments, and toolchains where a single credential is reused across many internal systems because privilege boundaries are already blurred.

Common Variations and Edge Cases

Tighter lateral movement controls often increase operational overhead, requiring organisations to balance containment against engineering friction and incident response speed. That tradeoff is especially visible in cloud, Kubernetes, and hybrid environments where workloads are ephemeral, service discovery changes quickly, and teams rely on automation to keep systems running.

Best practice is evolving around the idea that not every internal path should be treated equally. Some traffic is business-critical, such as application-to-database access or deployment pipelines, while other flows are purely administrative and should face much stricter controls. Current guidance suggests using tiered trust zones, short-lived credentials, and strong isolation around privileged automation rather than assuming that east-west traffic can be uniformly blocked.

There is no universal standard for this yet, but the consistent failure mode is overgeneralization: treating all internal movement as either harmless or fully preventable. The more realistic approach is to identify the identities, protocols, and management surfaces that would let an attacker leapfrog from one system to another, then reduce or remove those paths before an intrusion happens. That is where the NHI Mgmt Group’s broader guidance on identity governance and zero trust becomes operationally useful, especially when paired with implementation patterns from the Ultimate Guide to NHIs.

Related resources from NHI Mgmt Group

• What do security teams get wrong about data loss prevention?
• What do security teams get wrong about fraud prevention in iGaming?
• What do security teams get wrong about scam prevention?
• What do security teams get wrong about database breach prevention?