VMware NSX Advanced Licensing

NSX has had one of the more complex licensing histories in the VMware portfolio. The product has been through three editions of edition-naming, two acquisitions of adjacent products (Avi for load balancing, Lastline for advanced threat prevention), and a major repositioning under the Broadcom subscription model that simultaneously bundled it into VMware Cloud Foundation and restructured the standalone editions. Customers running NSX in production today are typically operating under some mix of legacy perpetual licences, transitioned subscriptions, and VCF-bundled entitlements — and the audit-defence implications depend on which mix applies to which deployment. This article works through NSX advanced licensing in the current Broadcom era, with focus on where audit findings actually surface.

The NSX edition structure today

NSX is licensed in the current Broadcom catalogue at three primary tiers, each with defined feature scope:

• NSX Professional — base networking and switching, distributed routing, basic firewalling. Suitable for connectivity-only deployments.
• NSX Advanced — adds advanced features around firewalling, gateway services, VPN, and certain operational integrations. The mainstream enterprise tier.
• NSX Enterprise Plus — adds the full security feature set including distributed IDS/IPS, advanced threat prevention, Network Detection and Response (NDR), and federation across NSX domains. The top tier.

The Advanced Load Balancer (Avi) is licensed separately from these tiers in most SKU constructions, with its own service-engine and core metrics. NSX bundled under VMware Cloud Foundation is generally at the Advanced tier, with limited Enterprise Plus features and with Advanced Load Balancer as a separately included or separately purchased capability depending on the VCF SKU.

The legacy NSX-V and NSX-T product lines have largely converged into the current NSX product, though customers still operating NSX-V will be in or near end-of-support territory. Migration projects from NSX-V to NSX-T (now just "NSX") are common audit triggers because they typically expand scope and feature use as customers re-architect.

Feature creep — the most common audit finding

The single most common NSX audit finding is feature use above the licensed edition. The NSX management plane will let an administrator enable Distributed IDS/IPS if they have the UI permission to do so, regardless of whether the licensed edition includes IDS/IPS. The configuration is persisted, the feature is active, and the audit data request will surface it. This pattern is true for:

• Distributed IDS/IPS — requires Enterprise Plus; frequently enabled under Advanced licences as part of security-team initiatives
• Network Detection and Response (NDR) — Enterprise Plus only; often turned on during proof-of-concept and left enabled
• Federation across NSX domains — Enterprise Plus; required for multi-site stretched NSX architectures
• Advanced Threat Prevention — requires the dedicated ATP add-on; the integration is enabled in the manager UI without licence check
• VPN with advanced capabilities — IPsec is included broadly; certain advanced VPN configurations are edition-gated
• Load balancing with advanced features — basic LB is in some editions; advanced LB (Avi) is separately licensed

The audit-discovery method here is straightforward. Broadcom requests NSX manager exports — the configuration of distributed firewall rules, IDS/IPS profiles, NDR settings, VPN configurations, load balancer service engines. These exports are compared against the licensed edition feature matrix. Anything enabled above the licensed edition is a finding.

The microsegmentation problem

Microsegmentation — the use of NSX distributed firewall to enforce east-west policy between workloads — is one of the most commonly deployed NSX use cases. It is also one of the most common sources of over-deployment claims, for two reasons.

First, microsegmentation typically deploys NSX agents to every VM in the protected estate. If the NSX licence is per-core or per-CPU of host capacity, every host carrying protected VMs is in scope. Customers who deploy microsegmentation broadly often find that the licensed core count does not match the protected host count.

Second, microsegmentation effectiveness improves with the security features in Enterprise Plus — IDS/IPS detection inside the segmented traffic, NDR correlation across segments, advanced threat profiles. Security teams enable these features because they improve the security outcome, often without confirming the licence edition supports it.

The combination — broad deployment plus feature creep — is why microsegmentation NSX deployments are routinely the largest audit-finding items in NSX-heavy estates.

NSX under VCF — what is and is not included

