Zero trust as a concept has been around long enough that it's started appearing in slide decks from people who haven't actually implemented it. NSX-T micro-segmentation is the mechanism that turns the concept into something that enforces. The distance between those two things is where most organizations find themselves stuck — either because the implementation is incomplete, or because it was built in a way that's technically functional and operationally unmanageable.
Both failure modes are common. They have different causes and different fixes, and it's worth being specific about them rather than treating "micro-segmentation isn't working" as a single undifferentiated problem.
What the DFW Actually Does
The NSX-T Distributed Firewall doesn't sit at the network edge. It doesn't sit at the virtual switch. It runs in the kernel of each ESXi host and enforces policy at the vNIC of every virtual machine — egress inspection as traffic leaves the VM, ingress inspection as traffic arrives. The enforcement point is as close to the workload as you can get without being inside the guest OS.
The practical implication matters. A compromised workload on the same ESXi host as your payment processing cluster can't reach that cluster through lateral movement if the DFW policy is correctly written, because the enforcement happens before the packet leaves the attacking VM's vNIC. There's no routing path to exploit because the firewall isn't in the routing path — it's in the hypervisor kernel, on both sides of every connection simultaneously.
DFW rules follow VMs during vMotion. When DRS moves a workload to a different host, the security policy moves with it — enforcement picks up immediately on the receiving host without any reconfiguration.
This is what makes micro-segmentation operationally viable in a dynamic environment: the security boundary is attached to the workload, not to the network location the workload happens to occupy at any given moment. It's also what makes getting the policy wrong consequential in ways that perimeter firewalls aren't — a gap at the DFW level is a gap at the workload level, not at the edge of the building.
One distinction worth being precise about: the gateway firewall handles north-south traffic — what enters and exits the environment through the NSX Edge nodes. DFW handles east-west — lateral traffic between workloads inside the data center. Both have a job, they work in conjunction, and conflating which layer handles what is how you end up with a policy that looks complete on paper and has a gap exactly where the actual risk lives.
The Pre-Work That Always Gets Underestimated
The most consistent failure mode I see in micro-segmentation projects has nothing to do with NSX-T configuration. It's that the traffic flow documentation doesn't exist before the first rule is written.
Not "is incomplete." Doesn't exist. Organizations have been running workloads for eight or ten years without systematically documenting what communicates with what, on what port, for what reason. Application owners know their application but often can't enumerate every service dependency — especially the ones added during an incident four years ago and never formally documented. Infrastructure teams know the network topology but not the application behavior running on top of it. The intersection of those two knowledge sets is where the actual policy has to be built, and that intersection is rarely a well-maintained document.
Writing DFW rules against undocumented traffic flows is how you block something critical without knowing you've done it until something fails in production.
- The situation. A team wrote DFW rules for a core banking application against a network diagram from the application vendor — a reasonable starting point, and the diagram was accurate when it was produced.
- The problem. The application had been in production for six years. The diagram hadn't been updated in four. There were twelve undocumented service dependencies that the rules didn't account for, including one to a monitoring agent installed by a contractor during a performance investigation and never formally removed from the environment.
- When the blocking rules went in. The monitoring platform lost visibility to a chunk of production infrastructure. The root cause — one untracked monitoring agent, one missing allow rule — took several hours to isolate because nobody knew the agent existed.
- The actual fix. Passive traffic observation in monitoring mode before any blocking rules are deployed. NSX Intelligence, or vRealize Network Insight if that's what's licensed, captures actual flow data against the real running environment. It takes weeks. The alternative is faster until it isn't.
The monitoring mode / passive observation phase isn't overhead on the project. It is the project, for the first several weeks. Teams that skip it in the interest of showing progress are making a tradeoff that usually becomes visible at the worst possible time.
Security Group Design and the Maintenance Problem Nobody Anticipates
Security groups are the objects DFW policy is written against — how you define "these workloads" in a firewall rule. Getting the design right here determines whether the policy is maintainable at eighteen months or whether it becomes something nobody wants to touch because making any change requires understanding a rat's nest of IP-address-based group membership that was accurate when it was created and hasn't been since.
The IP-address model feels familiar because it mirrors how physical firewalls have always worked. It's also fragile in a virtualized environment in ways that compound over time. IPs change. VMs get cloned and redeployed with different addresses. A subnet gets renumbered during a migration. Group membership silently drifts from the intended state, the policy continues enforcing against a stale inventory, and nobody notices until a security audit asks how they can be confident the rules reflect current reality — or until something breaks in a way that traces back to a group that was right in 2022.
Tag-based dynamic groups are the right model. A VM tagged with the appropriate scope and application identifiers is automatically a member of the relevant security group the moment the tag is applied, regardless of what IP it has, what segment it's on, or what host it runs on. Decommission the VM and remove the tag — or decommission the VM entirely — and it leaves the group. The policy stays accurate without manual group membership management.
Getting there requires a tagging taxonomy designed before the first security group is created. Environment scope, application identifier, tier, data classification — the categories vary by organization, but the principle is that every VM needs to be unambiguously tagged against the taxonomy from the moment it's provisioned. Retrofitting tags to an existing estate of several hundred VMs is the kind of project that starts with good intentions and ends six months later with group membership that's "mostly right" and a list of exceptions that everyone agrees will be cleaned up eventually.
The "Applied To" Field and What Happens When You Ignore It
This is the performance detail that most micro-segmentation implementations don't discover until the environment is large enough for it to matter — at which point it's harder to fix.
By default, every DFW rule is pushed to every vNIC on every NSX-prepared host. The intent is that the policy is complete and consistent across the environment. The consequence is that in an environment with hundreds of rules, every rule is being evaluated against every vNIC on every host, regardless of whether that vNIC has anything to do with the rule. A rule governing traffic between the payment processing tier and the database tier is sitting on the vNICs of the VMs in the development environment, doing nothing except consuming resources.
In NSX 4.2.1, Broadcom redesigned the vsip-rules heap allocation: 1 GB dedicated specifically for DFW rules, separate from the address-set heap. Exceeding the per-host rule limit (~120,000 rules) or the per-vNIC limit (4,000 rules) exhausts that heap. The consequence isn't a graceful degradation or a warning you get time to act on — Broadcom's own knowledge base documents it as capable of causing an ESXi host PSOD.
The fix is using the "Applied To" field to scope rules to the security groups they actually need to apply to. A rule governing payment processing VM communication belongs on the payment processing VMs — not on every vNIC in the data center. This is straightforward to implement correctly from the beginning. Retrofitting it to a policy that was built with everything scoped to the global DFW is the kind of project that requires careful review of every rule in the base before anything can be changed safely.
Traffic flow documentation — or passive monitoring mode to capture actual flows — before any rules are written. You cannot write a correct policy against unknown flows.
Tagging taxonomy and security group design validated before DFW rules reference them. Groups with wrong membership means rules with wrong scope, regardless of how correct the rule syntax is.
Allow rules tested and validated in monitoring mode before the default-deny rule is enabled. The default-deny goes in last, not first. Putting it in early to "prove the policy is working" is how the monitoring platform loses production visibility at 2am.
"Applied To" scoped to relevant security groups from the first rule, not retrofitted later when the environment is large enough to have a problem.
Most NSX-T micro-segmentation projects that go badly wrong got the sequencing wrong. The platform does what it's told. A blocking rule against an undocumented dependency is an outage. A group with stale IP-based membership is a policy gap. A default-deny rule deployed before the allow rules are validated is a crisis. The technology is sound. The order of operations is where the risk lives.