VMware License Audit: How to Be Ready

Q: Is Broadcom auditing VMware customers?

Broadcom's license agreements reserve audit rights, and since 2025 the company has been actively enforcing the boundaries of perpetual entitlements — sending cease-and-desist letters to holders with lapsed support demanding removal of post-expiration updates. Whether or not a formal audit arrives, the practical position is that entitlement boundaries are being enforced in a way they were not before, so the sensible posture is to know your own numbers.

Q: What does a VMware license audit actually check?

Three things, in order. First, deployed core count against licensed core count — every populated socket, every physical core, measured against entitlements including the 16-core per socket and 72-core per order minimums. Second, edition and feature use: whether features in use are covered by the tier you licensed. Third, for perpetual holders, build and patch level against the date support lapsed.

Q: What is the most common finding?

Core count drift. Hardware gets refreshed, a host gets added to a cluster during an incident, a lab environment quietly becomes production. None of it goes through procurement, so entitlements never move — and per-core licensing turns every additional populated socket into a compliance gap. It is almost never deliberate.

Q: How do I gather the evidence?

From vCenter, export the host inventory with physical socket and core counts per host and per cluster. From your procurement records, gather every purchase order, entitlement certificate and renewal confirmation. Then reconcile the two, cluster by cluster. That reconciliation is the whole exercise, and doing it before anyone asks is the entire point.

Q: What if I find a gap?

Fix it on your own schedule rather than someone else's. A gap you find yourself is a true-up quoted at normal commercial terms during your next renewal conversation. A gap found during an audit is a compliance finding, and compliance findings are not negotiated from the same position. The difference is entirely about who discovered it.

Q: Does lapsed support create an audit exposure?

It creates a specific one. Perpetual licenses keep working, but the entitlement covers the builds you were entitled to while support was current. Running updates or patches installed after the support expiration date is the exposure Broadcom's letters have targeted. Knowing which of your hosts are on post-lapse builds is worth doing before anyone asks.

The difference between a true-up and a compliance finding is not the size of the gap. It is who found it.

A gap you discover yourself gets quoted at normal commercial terms in your next renewal conversation. The same gap discovered during an audit is a finding, and findings are not negotiated from the same footing. That is the entire argument for doing this work before anyone asks.

What an Audit Actually Checks

1. Deployed cores against licensed cores. Every populated socket, every physical core, measured against entitlements. This is where the 16-core per socket minimum and the 72-core per order minimum matter: they set the floor, and deployment above your entitlement is the gap. Per-core licensing means hardware changes and license positions have to move together.

2. Edition and feature use. Whether the features actually in use are covered by the tier you licensed. Mixed estates — some hosts on one edition, some on another, after years of piecemeal purchasing — are where this gets uncomfortable.

3. Build and patch level, for perpetual holders. Perpetual entitlements cover the builds you were entitled to while support was current. Updates installed after support expired sit outside that. This is the specific exposure Broadcom's 2025 letters targeted, covered in can Broadcom disable your perpetual license.

The Three Findings That Catch Most Estates

Core count drift. The most common by a distance, and almost never deliberate. Hardware refreshed to denser CPUs. A host added to a cluster during an incident and never removed. A lab environment that quietly became production. None of it routes through procurement, so entitlements never move.

Minimums not applied. Estates that last renewed before April 2025 were sized under the old rules. A sparsely populated socket still licenses at 16 cores; an order still floors at 72. Anyone who has not re-sized since then is working from a stale number.

Post-lapse patching. Perpetual holders whose support expired, who kept applying updates because the update path still worked. The software installing successfully is not the same thing as the entitlement covering it.

Common finding	Why it happens	How to close it
Core count drift	Hardware refreshed, hosts added in an incident, a lab became production	Reconcile cluster by cluster, then true up at renewal
Minimums not applied	Estate last sized before April 2025	Re-size with 16-per-socket and the 72-core floor
Post-lapse patching	Updates kept applying because the path still worked	Identify hosts on post-expiry builds before anyone asks

The Evidence Pack to Assemble Now

From vCenter: a host inventory export listing physical sockets and physical cores per host, grouped by cluster, with build and patch level. Include everything — labs, DR sites, dormant hosts. Anything powered on and licensed counts.

From procurement: every purchase order, entitlement certificate, renewal confirmation and support contract, including the ones from before the acquisition. Perpetual entitlements from years ago still matter, and they are usually the hardest documents to find.

The reconciliation: cluster by cluster, deployed cores against entitled cores, with the minimums applied. This is the actual deliverable. Everything else is input.

Keep it current. Re-run it whenever hardware changes and at every renewal. A reconciliation done once and left to age is how drift starts again.

If You Find a Gap

Close it during a renewal conversation, not a compliance conversation. Sizing a renewal to your true deployed footprint is an ordinary commercial transaction; it happens at list-adjacent pricing with the normal levers available, and nobody is characterizing it as a breach.

Do not resolve a gap by quietly decommissioning hosts the week before an audit. Deployment history is visible in vCenter, and it converts a routine true-up into a credibility problem.

If you want the reconciliation done properly and the result turned into a correctly sized renewal quote, talk to AceMQ. We are a Broadcom partner and this is a normal part of a renewal.

FAQ

Is Broadcom auditing VMware customers?

Agreements reserve audit rights, and since 2025 entitlement boundaries have been actively enforced — including cease-and-desist letters over post-expiration patching. Know your own numbers.

What does a VMware license audit actually check?

Deployed cores against licensed cores with the minimums applied; edition and feature use against the tier licensed; and for perpetual holders, build level against the support expiry date.

What is the most common finding?

Core count drift — hardware refreshes, hosts added during incidents, labs that became production. Almost never deliberate, and per-core licensing makes every populated socket count.

How do I gather the evidence?

vCenter host inventory with sockets, physical cores and build level; every purchase order and entitlement certificate; then reconcile the two cluster by cluster.

What if I find a gap?

Close it as a true-up in a renewal conversation. The same gap found during an audit becomes a compliance finding negotiated from a much worse position.

Does lapsed support create an audit exposure?

Yes, a specific one: perpetual entitlements cover builds you were entitled to while support was current, not updates installed after it expired.

Guides, comparisons and research

Go deeper on VMware

Ready to act?

Get Your VMware Renewal Priced Properly

AceMQ is a Broadcom partner. We size VCF and VVF against your actual core count, apply the minimums correctly, and return a quote you can compare — usually within 24 hours.

VMware Licensing Services →