VMware Cloud Foundation includes NSX as a bundled component in most SKUs. The bundled NSX is at the Advanced tier in standard VCF and at higher tiers in the larger VCF editions. The bundle has three important constraints:

Scope constraint: The bundled NSX entitlement covers the VCF-licensed compute estate. NSX deployed to manage non-VCF hosts is outside the VCF entitlement and requires standalone NSX licensing.

Edition constraint: The bundled NSX is at a defined edition (typically Advanced). Use of Enterprise Plus features within the VCF estate requires either an upgrade to a higher VCF tier or separate Enterprise Plus licensing.

Add-on constraint: Advanced Load Balancer (Avi) and Advanced Threat Prevention (ATP) are typically not in the base VCF bundle. They are add-on entitlements purchased separately, even when running on VCF-managed hosts.

Customers who treat the VCF bundle as a "we have NSX" answer to all NSX licensing questions are routinely surprised in audit. The right framing is: VCF includes a defined NSX edition with defined scope, and any deployment, feature, or scope beyond that requires separate licensing.

The metric problem — cores vs CPUs vs hosts

NSX has been licensed across several metrics in its history: per-VM, per-CPU socket, per-CPU core, per-host. The current Broadcom subscription model is predominantly per-core, with minima per host. Customers carrying perpetual NSX licences from earlier eras may have different metrics.

The audit-defence implication is that the customer needs to understand the metric in their specific entitlement, count the deployment against that metric, and not rely on the current metric for a legacy entitlement. A customer with a per-CPU socket perpetual NSX licence does not need to convert to per-core to validate compliance against that entitlement — they need to count CPU sockets.

Where the customer has migrated some hosts to a subscription metric and some remain on perpetual, the inventory needs to separately track each. This is one of the cleanups that pays off in audit defence: clear documentation of which hosts run under which metric.

Advanced Load Balancer (Avi) licensing

The former Avi Networks load balancer, now NSX Advanced Load Balancer, has its own licensing structure built around service engines and core consumption. Avi can run in two primary modes:

• Self-service via NSX integration — Avi managed through the NSX manager, with consumption tracked against the Avi entitlement
• Standalone Avi controller — deployed independently, with Avi's native licensing model based on service-engine cores

The licensing metric for Avi is typically service-engine vCPU/core counts plus the number of virtual services. Customers expanding Avi usage beyond a small footprint often find that their initial entitlement, sized for a proof-of-concept, is much smaller than the production deployment. Audit defence requires an inventory of service engines, vCPU counts, and virtual services, mapped against the entitlement.

Advanced Threat Prevention (ATP)

Advanced Threat Prevention — the former Lastline product line — is licensed as an add-on. It includes the malware analysis sandbox, the network detection capabilities, and the threat intelligence feed. ATP is not included in VCF base bundles and is a separate purchase even alongside NSX Enterprise Plus.

ATP is one of the most expensive add-ons in the NSX family. Per-protected-VM pricing scales aggressively. Customers who enable ATP integration during a security initiative and then leave it running across a large VM population often find this is the single largest finding in an NSX audit. The remediation discussion typically involves either reducing the protected scope substantially or buying entitlement to match.

Federation, multi-site, and Enterprise Plus

Multi-site NSX deployments — multiple NSX domains federated under a single global manager — require Enterprise Plus across the federated estate. Customers who deploy a "global" NSX architecture without confirming the edition uplift across all member sites are exposed.

The audit discovery here is the federation configuration itself, which is visible in the global manager and in each local manager. A federation in place means Enterprise Plus is required; if even one local manager is at Advanced or Professional, the deployment is out of compliance.

NSX for container networking

NSX integrates with Kubernetes via the NSX Container Plugin (NCP) and with Tanzu Kubernetes Grid for in-cluster networking. The licensing scope of NSX when used for container networking is determined by the underlying host or core licensing, with additional considerations for the container workloads being managed. Customers deploying NSX as the container network on top of unlicensed hosts — for example, on Tanzu running on non-VMware infrastructure — face additional licensing complexity that the standard NSX SKU does not cleanly cover.

