Let's Be Honest About Where Most Networks Actually Are
I've done a lot of network assessments. Not the kind where you show up, run Nessus, and hand over a PDF. The kind where you actually sit down with the network team and trace how traffic moves. And I will tell you, without exaggeration, that the majority of mid-market corporate networks I've walked into in the last three years are functionally flat. Not "mostly flat." Flat. A printer in accounting can talk to a domain controller. An IoT badge reader shares a subnet with a file server. A developer's laptop can reach production databases directly.
This isn't a small company problem. I've seen this in organizations with 2,000 seats, dedicated security teams, and a slide deck full of Zero Trust talking points. The segmentation work never quite got done. There was always something more urgent. Now it's 2025 and the network looks like it did in 2012, except now there are 400 more IoT devices and three times the attack surface.
Let's actually talk about why this matters, what the real attack mechanics look like, and what doing it right actually requires — because "VLANs equal segmentation" is not the answer either.
The Difference Between VLANs and Segmentation That Actually Works
VLANs are not segmentation. I will die on this hill. VLANs are a broadcast domain control mechanism. They become segmentation only when you combine them with enforced inter-VLAN routing policies at a firewall or layer-3 device that is actually inspecting and controlling that traffic. If your core switch is doing inter-VLAN routing with an implicit permit-all, congratulations, you have labeled subnets, not segments.
The VLAN misconception is pervasive because it gives teams something to point to. "We have VLANs, we have segmentation." Auditors sometimes accept this. PCI DSS assessors should not. Under PCI DSS v4.0, the requirement for segmentation testing (Requirement 11.4.5 for service providers, recommended for merchants) explicitly requires that segmentation controls be tested to confirm that the CDE is isolated from out-of-scope systems. A VLAN with a permissive ACL fails that test. The standard is explicit: segmentation must prevent all access from out-of-scope systems to in-scope systems. Not most access. All access.
Microsegmentation is a different concept entirely. Instead of perimeter-based or VLAN-based controls, microsegmentation applies policy at the workload level. Tools like Illumio Core, Guardicore Centra (now Akamai Segmentation), and VMware NSX enforce policy based on workload identity — not IP address, not subnet, not port alone. The policy travels with the workload. If you move a VM, the policy moves. If a new instance spins up in an autoscaling group, it inherits policy from the group definition.
The practical difference matters enormously for east-west traffic. In a VLAN-based model, east-west traffic between workloads in the same VLAN is completely invisible and uncontrolled. An attacker who lands on one workload and pivots to another in the same VLAN never touches a firewall. With microsegmentation, that lateral movement hits a policy enforcement point regardless of whether the two workloads are in the same subnet, the same rack, or the same data center.
NotPetya Wasn't Sophisticated. The Networks Were Just Flat.
People still talk about NotPetya like it was some exotic, nation-state-exclusive capability. It wasn't. The propagation mechanism was EternalBlue and Mimikatz credential harvesting plus pass-the-hash. Both of those have been in the public domain for years. What made NotPetya catastrophic — $10 billion in damages across Maersk, Merck, FedEx, Mondelez — was not the malware's sophistication. It was the networks it ran on.
Maersk's network was, by most accounts, extremely flat. Domain admin credentials cached on endpoints. No segmentation between corporate offices globally. No controls limiting SMB traffic laterally between workloads. When NotPetya started moving, it moved at machine speed across the entire domain. Not hours. Minutes. A Wired investigation and subsequent incident reporting described the entire global network going down in roughly 45 minutes. That's not a malware problem. That's a network architecture problem that malware exposed.
There's a direct line between flat networks and ransomware blast radius. This is not theoretical. Ransomware operators have operationalized this knowledge. Modern ransomware gangs do reconnaissance specifically looking for flat networks, high-value servers reachable from any workstation, and backup systems co-resident on the same network as production. The dwell time before encryption is used precisely for this mapping. A flat network is not just easier to move through — it's easier to map, and that mapping is what informs which systems get encrypted first to maximize negotiation leverage.
Segmentation doesn't prevent initial compromise. Nothing does with 100% reliability. What segmentation does is constrain blast radius. An endpoint in a segmented VLAN for general corporate users should have zero routable paths to production database servers, backup infrastructure, or domain controllers. If that policy is enforced, lateral movement from a compromised endpoint either fails or requires exploiting the segmentation itself — which is substantially harder and louder than just using SMB to hop across a flat /16.
The "We Have EDR" Defense and Why It's Not Enough
Every time I bring up flat networks in a client conversation, someone mentions EDR. CrowdStrike, SentinelOne, Microsoft Defender for Endpoint. Good tools. I'm not here to knock them. But the argument that a well-deployed EDR replaces network segmentation reveals a fundamental misunderstanding of what EDR actually does.
EDR operates at the endpoint. It detects and can interrupt malicious behavior on the host where the agent is running. What it cannot do is stop a process from making a valid TCP connection to another system on the network — because from the host's perspective, that's a legitimate network operation. If an attacker uses a living-off-the-land technique with a signed binary — wmic.exe, psexec, native RDP — the EDR's behavioral detection has to catch the anomaly in process behavior and command-line arguments. Sometimes it does. Sometimes it doesn't, especially against operators who know how to blend in.
More importantly: EDR doesn't help you at all with unmanaged devices. And every network has unmanaged devices. Printers. HVAC controllers. Badge readers. IP cameras. Smart TVs in conference rooms. VoIP phones. These devices run embedded software. You cannot put an EDR agent on them. On a flat network, these devices can reach your domain controllers, your file servers, your whatever-else. In 2021, a threat actor compromised a water treatment facility in Oldsmar, Florida, via remote access. The plant's OT systems were not adequately segmented from the corporate IT network. That's an OT/IoT segmentation failure, and it's endemic.
The Purdue Model exists specifically to address this. It defines a hierarchy — Level 0 (physical process) through Level 4 (enterprise network) — with explicit demilitarized zones between each layer. OT networks that implement Purdue properly have firewalls between the DMZ and the corporate network. Data historians sit in the DMZ and act as the only communication bridge. Operational systems at Levels 0-2 are unreachable from Level 4. This model is decades old and still not universally implemented. I've personally walked into manufacturing environments where the engineering workstation that programs PLCs is on the same flat network as corporate email. That is a catastrophic risk that no amount of endpoint tooling fixes.
NAC Was Supposed to Fix This and Mostly Didn't
802.1X Network Access Control was going to save us. The idea is solid: authenticate devices before granting network access, enforce posture checks, put non-compliant devices in a quarantine VLAN. In practice, 802.1X deployments are among the most painful infrastructure projects I've ever been involved with.
The failure modes are consistent. First, printers, IoT devices, and legacy systems don't support 802.1X. So you end up with MAB (MAC Authentication Bypass) exceptions for every device that can't do EAP. MAB is trivially defeated by MAC spoofing. Second, the RADIUS infrastructure becomes a critical dependency that teams are terrified to touch, so it never gets updated and the policies calcify. Third, the quarantine VLAN often has more access than intended because someone needed to make it work quickly and never cleaned it up.
I've seen 802.1X deployments where the "quarantine" VLAN has access to the corporate file server because someone needed to run a remediation script years ago and the firewall rule never got removed. That's the firewall rule bloat problem in miniature — segmentation policy technical debt that accumulates over years until the policy no longer reflects any coherent security intent. It just reflects the accumulated scar tissue of every exception that was ever made.
Cloud Taught Us What Segmentation Should Look Like
Here's a thing I find genuinely ironic: most organizations that have flat on-premises networks have better segmentation in their AWS environments than in their own data centers. Not because cloud engineers are smarter, but because AWS's architecture forced them into it.
AWS VPC security groups are stateful, instance-level firewalls. By default, no inbound traffic is permitted. You explicitly allow what you need. Security groups are attached to the network interface, not the subnet, which means workloads in the same subnet are isolated from each other by default unless you explicitly permit the traffic. That's microsegmentation behavior built into the platform model. Network ACLs sit at the subnet boundary and are stateless — they're your blunt subnet-level controls, and most teams use them for broad policies while security groups handle the fine-grained workload-level stuff.
Compare that to the on-premises environment: a flat /16 with a perimeter firewall and an implicit permit-all for east-west. The same engineers who would never deploy an EC2 instance without thinking about security group rules will rack a physical server and connect it to the corporate network without a second thought about what it can reach.
The tools for doing microsegmentation on-premises now exist and are mature. Illumio's approach uses a Policy Compute Engine that maps application dependencies through passive traffic observation before enforcement, so you can actually see what your workloads are talking to before you write policy. That visibility step is critical and often skipped — teams jump to enforcement mode and break things, then give up. Guardicore (Akamai Segmentation) has similar discovery capabilities. NSX-T integrates directly into the vSphere hypervisor layer so policy enforcement doesn't require changes to the physical network at all. The technology is not the blocker. The blocker is that segmentation is operationally hard, politically contentious, and the consequences of getting it wrong are visible immediately while the consequences of not doing it are invisible right up until they're catastrophic.
Bastion Hosts, Jump Servers, and the PAM Question
One segmentation pattern that does get implemented — because it's relatively simple and satisfies auditors — is the jump box or bastion host architecture. The idea: administrative access to sensitive systems requires first connecting to a hardened intermediary. Your laptop can't RDP directly to a domain controller; you have to RDP to the jump box first.
This is better than nothing. But standalone jump boxes accumulate problems over time. They become shared infrastructure with multiple admins who all have credentials. Credential theft from the jump box itself compromises everything behind it. Logging is often incomplete. Session recording is rarely implemented. The jump box becomes a single point of failure for administrative access and a high-value target because attackers know that whoever owns the jump box owns the administrative tier.
Privileged Access Management solutions — CyberArk, BeyondTrust, Delinea — address most of these problems. PAM vaults credentials so admins never see the actual password for a target system. Sessions are proxied, recorded, and auditable. Access is request-based with approval workflows and time-limited. Just-in-time privilege elevation means standing admin access doesn't exist, which eliminates an entire class of credential theft value. PAM is architecturally a segmentation control: it enforces that administrative paths flow only through the PAM infrastructure, which is monitored, logged, and access-controlled.
The combination of PAM with network controls that literally block direct administrative protocol access (RDP/SSH) to sensitive systems except from the PAM infrastructure is genuinely strong. Most organizations have neither. Some have jump boxes. Very few have PAM deployed with network controls that make bypassing it topologically impossible rather than just policy-forbidden.
The Actual Work
Fixing a flat network isn't a project you do in a quarter. It's a multi-year program, and the organizations that succeed at it treat it that way. Start with visibility — deploy flow logging (NetFlow, sFlow, VPC Flow Logs if you're in cloud) and actually analyze it. Map your crown jewels and the paths that reach them. Identify which of those paths are business-necessary and which are artifacts of a flat topology that nobody ever cleaned up.
Segment highest-risk zones first: the CDE if you have PCI scope, OT/IoT networks if you have operational technology, your administrative tier. Those three segments alone will eliminate the most catastrophic lateral movement scenarios. Then work outward. Use a tool that gives you application dependency mapping before you enforce policy, or you will break things and lose organizational support for the project.
Test your segmentation. PCI DSS requires it for service providers and it should be mandatory for everyone. Penetration testers who specialize in internal network assessments will find misconfigured inter-VLAN routing, overly permissive security groups, and trust relationships that violate your intended architecture. Finding them in a test is substantially less expensive than finding them via a ransomware incident.
The flat network problem is solvable. It's just not easy, and the security industry has done everyone a disservice by selling EDR and XDR solutions as substitutes for network architecture work. They're not. A well-segmented network with mediocre endpoint tooling will contain a breach better than a flat network with best-in-class EDR. Both is the answer. But if I had to pick one first, I'd fix the network every time.
