The Microsegmentation Myth: Why EDR, VMware NSX, and CNAPP Are Not Microsegmentation

The Microsegmentation Myth: Why EDR, VMware NSX, and CNAPP Are Not Microsegmentation

Every quarter, a CISO asks us a version of the same question: "We already have CrowdStrike on every endpoint. Our cloud team runs Wiz for CNAPP. We still have VMware NSX in our data centre. Do we really need a separate microsegmentation platform?" The answer is yes, and the reason they need to ask reveals a category confusion that's costing enterprises real security coverage. EDR, VMware NSX, and CNAPP each do important things. None of them do microsegmentation. The category mistake isn't just a vendor positioning debate. It determines whether an attacker who gets past your perimeter can move laterally to your most critical systems, or whether they hit a wall.

The CrowdStrike 2026 Global Threat Report documents the stakes: average eCrime breakout time is 29 minutes. The fastest observed: 27 seconds. 82% of intrusions are malware-free, meaning attackers log in with valid credentials and move laterally through trusted pathways. At that speed, the only control that reliably limits blast radius is architectural containment. That's microsegmentation. Not EDR. Not CNAPP. Not network virtualization.

What Microsegmentation Actually Is

Before debunking the myths, let's define the category precisely.

Microsegmentation creates granular, workload-level security boundaries that control east-west (lateral) traffic within the network. Each workload, whether a VM, a container, a bare-metal server, or a cloud instance, operates in its own security segment with explicitly defined policies governing which other workloads it can communicate with, over which protocols, and for which purposes.

The defining characteristics of true microsegmentation:

Workload-level granularity. Not network segments, not VLANs, not subnets. Individual workloads. A database server and an application server in the same subnet can have different policies. A compromised web server cannot reach the database server even though they share a network segment.

East-west traffic control. Traditional firewalls control north-south traffic (in and out of the network). Microsegmentation controls east-west traffic (between systems inside the network). This is where 80%+ of lateral movement occurs during a breach.

Identity-based policy. Policies are defined based on workload identity (what the workload is and what it does), not IP addresses (where it happens to sit on the network). When a workload moves, its policies move with it.

Platform-agnostic enforcement. True microsegmentation works across VMs, containers, bare metal, cloud instances, and hybrid environments. Security shouldn't depend on which hypervisor, cloud provider, or operating system the workload runs on.

Always-on enforcement. Policies enforce even if the workload is compromised. An attacker who gains root access on a segmented workload cannot disable the microsegmentation controls from inside the workload.

With this definition clear, let's examine why three commonly confused technologies don't qualify.

Myth 1: "Our EDR Does Microsegmentation"

The claim: CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, and other EDR platforms include host-based firewall management capabilities. Vendors position these as "microsegmentation" or "network containment" features. CrowdStrike's Falcon Firewall Management, for example, allows centrally managed host-based firewall rules across endpoints.

Why it's not microsegmentation:

EDR is a detection and response tool. Its primary function is identifying malicious activity on endpoints, not controlling traffic between workloads. The host firewall features are a secondary capability, not the architectural foundation.

Detection-first, not prevention-first. EDR's design philosophy is "detect and respond." It monitors endpoint activity, identifies threats, and enables response. Microsegmentation's design philosophy is "prevent and contain." It blocks unauthorized communication before it happens, regardless of whether the communication is malicious. These are fundamentally different security postures.

Agent-dependent enforcement. EDR host firewall rules run as an agent process on the endpoint's operating system. An attacker who achieves kernel-level access or disables the EDR agent (which sophisticated attackers regularly do) eliminates the enforcement point. True microsegmentation operating at the hypervisor layer or through a kernel-level enforcement point that's architecturally separate from the OS cannot be disabled by compromising the workload.

No workload identity model. EDR firewall rules are typically based on IP addresses, ports, and protocols, the same model as traditional firewalls. Microsegmentation uses workload identity (application labels, environment tags, business function metadata) to define policies. When a workload moves to a different IP (during scaling, migration, or failover), EDR rules tied to the old IP break. Identity-based microsegmentation policies follow the workload automatically.

No east-west traffic visibility. EDR agents see what happens on their individual endpoint. They don't provide a unified view of all east-west traffic flows across the environment. Without this visibility, you can't build effective segmentation policies because you don't know what's communicating with what. Microsegmentation platforms begin with a traffic discovery phase that maps all communication patterns before any policies are applied.

Where EDR fits: Detection, investigation, and response on individual endpoints. EDR is essential for identifying threats that microsegmentation doesn't address: fileless malware, credential theft, privilege escalation on a single host. But EDR and microsegmentation are complementary layers, not substitutes. EDR tells you "this endpoint is compromised." Microsegmentation ensures "this compromised endpoint can't reach anything it shouldn't."

Myth 2: "VMware NSX Is Our Microsegmentation"

