What VMware’s licensing crackdown reveals about control and risk 

Not all risk is equal

VMware isn’t just another piece of enterprise software. It’s the plumbing. The foundation. The layer everything else runs on top of, which is precisely why many CIOs flinch at the idea of running unsupported. The potential risk is too great. A vulnerability or failure in your virtual infrastructure isn’t the same as a bug in a CRM. It’s a systemic weakness. It touches everything.

This technical risk is, without question, the biggest barrier to any organization considering support options outside of VMware’s official offering. And it’s a valid concern.  But technical risk isn’t black and white. It varies widely depending on version, deployment model, network architecture, and operational maturity. A tightly managed and stable VMware environment running a mature release with minimal exposure doesn’t carry the same risk profile as an open, multi-tenant deployment on a newer build.

Security without vendor support

The prevailing assumption is that support equals security—and that operating unsupported equals exposure. But this relationship is more complex than it appears. In most enterprise environments, security is not determined by whether a patch is available. It’s determined by how well the environment is configured, managed, and monitored.

Patches are not applied instantly. Risk assessments, integration testing, and change control processes introduce natural delays. And in many cases, security gaps arise not from missing patches but from misconfigurations: exposed management interfaces, weak credentials, overly permissive access. An unpatched environment, properly maintained and reviewed, can be significantly more secure than a patched one with poor hygiene. Support models that focus on proactive security—through vulnerability analysis, environment-specific impact assessments, and mitigation strategies—offer a different but equally valid form of protection. They don’t rely on patch delivery alone. They consider how a vulnerability behaves in the attack chain, whether it’s exploitable, and what compensating controls are available. 

This kind of tailored risk management is especially important now, as vendor support for older VMware versions diminishes. Many reported vulnerabilities relate to newer product components or bundled services, not the core virtualization stack. The perception of rising security risk needs to be balanced against the stability and maturity of the versions in question. In other words, not all unsupported deployments are created equal.

Uneven risk across environments

Some VMware environments—particularly older versions like vSphere 5.x or 6.x—are already beyond the range of vendor patching. In these cases, the transition to unsupported status may be more symbolic than substantive. The risk profile has not meaningfully changed.  Others, particularly organisations operating vSphere 7 or 8 without an active support contract, face a more complex challenge. Some critical security patches remain accessible, depending on severity and version, but the margin of certainty is shrinking.  

These are the cases where enterprises are increasingly turning to alternative support models to bridge the gap—ensuring continuity, maintaining compliance, and retaining access to skilled technical expertise.

Software support alternative

Third-party support is sometimes seen as a temporary fix—a way to buy time while organizations figure out their long-term plans. And it can serve that purpose well. But increasingly, it’s also being recognized as a strategic choice in its own right: a long-term solution for enterprises that want to maintain operational stability with a reliable support partner while retaining control over their virtualization roadmap.What distinguishes third-party support in this context isn’t just cost control, it’s methodology.  

Risk is assessed holistically, identifying which vulnerabilities truly matter, what can be addressed through configuration, and when escalation is genuinely required. This approach recognises that most enterprises aren’t chasing bleeding-edge features. They want to run stable, well-understood environments that don’t change unpredictably. Third-party support helps them do exactly that, without being forced into a rapid, costly migration or a subscription contract that may not align with their business needs. 

Crucially, it enables organisations to move on their own timeline.

Much of the conversation around unsupported VMware environments focuses on technical risk. But the longer-term threat may be strategic. The end of perpetual licensing, the sharp rise in subscription pricing, and now the legal enforcement of support boundaries all points to a much bigger problem: a loss of control over infrastructure strategy. 

Vendor-imposed timelines, licensing models, and audit policies are increasingly dictating how organizations use the very software they once owned outright. Third-party support doesn’t eliminate risk—nothing can. But it redistributes and controls it. It gives enterprises more agency over when and how they migrate, how they manage updates, and where they invest. In a landscape shaped by vendor agendas, that independence is increasingly critical. 

Broadcom’s cease-and-desist letters represent a new phase in the relationship between software vendors and customers—one defined not by collaboration, but by contractual enforcement. And for VMware customers still clinging to the idea of “owning” their infrastructure, it’s a rude awakening: support is no longer optional, and perpetual is no longer forever. Organizations now face three paths: accept the subscription model, attempt a rapid migration to an alternative platform, or find a support model that gives them the stability to decide their future on their own terms. 

For many, the third option is the only one that balances operational security with strategic flexibility. 

The question now isn’t whether unsupported infrastructure is risky. The question is whether the greater risk is allowing someone else to dictate what happens next.