The September 21 report attributes the retreat to weak purchasing demand and substantial hardware-development work. It is the sole independent report available establishing the withdrawal; VMware’s own published material provides background on the architecture and separately shows that the broader vDefend Distributed Firewall remains part of its security strategy.
What VMware was trying to move off the server CPU
SmartNICs offload networking work from a server’s main processor. Data processing units, or DPUs, extend that approach with processing resources capable of taking on infrastructure services. VMware’s ambition was to let private-cloud customers move some networking and security functions onto these devices, preserving host CPU capacity for application workloads.
VMware’s February 2023 technical overview explains the software connection: the Distributed Services Engine, previously known as Project Monterey, was announced with vSphere 8.0 at VMware Explore 2022. It enables the hypervisor to offload tasks to an associated DPU.
The intended benefit went beyond throughput. VMware described separating workload processing from infrastructure and security processing, with hardware providing an additional isolation boundary. Its overview discussed firewall processing, encryption and other security tasks as potential uses of DPUs—not a guarantee that every such function was available in every supported configuration.
That architecture also introduces an economic trade-off. VMware’s own overview acknowledged that accelerators can increase capital and operating costs. Where only some hosts have the hardware, operations teams must account for which workloads can use it and where those workloads run. Reclaiming CPU capacity therefore has to justify both the hardware investment and the deployment complexity.
Why the firewall offering lost momentum
According to The Register, Umesh Mahajan, Broadcom’s vice president and general manager of application networking and security, said at VMware Explore that the company had “walked back from that space.” His explanation was blunt: “Customers kept talking, but not buying.”
The same report attributes additional difficulty to hardware enablement. Mahajan said VMware got its software working on AMD and Nvidia SmartNICs but struggled with Intel hardware, with development involving microcode. These are reported engineering experiences, not evidence that all Intel SmartNICs are incompatible with every VMware offload feature.
The Register also reports that improvements in conventional NIC throughput reduced the relative benefits of the SmartNIC approach. No comparative performance measurements accompany that account, so it does not establish that a conventional NIC can replace a DPU for every workload or isolation requirement.
A VMware spokesperson told the publication that the surrounding SmartNIC market had been slow to develop. Taken together, the reported explanation is a commercial and implementation problem: customer purchases did not justify continuing development of that firewall offering.
Three capabilities administrators should keep separate
The shared terminology can obscure materially different product boundaries:
| Capability | What the evidence establishes |
|---|---|
| Distributed firewall implementation for SmartNICs/DPUs | The Register reports that VMware has stopped selling it. |
| Distributed Services Engine | VMware’s spokesperson says it remains in Cloud Foundation and continues to receive support. |
| ConnectX-7 direct network offload | VMware’s spokesperson describes a separate traffic-acceleration mechanism, distinct from Distributed Services Engine. |
The ConnectX-7 capability should not be assumed to be a feature-for-feature replacement for the withdrawn firewall implementation. VMware’s statement describes network-traffic acceleration, without establishing equivalent firewall functionality or a migration procedure.
Meanwhile, VMware’s July 23 program for Explore 2026 explicitly included vDefend Distributed Firewall deployment, architecture and administration sessions. One session described distributed firewall and intrusion-prevention services processing rules and signatures in the kernel, within the virtual networking infrastructure. That first-party material supports the narrower reading of the withdrawal: VMware’s distributed-security platform has uses beyond the SmartNIC-hosted implementation.
What this changes for infrastructure planning
For a new purchase or expansion, the useful question is which capability the design actually requires. A proposal built around a DPU-resident firewall has a different dependency from one using Distributed Services Engine or ConnectX-7 traffic acceleration. Procurement and architecture reviews should name that dependency explicitly rather than treating “SmartNIC support” as a single feature.
For existing installations, ending sales does not establish an end-of-support date. The Register’s account does not give a precise sales cutoff, a support deadline for the firewall implementation, or an affected-version matrix. VMware’s assurance that Distributed Services Engine remains supported cannot safely be extended to every firewall package, card and software release.
There is consequently no basis in this report alone for disabling deployed security controls or removing DPUs. The concrete planning action is to obtain lifecycle and compatibility confirmation for the exact firewall implementation, Cloud Foundation or vSphere release, and hardware configuration before committing to further purchases. Continued support for the underlying offload engine preserves some DPU use cases, but it does not preserve the withdrawn firewall sales proposition.