VMware License Compliance Checklist
Compliance is not a one-time exercise. The subscription model creates a continuous reconciliation between deployed cores, deployed features, and entitled scope. This is the operational checklist we use with clients to hold the position quarter over quarter.
License compliance for VMware under Broadcom is not a one-time exercise. The subscription model creates a continuous reconciliation between deployed cores, deployed features, and entitled scope — with the reconciliation surface changing as hardware is refreshed, clusters are reorganised, workloads are migrated, and entitlements roll across renewals. Customers without a maintained compliance posture produce audit findings; customers with a maintained compliance posture defend their entitlement scope effectively.
This checklist is the operational reference we use with clients to maintain VMware compliance across the post-acquisition catalogue. It is organised into the five compliance areas where audit findings cluster: core counting, edition usage, feature deployment, environment scope, and entitlement records. Each area has a set of operational practices that, executed consistently, hold the customer's compliance position.
Core counting compliance
Core counting is the single largest compliance surface. The subscription model licenses a defined core count; deployment that exceeds the count is the most common audit finding.
Maintain a host-level inventory
Maintain an inventory of every host running VMware software, with the host's CPU model, physical core count per CPU, total physical core count, and cluster assignment recorded. The inventory should be refreshed quarterly and on every hardware change. The principal source is the vCenter inventory; the discipline is treating the inventory as a managed asset rather than a transient operational record.
Apply the 16-core minimum per CPU
Apply the per-CPU minimum-floor calculation to the inventory. Each CPU below 16 physical cores is counted at 16. Sum the floor-adjusted core counts across hosts to produce the entitlement-counted core total. The sum should be compared monthly against the entitled core count.
Track decommissioning explicitly
Hosts being decommissioned should be tracked through the decommissioning process. Hosts powered down but not formally decommissioned still count toward the entitlement reconciliation in most cases. The decommissioning record should include the date the host was removed from the vCenter inventory and the date the underlying hardware was retired or repurposed.
Reconcile against entitlement quarterly
Compare the floor-adjusted deployed core count against the entitled core count at least quarterly. Variances of more than 5% should trigger investigation; variances of more than 10% should trigger a remediation plan. The reconciliation should be documented and retained.
Edition usage compliance
Edition compliance turns on the principle that licensed editions gate the available feature set. Using features that require a higher edition than the licensed edition produces a finding.
Map deployed editions to licensed editions
Maintain a mapping between deployed software editions (as configured in vCenter and in the licensed feature set) and the entitled editions in the subscription. Discrepancies — deployed editions higher than entitled — need to be remediated by either down-revving the deployment or upgrading the entitlement.
Identify edition-gated features in use
Several features are gated by edition. Distributed switching, Storage DRS, DRS, certain vSAN features, NSX edition-specific features, and Aria edition-specific features each have an edition floor. Maintain a register of edition-gated features in actual use, with the edition each requires, and reconcile against the licensed entitlement.
Watch for edition creep
Edition creep — the gradual adoption of features that require higher editions than the customer originally licensed — is a common driver of findings. The discipline is to review feature adoption at each major operational change and to validate that the change is supported by the licensed edition.
Some edition-gated features are technically usable on a lower-edition deployment because the runtime does not enforce the edition boundary in all cases. The audit reconciliation does enforce it. The fact that a feature was usable is not a defence against a finding that it required a higher edition.
Feature deployment compliance
Several VCF-bundled components have entitlement-scope limits that go beyond core counting and edition assignment. These need their own compliance discipline.
NSX scope
NSX inside VCF is deployed across the cores covered by the VCF entitlement. NSX deployed across additional hosts — even hosts running vSphere outside the VCF entitlement — produces a finding. Maintain an NSX-host-list and reconcile against the VCF-licensed host list.
vSAN scope
vSAN inside VCF can be deployed at full capacity across the licensed cores. vSAN deployed outside the VCF-licensed host scope — on hosts not within the VCF entitlement — produces a finding. Reconcile vSAN-deployed hosts against VCF-entitled hosts quarterly.
Aria scope
Aria suite components inside VCF cover monitoring and automation of the VCF-licensed environment. Aria scope extended to non-VCF estate — managing additional VMware deployments or non-VMware infrastructure beyond the entitlement scope — produces a finding. Validate the scope of Aria-managed assets against the entitled scope.
Tanzu scope
Tanzu Standard inside VCF covers Kubernetes runtime on the licensed cores. Tanzu Platform features deployed under the assumption of VCF coverage produce findings. Tanzu Mission Control extended to non-TKG Kubernetes clusters beyond the bundled scope produces findings. Validate Tanzu deployment scope against the bundled entitlement.
HCX scope
HCX inclusion in VCF is bounded by use-case scope. Migration use cases are typically covered; broader use cases may require additional entitlement. Validate HCX usage against the entitled scope.
Environment scope compliance
The entitled environment under a subscription is bounded. Deployment outside the entitled environment is a finding.
Document the entitled environment
Document the entitled environment explicitly: the sites, the data centres, the clusters, and the boundary between entitled and unentitled hosts. The document should be maintained at the same cadence as the host inventory.
Manage cloud-destination deployments
Deployments to AWS, Azure, GCP, IBM Cloud, Oracle Cloud, or other cloud destinations require participation in the relevant cloud programme. Document the cloud-destination scope, the programme arrangements, and the entitlement coverage for each destination.
Manage hosting-partner deployments
Deployments via hosting partners follow the hosting partner's licensing arrangement. Document the hosting-partner arrangement, the entitlement scope at the partner, and the customer-side or partner-side ownership of the underlying VMware subscription.
Manage DR-site scope
DR sites that are active or warm consume entitlement; cold DR sites typically do not. Document the active/cold status of each DR site, the operational conditions under which each is operated, and the entitlement implication. The DR documentation supports both ongoing compliance and audit defence on contested DR-scope questions.
Entitlement records compliance
The entitlement records held by the customer need to match the entitlement records held by Broadcom. Discrepancies between the two are a source of audit-defence complications.
Maintain a copy of every entitlement record
Every entitlement — subscription contract, OEM-bundled record, amendment, and renewal — should be retained in the customer's records. The retention should outlast the entitlement period; entitlement records from prior periods inform audit reconciliation back to the period of activity.
Reconcile against the Broadcom Support Portal
The Broadcom Support Portal displays the entitlements Broadcom has recorded against the customer's account. Reconcile the customer-side record against the portal record at least annually. Discrepancies should be raised with Broadcom and documented in the reconciliation record.
Track amendments and renewals carefully
Amendments, renewals, and add-ons all modify the entitlement. The cumulative effect of multiple modifications can be difficult to reconstruct after the fact; maintain a clean chronology of entitlement changes with the supporting contractual evidence.
OEM-procured records
OEM-bundled entitlements pass through the OEM's reporting channel to Broadcom. Validate that OEM-bundled entitlements are reflected in the Broadcom-side records; gaps in the OEM-to-Broadcom propagation produce apparent entitlement deficits at audit.
Continuous compliance practices
Several operational practices support the compliance posture continuously rather than at specific events.
Quarterly compliance review
Conduct a quarterly compliance review covering core counting, edition usage, feature deployment, environment scope, and entitlement records. The review should produce a written report flagging any variance from the entitled position and any open remediation items. The report should be reviewed by IT leadership and retained as audit-defence evidence.
Change-management integration
Integrate VMware-licensing impact assessment into the change-management process. Hardware additions, cluster expansions, feature adoptions, edition upgrades, and scope changes should each be reviewed for licensing impact before execution.
Renewal preparation
Renewal preparation should start six to nine months ahead of the renewal date. The preparation includes a full compliance review, an entitlement-position validation against deployment, and a forward-projection of deployment scope across the renewal term. The renewal commercial should reflect the validated position rather than the historic commitment.
Audit-readiness drill
Conduct an audit-readiness drill annually. The drill simulates the audit reconciliation process: produce the host inventory, the floor-adjusted core total, the edition usage register, the feature deployment register, the environment scope documentation, and the entitlement records. If the drill produces a clean reconciliation, the compliance posture is sound; if it produces gaps, those gaps are the priority remediation items.
The compliance team and ownership model
License compliance is typically owned by a combination of IT operations (who hold the deployment data), procurement (who hold the entitlement records), and IT asset management (who maintain the reconciliation). The principle that matters is that one role has explicit ownership of the compliance posture; in our experience, compliance disciplines that are shared across roles without explicit ownership typically deteriorate.
The ownership-role experience profile varies by customer scale. Smaller customers (single-data-centre deployments under a thousand cores) typically assign compliance to a part-time owner within IT operations or IT asset management. Mid-sized customers (multi-site deployments at thousands of cores) typically dedicate a full-time owner. Enterprise customers (large multi-site, multi-cloud deployments) typically operate a small team with the owner role at the IT-asset-management or software-asset-management function.
The compliance posture at specific events
Several events in the deployment lifecycle require specific compliance-posture attention beyond the ongoing operational disciplines.
Hardware refresh events
Hardware refresh produces immediate licensed-core impact and may produce edition-scope impact. Pre-refresh: model the post-refresh licensed-core count under the per-core arithmetic; identify any entitlement adjustment required. Post-refresh: validate the actual licensed-core count against the modelled count; document the change in the host inventory.
Cluster expansion events
Cluster expansions add hosts to the licensed environment. Pre-expansion: validate the post-expansion core count against the entitlement; identify any entitlement adjustment required. Post-expansion: update the host inventory and the licensed-environment register.
Feature adoption events
Adoption of new features may invoke edition requirements not present in the current entitlement. Pre-adoption: validate the feature's edition requirement against the licensed edition; identify any entitlement adjustment required. Post-adoption: document the new feature in the feature-deployment register.
Decommissioning events
Decommissioning produces opportunities for licensed-core reduction. Pre-decommissioning: identify the licensed cores associated with the decommissioned hosts; plan the entitlement adjustment at the next renewal cycle. Post-decommissioning: update the host inventory and the licensed-environment register.
M&A events
Mergers, acquisitions, and divestitures produce licensed-entitlement integration complications. Pre-event: validate the entitlement scope of each entity; identify any portability constraints. Post-event: integrate the entitlements (in the case of acquisition) or separate them (in the case of divestiture); document the post-event entitlement structure.
The compliance documentation pack
Maintain a defined compliance documentation pack that supports both ongoing operations and audit defence. The pack should contain:
The current host inventory with CPU model, physical core count, total core count, cluster assignment, and entitlement attribution for each host. Refreshed quarterly.
The current entitlement register listing all active subscriptions, OEM-bundled entitlements, amendments, and renewals with date, scope, and term details.
The licensed-environment register documenting sites, data centres, clusters, and the entitled-environment boundary.
The feature-deployment register listing all edition-gated features in active use with the licensed edition requirement for each.
The cloud-destination programme record documenting each cloud destination's programme participation and the entitlement-coverage arrangement.
The DR-site posture record documenting active/cold status and operational conditions for each DR site.
The compliance-review history with quarterly review reports and remediation tracking.
The Broadcom Support Portal reconciliation records documenting the annual reconciliation against Broadcom-side entitlement records.
What audit-defence engagements typically require
Audit-defence engagements typically begin by requesting the compliance documentation pack. The customer who has maintained the pack across the deployment lifecycle is materially better positioned than the customer who must reconstruct the pack at audit notice. The reconstruction effort under audit deadline pressure typically produces worse outcomes than steady-state maintenance.
Related reading
For deeper detail on adjacent topics, see the VMware licensing complete guide, per-core licensing mechanics, licence portability rules, licence harvesting, licence key management, and our VMware audit defence guide.