Defence steps for an NSX audit

Step 1: Produce the entitlement summary

List every NSX entitlement the customer holds, including legacy perpetual, transitioned subscription, VCF-bundled, and any add-ons (Avi, ATP). For each, document the metric, the count, the edition, and the scope.

Step 2: Produce the deployment inventory

For each NSX manager domain, document the hosts in scope, the cores/CPUs/VMs as relevant to the metric, the configured features (firewall, IDS/IPS, NDR, ATP, LB, VPN, federation), and the actual usage of each feature.

Step 3: Cross-reference deployment against entitlement

For each deployed feature, confirm it is within the licensed edition. For each scope element, confirm it is within the licensed quantity. Flag every gap.

Step 4: Decide on remediation for each gap

Three options for each gap: reduce the deployment to fit the entitlement (disable the feature, reduce scope), buy entitlement to cover the deployment, or document a contractual position. The third path is hardest and usually requires legal review.

Step 5: Document the position

Produce a dated, signed-off compliance position for the NSX estate. This becomes the response to Broadcom's data request and the basis of any defence negotiation.

Negotiation levers

When NSX audit findings are material, the customer has several levers in negotiation:

• Trade-up to VCF — converting the NSX standalone into VCF bundling with Enterprise Plus capability is a common path; Broadcom is incentivised to push customers toward VCF
• Term commitment — extending the subscription term in exchange for waiver of historical claim
• Scope contraction — committing to disable specific features (typically ATP, NDR, federation) in exchange for reduced or zero remediation
• Edition uplift — moving from Advanced to Enterprise Plus across the relevant estate, sometimes at discount, in exchange for waiver

The lever that works best depends on what Broadcom's account team is being measured against and what the customer is willing to commit. Most settlements involve some combination of the above rather than a clean cash payment of the original claim.

Common myths

"VCF includes everything NSX"

It includes a defined edition of NSX, at a defined scope, for the VCF-licensed cores. It does not include Avi, ATP, or scope beyond VCF cores.

"If the feature is in the UI it must be licensed"

The NSX manager UI exposes features regardless of edition. The licence is contractual, not enforced by the software. Enabling a feature does not mean the customer is entitled to it.

"Microsegmentation is a basic feature"

The distributed firewall enabling microsegmentation is in most editions. The advanced security features that make microsegmentation effective (IDS/IPS, NDR) are not. Edition matters.

"Federation is just a configuration"

Federation is an Enterprise Plus capability and requires Enterprise Plus across all federated sites. Configuring federation without the edition is a finding.

Frequently asked questions

What edition of NSX do we need for microsegmentation?

Basic microsegmentation (distributed firewall rules) is in Advanced and above. Effective microsegmentation typically uses IDS/IPS and NDR features that require Enterprise Plus.

Is Advanced Load Balancer included in VCF?

Generally no — it is an add-on. Some larger VCF SKUs include limited Advanced LB scope; verify against the specific contract.

Can we run NSX on non-VMware hosts?

NSX runs on ESXi hosts (and KVM in some legacy configurations). The licensing question is whether those hosts are within scope of the NSX entitlement. Hosts outside the licensed core/CPU count need additional NSX licensing.

What happens to NSX-V customers under Broadcom?

NSX-V is in end-of-support. Customers with active NSX-V deployments are typically being directed to migrate to NSX (T-equivalent), often through a VCF transition. The migration project is a frequent audit trigger.

How does Broadcom discover NSX feature use?

Through manager configuration exports, which include firewall rules, IDS/IPS profiles, NDR settings, VPN configurations, federation status, and integration with ATP. These exports are routine data requests in NSX audits.

What is the typical remediation for an NSX feature finding?

Edition uplift across the affected scope, often with retroactive subscription fees. Common settlements involve trade-up to a higher VCF tier in exchange for waiver of historical claim.