How should organisations reduce lateral movement in hybrid networks?

Why This Matters for Security Teams

lateral movement is what turns a single foothold into a broader compromise. In hybrid networks, attackers rarely rely on one clean path; they chain identity theft, remote management tools, misconfigurations, and trust relationships between on-premises and cloud workloads. That is why the real problem is not only segmentation, but whether access is continuously authorised at the point of use. Guidance from NIST SP 800-207 Zero Trust Architecture reinforces this shift from implicit network trust to explicit, contextual access decisions.

Security teams often overestimate the protection provided by traditional VLANs, routing boundaries, or firewall zones. Those controls still matter, but they do not reliably stop a compromised identity, a stolen service token, or an over-privileged admin session from moving across domains. In practice, the highest-risk paths are usually the ones created for convenience: shared admin access, broad east-west rules, legacy jump hosts, and cloud-to-on-prem trust links that were never revisited after deployment. Mapping attacker behaviour against the MITRE ATT&CK Enterprise Matrix helps teams see how common techniques chain together across environments. In practice, many security teams encounter lateral movement only after an internal account has already been abused to reach a higher-value system, rather than through intentional path monitoring.

How It Works in Practice

Reducing lateral movement means controlling both reachability and authority. The practical pattern is to combine network enforcement with identity-based policy so a connection is allowed only when the workload, user, device, and session context match what is expected. That usually means segmenting by application or trust zone, not by broad location, and then validating every permitted path against business need. Zero Trust Architecture is useful here because it treats the network as hostile by default and requires ongoing verification rather than one-time admission.

In hybrid networks, implementation normally spans three layers:

• Identity and privilege: remove standing admin access, prefer just-in-time elevation, and separate human, service, and automation credentials.

• Traffic control: enforce east-west filtering with microsegmentation, host firewalls, and tightly scoped security group rules across cloud and on-premises assets.

• Validation and detection: continuously test allowed paths, alert on unexpected authentication hops, and correlate identity events with network telemetry in SIEM and EDR.

This matters because lateral movement often succeeds through normal tools and trusted relationships, not exotic exploits. Remote PowerShell, SSH, RDP, API calls, directory replication, and service-to-service calls can all become movement channels if entitlements are too broad. A good control design assumes compromise of one endpoint or account and then limits what that compromise can reach. Current best practice is to review those paths alongside attack-path modelling and to align detections with techniques documented in MITRE ATT&CK. These controls tend to break down when legacy applications require flat network access because the application dependency chain is undocumented and cannot be decomposed safely.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance reduced blast radius against application complexity and change-management burden. That tradeoff is real in hybrid estates where older systems, vendor-managed appliances, and cross-domain admin workflows do not fit modern policy models. Best practice is evolving, but there is no universal standard for how granular every segment should be; the right level depends on the sensitivity of the asset, the trustworthiness of the workload, and the maturity of detection coverage.

Edge cases matter. Batch jobs, backup systems, monitoring platforms, and identity infrastructure often need broad reach that would be unacceptable for ordinary workloads. The mistake is to treat those exceptions as permanent blanket permissions rather than documented, monitored, and periodically revalidated carve-outs. For identity-heavy environments, the intersection with NHI governance is especially important: service accounts, API keys, certificates, and automation tokens can create invisible east-west pathways if they are not scoped and rotated with the same discipline as human admin access.

Where cloud and on-premises identity planes overlap, organisations should also watch for hidden trust bridges such as federated logins, shared secrets, and over-permitted orchestration tools. The practical control objective is not perfect isolation, but deliberate friction: make movement harder, more visible, and less reusable. That approach is strongest when segmentation, identity assurance, and telemetry are designed together rather than bolted on after the fact.

Related resources from NHI Mgmt Group

• How should security teams reduce lateral movement risk in enterprise networks?
• How can organisations reduce lateral movement without breaking normal operations?
• How should security teams reduce lateral movement risk after a fast exploit chain succeeds?
• Why do perimeter VPNs increase lateral movement risk in enterprise networks?