VMware License Key Management

VMware license key management is one of the operational practices that most often determines audit outcome — not because the keys themselves are sensitive (the discovery process does not depend on customer key inventory), but because how well an organisation manages its keys is a proxy for how well it actually controls deployment, decommissioning, and capacity. Customers with disciplined license key management consistently produce cleaner audit responses and stronger negotiating positions. Customers with chaotic key management consistently produce data that Broadcom uses against them. This article is a practical guide to enterprise-grade VMware license key management in the post-Broadcom era.

What "license key management" actually covers

The phrase covers four operational disciplines:

• Inventory — knowing what licences you hold, in what entitlements, at what versions and editions, with what expiration dates
• Assignment — knowing which licences are applied to which environments, hosts, and clusters, with documented mappings
• Lifecycle — tracking activation, deactivation, transfer between environments, and retirement of licences as hardware changes
• Reconciliation — periodically comparing the entitlement inventory against actual deployed state and resolving discrepancies

Each of these has direct audit implications. Inventory gaps mean you cannot prove what you bought. Assignment gaps mean you cannot prove where licences are applied. Lifecycle gaps mean unused licences accumulate or, worse, licences are reused without proper deactivation. Reconciliation gaps mean the difference between what you bought and what is deployed grows over time without correction.

The Broadcom-era complications

Several Broadcom-era changes have made VMware license key management materially more complex than it was under pre-acquisition VMware:

Subscription-only entitlements

Perpetual licences had a long life cycle and relatively stable key inventory. Subscription entitlements roll over at term boundaries (typically annually or triennially), generating new entitlement records and sometimes new key material. Customers who treated key inventory as a once-a-year exercise under perpetual licensing now need ongoing maintenance under subscription.

The Broadcom Support Portal transition

VMware's myvmware.com licence portal was migrated into the Broadcom Support Portal during 2024–2025. The migration affected how customers access their licence entitlements, how keys are downloaded, and how licence reports are generated. Many enterprises lost visibility into their licence inventory during the transition; some still have not fully reconciled the post-migration entitlement state.

Edition consolidation and re-bundling

Pre-Broadcom edition SKUs (vSphere Standard, vSphere Enterprise Plus, vSAN editions, NSX-T editions, vRealize editions) were rebundled into vSphere Foundation and VCF subscription tiers. The mapping from old entitlements to new entitlements is not always obvious and was handled differently for different customers. Some organisations have orphaned entitlement records from the migration that do not map cleanly to current deployment state.

VCF bundle scope

A single VCF entitlement covers multiple products — vSphere, vSAN, NSX, Aria Operations, Tanzu — through a single licence key. This simplifies management in one sense but complicates audit defence because compliance must be evaluated against the bundle as a whole, not against individual product components. Customers used to thinking per-product need to reframe to think per-bundle.

Building a license key inventory

A complete license key inventory should capture, at minimum:

• Each entitlement record (the contractual purchase artefact)
• The Broadcom Support Portal reference for each entitlement
• The licence key string(s) associated with each entitlement
• The product, edition, and version range each key covers
• The quantity covered (cores, CPUs, hosts, VMs, or other unit depending on product)
• The effective start date and expiration date
• The contracting entity (legal entity within the customer organisation that owns the entitlement)
• The associated commercial document (PO, contract, order form)
• The current deployment status — applied, partially applied, unapplied, retired

This inventory should live in a system of record — typically a CMDB, ITAM platform, or dedicated SAM tool. Spreadsheets work for small footprints but become unsustainable beyond a few dozen entitlements. The key requirement is single source of truth: there should be exactly one authoritative record of what your organisation owns.

Assignment tracking

Once the inventory exists, assignment tracking maps each licence key to where it is actually applied. This typically uses two parallel sources:

vCenter / Aria Operations data — vCenter knows which licences are applied to which hosts. Aria Operations (or its predecessor vRealize Operations) consolidates licence application across multiple vCenters. Both produce report outputs that show licence-to-host mapping at a point in time.

The organisation's CMDB — independent of what vCenter reports, the customer's CMDB should maintain its own record of what licence applies where. This redundancy is important because vCenter data can be inaccurate (cached, stale, or affected by configuration anomalies) and because audit defence requires the customer's own corroborating documentation.

When the two sources disagree, the discrepancy needs to be investigated and resolved. Persistent disagreements between vCenter and CMDB are an early warning sign of broader license management problems.

Lifecycle management

License keys move through a lifecycle that needs explicit management:

Activation — when a new entitlement is purchased and the key is first applied to an environment. This should generate a record in the inventory and an assignment record linking the key to its deployment location.

Reassignment — when a key is moved from one host or cluster to another. This is common during hardware refresh, environment consolidation, or capacity rebalancing. Each reassignment should be logged.

Deactivation — when a host or environment is decommissioned and the licence becomes available for reuse. This requires explicit action to "release" the licence; many customers leave decommissioned licences in place, which inflates the apparent deployment footprint without contributing capacity.

Retirement — when an entitlement is allowed to lapse (subscription not renewed) or when perpetual licences are retired. The retirement event should be reflected in the inventory and the licences confirmed as no longer in use anywhere.

