How should teams balance network controls and identity controls against lateral movement?

They should treat them as complementary parts of the same exposure problem. Network controls reduce where an attacker can go, while identity controls reduce what they can do once they arrive. If identity trust still permits traversal through service accounts or delegated access, segmentation alone will not fully constrain lateral movement.

Why This Matters for Security Teams

lateral movement is rarely blocked by a single control type. Network segmentation can slow an intruder, but identity misuse often provides the path around it through valid accounts, delegated tokens, service principals, or over-permissive admin roles. Teams that focus only on firewall boundaries often miss the more durable problem: once an identity is trusted, the attacker may no longer need to break the network perimeter.

This is why the question is not whether network controls or identity controls are better, but how they work together as one exposure model. NIST SP 800-207 Zero Trust Architecture makes this explicit by treating every access request as a decision point rather than assuming trust based on location. That framing matters because modern environments mix on-premises systems, cloud workloads, remote users, and machine identities, all of which can be abused differently. The most common mistake is to treat segmentation as a substitute for identity governance, when in practice the two control planes need to fail independently.

MITRE ATT&CK Enterprise Matrix is useful here because it shows lateral movement as a set of techniques, not a single event. In practice, many security teams encounter lateral movement only after valid credentials or delegated access have already been abused, rather than through intentional segmentation failure.

How It Works in Practice

Balancing these controls starts with mapping the paths an attacker would actually use. Network controls limit reachability between subnets, workloads, and user zones. Identity controls limit which accounts, tokens, certificates, and roles can authenticate, elevate, or delegate. The strongest posture is achieved when both layers are designed to answer different questions: “Can this connection be made?” and “Should this identity be allowed to do this?”

In practice, teams should align segmentation with identity boundaries instead of using static network trust zones alone. That means protecting administrative paths, restricting east-west traffic, and ensuring privileged actions require stronger authentication, conditional access, or just-in-time elevation. For machine-to-machine environments, service account scope matters as much as network placement, especially where automation, CI/CD, and API calls are involved.

• Use network segmentation to constrain high-value zones, shared services, and management planes.
• Use identity controls to reduce standing privilege, limit token reuse, and tightly scope delegated access.
• Correlate identity events with network telemetry so anomalous logons and unusual east-west traffic can be investigated together.
• Prioritise protections around administrative protocols, remote management tools, and sensitive service accounts.

Zero Trust guidance is useful because it shifts enforcement from “trusted segment” to “verified request,” which is a better fit for hybrid environments and remote operations. It also helps when teams need to decide whether to place a control at the endpoint, the identity provider, the network layer, or all three. The practical objective is not to eliminate movement entirely, but to make each move observable, time-bound, and hard to escalate. These controls tend to break down in flat legacy networks with shared credentials because there is no clean separation between reachability and privilege.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance attack-surface reduction against application friction and administration complexity. That tradeoff becomes more visible in environments with legacy protocols, brittle dependencies, or heavily automated service-to-service communication. Best practice is evolving toward identity-aware networking, but there is no universal standard for exactly how much enforcement should sit in the network versus the identity plane.

Edge cases matter. In cloud environments, security groups and microsegmentation may reduce exposure, but a compromised role or workload identity can still traverse allowed APIs. In enterprise environments, VPN access may look well-controlled while privileged credentials quietly enable RDP, WinRM, SSH, or remote PowerShell movement. For SaaS and SaaP-connected environments, the attack path may not look like network hopping at all; it may appear as delegated consent, token theft, or abuse of federation trust. That is why identity logging, conditional access, and privilege review should be treated as part of lateral-movement defence, not separate governance work.

Current guidance suggests using network controls for containment and identity controls for authorization, then testing both together through adversary emulation and attack-path analysis. The right balance is the one that breaks the chain at the cheapest point without assuming either control plane will hold on its own. MITRE ATT&CK Enterprise Matrix is especially helpful for identifying where control gaps still permit valid-account abuse, remote service execution, and privilege escalation across segments.

Related resources from NHI Mgmt Group

• How can teams know if identity controls are actually limiting lateral movement?
• How can security teams balance user experience with stronger identity controls?
• Why do segmentation controls often fail against modern lateral movement?
• How can security teams tell whether identity controls are actually catching real attacker movement?