Your Internal Network Trusts Everything Inside It
The phishing email landed on a junior marketing coordinator's laptop. The attacker had a foothold on an endpoint with no administrative rights, no direct database access, and no path to anything that looked interesting from the outside. In a well-segmented environment, that is roughly where the story ends.
In most organizations, it is where the story begins.
The coordinator's laptop can initiate connections to the finance file server, the HR system, the domain controllers, and the backup infrastructure. It always could. Nothing ever told it otherwise. What looked like a low-value compromise was an entry point into the entire environment.
What Lateral Movement Actually Looks Like
Lateral movement is the gap between initial access and actual impact. The attacker has a beachhead on a low-privilege endpoint and needs to reach something worth having: a domain controller, a database with customer records, the backup servers they plan to encrypt before anyone notices.
The tools are simple. Network scanning from the compromised endpoint reveals what is reachable. Credential harvesting from memory pulls authentication material that can be reused elsewhere. Pass-the-hash attacks authenticate to other systems without knowing the actual password. Kerberoasting extracts service account credential hashes for cracking offline.
None of this requires sophisticated capability. It requires reachability. The compromised endpoint has to be able to initiate a connection to the systems the attacker wants to reach. In a flat network, it can reach most of them.
Why Organizations Still Have Flat Networks
Segmentation is not a new idea. It appears in every framework, every architecture review, and every pentest report that includes recommendations. Most security teams will tell you they have network segmentation in place.
Most of them are describing VLANs.
VLANs separate broadcast domains. Without firewall policy enforcing what traffic is allowed between segments, they do not meaningfully restrict lateral movement. An attacker on the workstation VLAN can still reach servers on the server VLAN if there is an implicit allow or a default permit rule between them. The network diagram shows segments. The traffic can still cross freely.
The other common answer is a perimeter firewall with an internal default-permit policy. Traffic is inspected going in and out. Traffic going sideways between internal systems goes through nothing. The assumption built into the design is that traffic originating inside the network is inherently safe. That assumption is the flat network problem.
Meaningful segmentation did not happen because it is operationally difficult. It requires an accurate inventory of what systems exist, what they legitimately communicate with, and what the exceptions are. In most environments, that inventory is wrong or absent. Application dependencies are undocumented. The monitoring agent installed in 2019 connects to seventeen systems that no longer exist in the asset database. The legacy system that runs the warehouse floor will break if any of its connections are interrupted.
So the segmentation project scopes itself narrowly to the highest-risk zones, gets implemented partially, and the general workstation subnet continues to talk freely to everything it ever could.
VLANs Are Not Segmentation
A VLAN with a corresponding ACL or firewall policy that enforces what traffic is allowed between it and other VLANs is meaningful segmentation. The combination of broadcast domain isolation and enforced traffic policy creates an actual control.
A VLAN with a default-permit inter-VLAN routing rule, or with policy that only blocks the traffic patterns someone thought to list at the time, is not. The attacker moves between VLANs the same way legitimate traffic does, because the routing permits it and the policy does not distinguish between them.
The gap matters because organizations that believe they have segmentation because they have VLANs are not prioritizing closing it. They think the control exists. An attacker's reconnaissance scan will show otherwise.
What Meaningful Segmentation Requires
Start with an accurate picture of what is actually communicating. Run NetFlow or full-packet capture on key internal segments for 30 to 60 days before implementing policy. Build the allowlist from what you observe, not from what you expect. You will find connections you did not know existed, and you will find expected connections that have not happened in months.
Define zones by function and risk level, not by team or department. Endpoints belong in one segment. Servers belong in another. Domain controllers, backup infrastructure, and payment processing systems each get their own zone with explicit, narrow policy. The organizational friction this creates is the point: every exception that gets requested tells you about an undocumented dependency or a misconfigured service.
Enforce a default-deny baseline between segments. Define what is allowed and block everything else. This is operationally uncomfortable at first and catches problems you did not know existed. It is also the only posture that makes unexpected internal traffic detectable. A workstation trying to connect to a domain controller on a port that is not in the allow policy generates an alert. In a permissive environment, it generates nothing.
Apply inspection to east-west traffic, not just north-south. Perimeter controls see traffic entering and leaving the network. East-west traffic between workstations and servers, between application tiers, between internal services, crosses through perimeter controls only if it leaves and re-enters. An internal firewall or a software-defined microsegmentation solution that applies policy to internal traffic is what actually constrains lateral movement. The perimeter control the attacker already bypassed does not.
The Practical Starting Point
Rebuilding segmentation from scratch is not realistic for most organizations. The practical sequence starts with isolating the highest-value targets. Domain controllers, backup systems, and core infrastructure go into their own segments with explicit policy before anything else. This limits the blast radius of the most common lateral movement scenarios without requiring a full network redesign.
Then work outward: separate servers from general endpoints, add inspection at major trust boundaries, tighten policy as you develop better visibility into legitimate communication patterns.
An attacker with one compromised endpoint should not end up with access to your entire environment. That outcome requires a design choice, not just the absence of a sophisticated attacker.