Can Broadcom Disable Your Perpetual VMware License?

No. There is no remote kill switch. Broadcom cannot reach into your environment and switch off a perpetual licence, and its own documentation confirms that the expiration of Support and Subscription does not revoke the underlying entitlement. The software you bought keeps running.

That is the reassuring half of the answer, and it is where most articles stop. The half that actually matters is this: the constraint is version, not time. What you own is the right to run the specific build and version you held on the final day of your active SnS contract — not whatever the latest 8.x release happens to be today.

This piece exists because a customer asked us exactly that question, almost word for word: can Broadcom remove it remotely at any time, or is it legally ours forever — and can we keep running the latest version of 8 while we plan a migration? The short answer is that the first part is safe and the second part is not. Here is why.

A perpetual licence and a support contract are two different purchases, and the confusion comes from treating them as one.

The perpetual licence is a right to run the software, and it does not expire. Nothing about a lapsed support contract revokes it, disables it, or requires you to stop.

Support and Subscription (SnS) is what entitles you to new software — updates, patches, maintenance releases, upgrades — plus the right to contact support. When it lapses, that entitlement stops on that date.

So the line is drawn at a moment in time. Everything published up to your expiration date, you own and may run indefinitely. Everything published after it, you do not. The licence keeps working; the tap of new bits is closed.

The practical consequence catches people out: an estate that has been dutifully applying updates for a year after its contract lapsed is not comfortably compliant. It is running software it was never entitled to receive — and that is the specific behaviour Broadcom has chosen to pursue.

From around May 2025, Broadcom began sending cease-and-desist letters to perpetual licence holders whose support had expired. This is documented across multiple independent outlets, and it is not a rumour circulating in forums.

The letters demand the immediate removal and de-installation of any software releases, updates, patches or enhancements installed after the support expiration date. They characterise continued use of those updates as a material breach of the agreement and an infringement of VMware's intellectual property rights, and they reference potential claims for enhanced damages and attorneys' fees. Reporting indicates some letters arrived within days of a contract lapsing.

Two details are worth knowing because they change what you should do.

• There is a narrow zero-day carve-out. Reporting on the letters indicates an exception for zero-day security fixes. That is a genuine and sensible carve-out, and it is not a patching strategy — everything else published after your expiration date sits outside it.
• The letters reserve audit rights. The agreements generally oblige customers to report VMware usage even after a contract has ended, and failure to do so is treated as a breach that triggers those rights. A lapsed contract is an open compliance obligation, not a closed chapter.

None of this means a lapsed estate is about to be sued. It does mean the informal industry assumption — that you quietly keep patching and nobody notices — has stopped being true.

This is the question behind the question, and it is a reasonable plan on its face: hold the current environment steady, buy hardware, migrate to something else on your own timeline, spend nothing extra in the meantime.

It works — with one correction. You can stay on the build you were entitled to. You cannot stay on the latest 8. If the release currently running was published after your expiration date, it is outside what you own, and it is exactly what the letters ask you to remove.

So the first task is not a decision, it is a fact-find: which build were we actually entitled to on our expiration date, and which build are we running now? Those two answers are often different, and nobody discovers that comfortably during an audit.

If they match, holding steady while you plan a migration is a legitimate strategy. You are accepting a frozen, unpatched hypervisor for the duration — a real security position that your risk owners should sign off on explicitly, not a technicality.

If they do not match, you have a remediation question to answer before you have a migration question.

Every lapsed or lapsing estate lands on one of four paths. They are not equally good, and the right one depends on estate size, risk tolerance and how close your renewal timing is.

One timing note that increasingly forces the issue: vSphere Standard and Enterprise Plus stop at 8 Update 3, with an end-of-life date in October 2027, and there is no standalone vSphere 9 to upgrade into. Estates planning to sit still until they migrate should check that their sit-still window actually reaches their migration date.

Four concrete steps, in order, whether or not a letter has arrived.

1. Establish your expiration date and entitled build for every perpetual SKU you hold. Not the version you are running — the version you were entitled to on that date.
2. Compare against what is actually deployed. Any host running a post-expiration release is the exposure, and you want that list before anyone else asks for it.
3. Write down the risk position. If you are staying frozen, that is a decision someone should own in writing, with the unpatched exposure stated plainly.
4. Price the alternatives before you need them. Reinstatement, subscription and migration all take longer to arrange than the notice period a letter gives you.

If you want that inventory checked, or the reinstatement and subscription options priced side by side against your actual core counts, talk to AceMQ — we are a Broadcom partner and we quote this weekly. We will also tell you when running frozen is the sensible answer, because sometimes it is.