Reconciliation discipline

Regular reconciliation — quarterly at minimum, monthly for high-change estates — is what keeps the inventory accurate over time. The reconciliation compares three things: what the contractual inventory says you own, what the deployed environment actually shows applied, and what the CMDB records as current state. Discrepancies between any two of the three need investigation.

Customers who reconcile diligently produce audit responses where the contract, the technical environment, and the documentation all align. Customers who do not reconcile produce audit responses where Broadcom finds discrepancies that the customer cannot explain, which inflates settlement demands.

The Broadcom Support Portal: what changed and how to manage it

The migration from myvmware.com to the Broadcom Support Portal during 2024–2025 changed several practical things:

• Single sign-on — Broadcom Support Portal accounts are separate from legacy VMware accounts; many customers needed to re-establish access
• Entitlement visibility — entitlement records were migrated but presentation, search, and download experiences changed
• Report formats — licence reports and downloadable artefacts now use Broadcom formats rather than VMware formats
• Role and access management — assigning portal access to internal staff follows Broadcom's role model

For customers who have not fully reconciled the post-migration state, the practical recommendation is: log in, generate a full entitlement export, and compare it against your independent record of what you purchased. Discrepancies should be raised with Broadcom support promptly; the longer the gap between migration and reconciliation, the harder it becomes to substantiate ownership.

Audit implications

License key management discipline shows up in audit defence in several specific ways.

Faster and narrower scoping. A customer with a clean inventory can scope an audit with precision — "we own entitlement X covering Y cores in legal entity Z, deployed in environments A and B" — which limits Broadcom's discovery to those scopes. Customers without clean inventory cannot scope tightly, so Broadcom's discovery defaults to broader.

Better claim methodology challenge. Broadcom's claim methodology applies a calculation to the discovered deployment data. A customer with documented assignment records can challenge Broadcom's calculation point by point. A customer without documentation cannot, so Broadcom's calculation goes substantially unchallenged.

Stronger negotiating position. Settlement negotiations are partly about who has better data. The party with cleaner records typically dictates more of the framing. License key management discipline puts the customer in the stronger position.

Faster recovery from inadvertent overuse. When customers discover they have been over-deployed (a real and common situation), having clean records lets them resolve the over-deployment cleanly. Without clean records, every remediation step generates new uncertainty.

Tools and automation

Three categories of tooling support enterprise license key management:

SAM platforms — Flexera, Snow, ServiceNow SAM, Aspera all support VMware licence tracking. They vary significantly in depth; some primarily handle Microsoft, IBM, and Oracle well and treat VMware as a secondary use case. Evaluate based on VMware-specific functionality.

VMware-native tooling — vCenter, Aria Operations, and the Broadcom Support Portal collectively provide native visibility. The native tooling is necessary but not sufficient; supplement with independent records.

Custom scripts and integrations — many enterprises maintain custom PowerShell or Python scripts that pull data from vCenter and reconcile it against their internal CMDB. Custom tooling is the most flexible approach but requires ongoing maintenance.

Governance and ownership

License key management has to be owned by a specific function within the organisation. The most successful models we see are:

• Centralised in IT asset management with a dedicated VMware lead, supported by virtualisation engineering for operational data
• Distributed by business unit with central oversight, where each BU maintains its own inventory but a central team reconciles across BUs
• Outsourced to a managed SAM provider with the customer retaining audit-defence ownership and using the SAM provider's data

The unsuccessful model is "shared between procurement and IT" with no clear owner. Without a single accountable owner, licence inventory deteriorates over time and audit defence becomes reactive.

Frequently asked questions

How often should we reconcile the licence inventory?

Quarterly at minimum. Monthly for environments with high change rates (frequent hardware refresh, frequent capacity reorganisation). The cost of more frequent reconciliation is modest; the cost of letting drift accumulate is meaningful in audit defence.

What if the Broadcom Support Portal shows different entitlements than we believe we own?

Raise the discrepancy with Broadcom support immediately, with documentary evidence of your purchase (POs, contracts, order forms). The longer the gap between portal migration and your reconciliation, the harder it becomes to resolve discrepancies. Some customers discovered, months after migration, that entitlements they purchased did not migrate cleanly; these cases require formal support cases to resolve.

Can we use vCenter as the single source of truth?

Not safely. vCenter shows what licences are currently applied, which may not match what is owned (over-deployment, partial deployment, decommissioned hosts still showing assignments) and which Broadcom does not consider authoritative for entitlement purposes. The contract is the source of truth for what is owned; vCenter is one input into how it is deployed.

What happens to perpetual licence keys after Broadcom?

Perpetual licences continue to function. The keys themselves do not expire. SnS support, where applicable, may have been renewed at increased rates or transitioned to subscription. Customers with active perpetual licences should treat them with the same inventory discipline as subscription entitlements.

How does the licence assignment data feature in audit defence?

Heavily. The audit discovery measures deployed state; the customer's licence assignment data is the basis for explaining how that deployed state aligns with entitlement. Customers who can produce contemporaneous assignment records routinely defeat audit claims that customers without such records cannot defeat. The records do not need to be elegant; they need to be present.