How Does VMware Licensing Work in an Air-Gapped Environment?

Standard VMware Cloud Foundation licensing assumes your infrastructure can reach Broadcom's licensing servers over the internet. For air-gapped environments — defense programs, classified networks, and any deployment where outbound connectivity is prohibited by policy — that assumption breaks down completely, and the standard activation flow simply isn't available.

This post covers how air-gapped VMware licensing actually works, based on a real defense-sector discovery call, including the specific activation model available for qualified government customers.

In a normal, internet-connected deployment, VCF's centralized license server communicates outbound to Broadcom's licensing infrastructure to verify and activate your license. In an air-gapped environment, that outbound connection simply isn't available — and for many defense and government environments, it's not just unavailable, it's explicitly prohibited by policy, since no exfiltration of data is allowed at all in the most restrictive environments.

Broadcom has three distinct activation models to handle this spectrum, not just one "offline mode":

1. Standard connected activation. The license server communicates directly with Broadcom's licensing servers. Not viable for air-gapped environments.
2. Disconnected mode. You generate a file from your license server describing what you're looking to license (a human-readable file, specifically designed so your organization's security/IA team can review exactly what data it contains before it leaves your environment), manually upload that file to the Broadcom website from a separate connected system, and receive an activation response back the same way. This is a one-way, manually-controlled data transfer rather than a live connection — as it was described directly: "You control the exfiltration of the data... there's no constant connection going back and forth."
3. Single-activation licensing for qualified government/defense customers. For environments where even the disconnected-mode file transfer would violate air-gap policy (no data leaves the environment under any circumstance), a third model exists: the system is activated a single time based on a direct conversation about core count, generating an activation file that's applied once and remains active for the entire contract term — with no further data ever needing to leave the environment.

This depends specifically on your program's classification and connectivity policy — and it's worth confirming directly with your VMware/Broadcom account team rather than assuming, because the single-activation model is explicitly restricted to qualified customers.

In a real case, the single-activation, zero-exfiltration model was described as available specifically for a defense division's air-gapped environments working with federal government programs, and explicitly not available for the same company's commercial-side business unit. The determining factor wasn't the company — it was which specific division and program the environment supported, and whether that program qualified under the government-customer terms.

Practical next step: ask your Broadcom account contact directly which of the three activation models your specific program qualifies for — don't assume disconnected mode is your only option if your policy is stricter than that, since a further-restricted single-activation path exists for genuinely zero-exfiltration environments.

The core-counting mechanics are the same as connected licensing — subscription-based, per-core, with a minimum threshold — but the enforcement model in an air-gapped context is necessarily closer to a documented, contractual commitment than a live technical check.

For a real deployment scenario: two servers, two CPUs each, 32 cores per CPU, licensed by physical core (not by socket) — worked out to 128 total cores requiring licensing. The 16-core minimum applies per the standard subscription model, and licensing is scaled by adding cores in the same increments when new hardware comes online (for example, purchasing two additional identical servers later would add another 128 cores to the license).

What doesn't change in an air-gapped context: you still need an accurate physical core count for your hardware before requesting a quote or activation, since that count drives both the cost and the activation file itself.

Yes, if you have multiple sites or programs under the same larger organization — this is standard practice for defense and government customers with several disconnected or classified locations, and it's worth requesting deliberately rather than assuming a single generic account will suffice.

In a real air-gapped licensing case, this was explicitly called out: because the requesting program was one of potentially many similar programs under the same larger organization (each likely with its own physical infrastructure, not necessarily virtualized in the same way), a dedicated site ID specific to that location was requested — specifically so that the site wouldn't see or have access to licensing information belonging to any other site under the same parent organization.

When to request a dedicated site ID:

• Your organization has multiple air-gapped or classified locations under one parent account
• You need administrative and licensing separation between locations for security or compliance reasons
• You're using the single-activation model, since that model is explicitly tied to site ID as part of how the one-time activation is scoped

The commercial process is largely standard, even though the technical activation differs. A rough order of magnitude (ROM) quote — not yet a formal, binding quote — is typically the first artifact needed, used internally to get management buy-in on relative cost before engaging formal procurement.

In a real defense-sector case, the process flow was: engineering requests a ROM based on estimated core count → that ROM is used internally to justify the spend to management → once approved, the request moves to a dedicated procurement contact who processes it through the organization's established channel for that specific technology, since — as it was put directly — "this will probably be the 50th time this process would be executed this year" for an organization already running an established VMware relationship. Even for an air-gapped, defense-specific request, the underlying procurement relationship and process are usually already well-established and don't need to be built from scratch.

Standard terms to expect: five-year subscription terms are common for large defense/government VMware deployments, aligning licensing commitments with program lifecycles. Sole-sourcing software for a defense program is also typically difficult to justify — expect your procurement process to require comparative quotes even when you have a clear preferred vendor relationship already in place.

This is a related but separate question worth raising in the same planning conversation, particularly given current DDR5 memory pricing pressure. Recent versions of VMware's virtualization platform (VCF 9 and later) introduced memory tiering — the ability to dedicate NVMe storage to act as an extension of physical RAM for VM allocation purposes, rather than using that NVMe purely as storage.

In practical terms: a server with 1TB of physical DDR5 RAM can have additional NVMe memory dedicated (with mirroring for redundancy) and configured so the system allocates virtual machine memory against a combined pool — in current versions, as much as 4x the physical RAM can be added via NVMe-based memory tiering, a substantial improvement over the 1:1 ratio in earlier versions. This directly addresses a real cost pressure: DDR5 physical memory pricing has increased substantially, and memory tiering is explicitly positioned as a way to reduce the physical RAM procurement burden without sacrificing the VM memory pool size.

This is particularly relevant for air-gapped hardware procurement specifically, since air-gapped environments often can't easily "just add more hardware later" the way a cloud-connected environment can — getting the initial sizing right, including whether to leverage memory tiering, matters more when procurement cycles are longer and hardware changes are harder to make incrementally.

1. Confirm which of the three activation models (connected, disconnected, or single-activation) applies to your specific program — don't assume based on your organization's general status; it depends on the specific division and program.
2. Get an accurate physical core count for your target hardware before requesting a ROM quote.
3. Request a dedicated site ID if you have multiple locations under one parent organization.
4. Evaluate memory tiering as part of your hardware sizing, particularly given current DDR5 pricing pressure.
5. Engage your organization's established procurement contact for VMware/Broadcom rather than starting a new vendor relationship from scratch, if one already exists elsewhere in your organization.

Planning or troubleshooting a VMware Cloud Foundation deployment in an air-gapped or defense environment? AceMQ helps with VMware licensing model selection, sizing, and procurement — get VMware support or contact AceMQ to work through your specific environment.

• VMware Tanzu Support
• VMware Licensing Cost: How Pricing Actually Works
• VMware Licensing Changes: What Broadcom's Model Means
• AceMQ Home