The claim: VMware NSX's Distributed Firewall (DFW) provides microsegmentation capabilities integrated into the hypervisor. Many enterprises, particularly those with mature VMware environments, have deployed NSX DFW as their microsegmentation solution.

Why it's not enough (and why the timing matters):

VMware NSX DFW is technically the closest to true microsegmentation among the three myths. It operates at the hypervisor level, provides workload-level granularity for VMs, and supports identity-based security groups. For enterprises running 100% VMware workloads, NSX DFW has historically been a reasonable microsegmentation approach.

Three problems have emerged that make NSX insufficient for modern enterprise microsegmentation:

Platform lock-in to VMware. NSX DFW only works on VMware workloads. It cannot segment bare-metal servers, non-VMware cloud instances (AWS EC2 on non-VMware substrates, Azure VMs, GCP Compute Engine), or containers running on non-VMware Kubernetes. Most Indian enterprises operate hybrid environments: some VMware VMs in the on-premise data centre, some workloads on AWS, some containers on Kubernetes. NSX segments only the VMware slice. Everything else is unprotected.

As ColorTokens' analysis puts it: "NSX couples enforcement, policy objects, tagging models, and operational workflows to the VMware stack. As organizations reassess their VMware footprint following the Broadcom acquisition and licensing changes, security teams face an uncomfortable reality: migrating compute platforms may require redesigning security controls in parallel."

The Broadcom pricing disruption. Broadcom's acquisition of VMware has triggered 2-10x price increases for NSX licensing, with perpetual licenses eliminated in favour of subscription-only bundling through VMware Cloud Foundation. For Indian enterprises that deployed NSX for microsegmentation specifically, the cost of maintaining that security control has increased dramatically. Many are now re-evaluating whether platform-locked microsegmentation is sustainable.

No container or serverless coverage. NSX's microsegmentation capabilities were designed for virtual machines. Container workloads on Kubernetes, serverless functions, and modern cloud-native architectures operate outside NSX's enforcement model. As Indian enterprises modernize their application stacks (and they are: microservices architectures, containerized deployments, cloud-native development), the percentage of workloads that NSX can actually protect is shrinking.

Where NSX fits: Network virtualization, software-defined networking, and east-west firewalling within VMware-specific environments. If your entire estate is VMware and will remain VMware, NSX DFW provides reasonable segmentation for that estate. But that's an increasingly rare scenario, and Broadcom's pricing changes are making it less viable with every renewal cycle.

Myth 3: "Our CNAPP Handles Microsegmentation"

The claim: Cloud-Native Application Protection Platforms like Wiz, Palo Alto Prisma Cloud, CrowdStrike Falcon Cloud Security, and Lacework include network segmentation capabilities in their feature sets. Vendors position these as microsegmentation for cloud environments.

Why it's not microsegmentation:

CNAPP is a cloud security posture management and vulnerability detection platform. Its primary function is identifying misconfigurations, vulnerabilities, and threats in cloud environments. Some CNAPPs include network policy recommendations or segmentation scoring features. These are not the same as microsegmentation enforcement.

Visibility, not enforcement. Most CNAPP network features show you what your current network configuration looks like and flag issues (overly permissive security groups, publicly exposed ports, misconfigured NACLs). They don't enforce microsegmentation policies. They tell you "this workload can talk to that workload, and it shouldn't." They don't prevent the communication. That's the difference between a security assessment tool and a security enforcement tool.

Cloud-only scope. CNAPPs protect cloud workloads. They have no visibility into or control over on-premise data centres, co-location environments, or edge deployments. Indian BFSI institutions, which typically operate hybrid environments with core banking on-premise and digital channels in the cloud, need microsegmentation that spans both. A CNAPP that segments your cloud workloads while leaving your on-premise core banking system unprotected is solving half the problem.

No identity-based policy model. CNAPP network controls typically operate on cloud-native constructs: security groups, network ACLs, VPC peering rules. These are infrastructure-level controls, not application-level microsegmentation policies. They don't understand workload identity, application dependencies, or business context. When your development team spins up a new microservice, the CNAPP doesn't automatically know what it should be allowed to communicate with.

Complementary, not substitutive. CNAPP is essential for cloud security posture management, vulnerability detection, and compliance monitoring. It should be in every cloud security stack. But it's a different category from microsegmentation, solving different problems with different mechanisms.

The Category Distinction That Matters

The Forrester Wave for Microsegmentation Solutions evaluates vendors specifically on microsegmentation capabilities: workload discovery, policy creation, enforcement, visualization, and hybrid environment support. The vendors in the Wave are microsegmentation specialists and platforms with dedicated microsegmentation capabilities. EDR vendors, CNAPP vendors, and VMware NSX are evaluated in their own respective categories because they solve different problems.

This isn't vendor politics. It's architectural reality. Here's the comparison:

Why This Matters for Indian Enterprises Right Now

Three converging forces make the category distinction urgent for Indian CISOs:

The Broadcom/VMware NSX pricing disruption. Enterprises that built their microsegmentation strategy on NSX are facing renewal costs that may be 2-10x higher than their previous agreements. This is forcing a re-evaluation of microsegmentation strategy at exactly the moment when the need for microsegmentation is increasing.

The CrowdStrike 2026 report's breakout time data. 29-minute average breakout, 27-second fastest, 82% malware-free intrusions. At these speeds, the question isn't "will my EDR detect the attacker?" (it probably will, eventually). The question is "what can the attacker reach before detection?" Only architectural containment through microsegmentation answers that question.

Regulatory pressure. RBI's IT Governance Master Direction requires network segmentation for critical banking systems. The FM's April 23 directive on AI-driven cyber threats demands architectural preparedness beyond perimeter controls. The DPDP Act's security safeguard requirements make microsegmentation a component of "reasonable" security for organisations processing personal data at scale.

Indian enterprises that claim "we have microsegmentation" based on EDR host firewalls, VMware NSX (for part of their environment), or CNAPP network features are carrying unquantified lateral movement risk that the current threat landscape makes unacceptable.

The Three Questions That Reveal Whether You Have True Microsegmentation

Question 1: If an attacker compromises a web server today, can they reach your database servers?

If your microsegmentation is working, the answer is: only through the specific, documented API calls that the web application legitimately makes to the database, and nothing else. The compromised web server cannot initiate SSH connections, ping sweeps, RDP sessions, or any other communication to the database that isn't explicitly permitted.

If your "microsegmentation" is EDR host firewalls, the answer depends on whether the attacker has disabled the agent. If it's VMware NSX, the answer depends on whether both the web server and database are VMware VMs. If it's CNAPP, the answer depends on whether both are in the same cloud environment.

Question 2: Can your microsegmentation policies follow a workload that moves from on-prem to cloud?

If your microsegmentation is platform-independent, the policies persist regardless of where the workload runs. If it's VMware NSX, the policies exist only in the VMware environment. If the workload migrates to AWS, the NSX policies don't follow.

Question 3: Can a compromised workload disable its own segmentation controls?

If your microsegmentation operates at the hypervisor or kernel level, the answer is no: the enforcement point is architecturally separate from the workload. If your "microsegmentation" is an EDR agent running in user space, a sophisticated attacker can disable it.

The enterprise that can answer all three questions affirmatively has true microsegmentation. The enterprise that can't has a coverage gap that needs to be addressed before the next CrowdStrike report documents a 20-second breakout time.

Frequently Asked Questions

Do we need microsegmentation if we have EDR on every endpoint? Yes. EDR detects threats on individual endpoints. Microsegmentation prevents lateral movement between workloads. They solve different problems. An EDR alert that says "endpoint compromised" is useful but reactive. Microsegmentation that blocks the compromised endpoint from reaching your database is proactive. At 29-minute breakout times, the gap between "detected" and "contained" is where damage occurs.

We've invested heavily in VMware NSX. Should we rip and replace? Not necessarily. But you should assess what percentage of your workloads NSX actually covers. If you're 100% VMware (increasingly rare, and increasingly expensive post-Broadcom), NSX DFW provides reasonable segmentation for that estate. If you run hybrid environments (on-prem VMware + cloud + containers + bare metal), NSX covers only the VMware slice. The unprotected workloads need a platform-independent microsegmentation solution. Migration doesn't have to be abrupt; it can be phased as VMware licenses come up for renewal.

Isn't CNAPP microsegmentation for the cloud? No. CNAPP provides cloud security posture management, vulnerability detection, and compliance monitoring. Some CNAPPs include network visibility and policy recommendation features, but these are assessment tools, not enforcement tools. They tell you what your network configuration looks like and what's wrong with it. They don't enforce granular, identity-based, east-west traffic controls at the workload level. You need both CNAPP (for cloud security posture) and microsegmentation (for lateral movement prevention).

What about Kubernetes network policies? Aren't those microsegmentation? Kubernetes network policies provide basic network segmentation within a K8s cluster: controlling which pods can communicate with which other pods. This is useful but limited. It only covers containerized workloads within Kubernetes. It doesn't cover VMs, bare metal, cross-cluster communication, or hybrid environments. And policy management at scale (across hundreds of microservices with complex dependency chains) requires a microsegmentation platform with automated policy discovery, not manually written YAML.

How does this affect our DPDP Act compliance? The DPDP Act requires "reasonable security safeguards" (Section 8) for personal data processing. In a regulatory environment where the FM has directed banks to counter AI-driven threats, where CrowdStrike documents 29-minute breakout times, and where shadow AI creates uncontrolled lateral movement risk, microsegmentation is rapidly becoming part of what "reasonable" means. An enterprise that suffers a lateral movement breach and didn't have microsegmentation will find it difficult to argue that its security safeguards were "reasonable."