What’s New Is Old Again: VMware Tools, Virtual Hardware, and the Hidden Cost of Standing Still

Your ESXi hosts are current. Your servers have been refreshed. Your workloads have been migrated. So why are some virtual machines still carrying hardware compatibility from another era?

A new release, and a familiar discovery

Today’s announcement of VMware Tools 13.1.6.0 reminded me of a story I’ve told before. In my April 2025 Architect’s Edge newsletter, I described finding a production VM with a version of VMware Tools more than a decade old. Not a forgotten lab workload: production. It wasn’t necessarily causing problems, but it was a good reminder that virtualization is remarkably effective at keeping workloads alive long after their original configurations have stopped receiving attention.

That came to mind again during a very recent look at another production environment. Roughly 90% of the VMs were running virtual hardware version 21, introduced with vSphere 8.0 Update 2. Nice! Clearly a great deal of modernization had taken place. But the remaining 10% told a different story: scattered across the same environment were hardware versions 4, 7, 8, 9, 14, and 17. That’s everything from the ESX 3.x and 4.x generations through ESXi 5.x, 6.7, and 7.0, all coexisting with version 21 in production. Broadcom KB 315655 documents the version history.

Does an old hardware version automatically mean a broken, vulnerable, or slow VM? Of course not. But when most of an environment has moved forward and a minority still reflects several generations of virtualization history, it’s worth asking whether those configurations were deliberately retained—or simply never revisited.

VMware Tools can move forward. Virtual hardware often doesn’t.

One reason these gaps appear is that VMware Tools and virtual hardware have very different maintenance habits. VMware has supported automatic Tools upgrades during power-cycle workflows since at least the VMware Infrastructure 3.5 / VI API 2.5 era. When the upgradeAtPowerCycle policy is enabled, an eligible VM can receive a newer Tools package from the configured host repository as part of that workflow. It’s a useful way to fold guest integration updates into existing maintenance, and VMware has long documented the options in Six Methods for Keeping VM Tools Up to Date.

Of course, can doesn’t mean will. The policy must be enabled, the installed Tools and guest OS must support the upgrade path, and an appropriate package must be available. A VM may be current relative to its ESXi host’s repository without running the newest standalone Tools release; sufficiently old installations may need manual attention. On many Linux guests, open-vm-tools is updated through the distribution’s package manager instead. And for critical workloads, administrators may deliberately control update timing because a Tools upgrade can require an additional restart.

Virtual hardware is different. Upgrading ESXi, replacing a server, or moving a VM with vMotion doesn’t automatically upgrade that VM’s hardware compatibility. Doing so normally requires a powered-off VM and an intentional change. You can schedule the compatibility upgrade for a future power cycle or orchestrate it with PowerCLI, but somebody still needs to inventory the versions, check guest and host compatibility, and arrange the shutdown. We’ve recently shared scripting approaches to make that work less painful; the application owner’s reluctance to approve downtime, however, isn’t something a script can solve.

And that’s how an otherwise healthy VM can carry its original hardware compatibility through years of infrastructure refreshes. It isn’t always a maintenance failure; sometimes an older level is required. The point is to know which situation you’re looking at.

Why the version matters: security, capability, and performance

Security: VMware Tools is software, and software needs maintenance

VMware Tools is more than a convenience package: it provides guest integration services, drivers, and management capabilities, all of which have a security lifecycle. For example, CVE-2025-41244, addressed in VMSA-2025-0015, could allow privilege escalation to root under specific conditions involving VMware Aria Operations with the Service Discovery Management Pack (SDMP) enabled. Broadcom reported suspected exploitation in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog on October 30, 2025—exactly one year before the announcement that inspired this article. CVE-2025-22247, addressed in VMSA-2025-0007, concerned insecure file handling in VMware Tools.

Those vulnerabilities have different affected versions and exploitation prerequisites; neither makes every old Tools installation vulnerable. Likewise, a Linux guest running distribution-maintained open-vm-tools may already have backported security fixes despite an older-looking version number. The lesson isn’t to panic over a version string, but to track the applicable advisories and ensure the software is actually maintained.

Hardware compatibility: what’s the guest actually able to use?

New physical processors bring newer instructions and security features, but the guest’s view depends on ESXi, the EVC baseline, virtual hardware compatibility, and guest OS support—not just the CPU under the hood. Broadcom KB 315655 specifically notes that virtual hardware upgrades can be necessary to expose CPU flags used by certain guest security mitigations. Virtual devices also matter: keeping an older emulated adapter doesn’t magically provide the capabilities of a newer paravirtualized device.

Does a hardware compatibility upgrade automatically make everything faster? No, and Broadcom advises against upgrading merely to have the highest version number. But old settings can impose real feature limitations. The useful question is which security, compatibility, or performance capability a workload actually needs—and which part of its configuration is preventing it from using that capability.

Secure Boot makes those dependencies very real

This brings us back to VMware Tools 13.1.6.0. Microsoft’s transition from its older 2011 Secure Boot certificates to the 2023 certificate infrastructure is a particularly useful illustration of why guest software and virtual hardware need to be considered together. Certificate expiration doesn’t mean every affected VM suddenly stops booting, but administrators need a supported path for updating certificates, revocations, and the Secure Boot chain of trust.

Here’s the wrinkle: virtual hardware version 13 introduced VM Secure Boot support, but Broadcom’s documented Platform Key (PK) update methods require version 14 or newer. A VM can therefore support Secure Boot yet be too old for the current remediation methods. Even hardware version 14 isn’t sufficient on its own—the ESXi release, guest OS, Windows updates, VMware Tools version, Secure Boot configuration, and virtual TPM (vTPM) state all matter. Broadcom’s KB 423893 explains the supported combinations.

VMware Tools 13.1.5 introduced the Capsule PK update driver for selected Windows guests. The newly announced 13.1.6.0 release identifies expanded support for Windows Server 2016 and Windows 10 64-bit versions 22H2 and 1809. Documentation timing matters: as of October 30, 2026, KB 423893 still describes those guest versions as awaiting a future Tools release, so verify the current guest-support and prerequisite matrix before deploying the remediation. The Capsule mechanism coordinates the key update with Windows, which matters especially where vTPM and BitLocker are involved; changing measured-boot state improperly can trigger recovery. The applicable Windows cumulative updates and installation sequence also vary by guest, so installing Tools alone is not the whole remediation plan.

What matters is the combination: virtual hardware provides required firmware capabilities, the ESX release supplies supported remediation, Tools provides the driver where applicable, and the guest OS must participate correctly. Follow KB 423893, KB 423919, and Microsoft’s certificate guidance—particularly for VMs with vTPM or BitLocker. I also covered the vSphere-side enhancements in my recent Architect’s Edge look at VCF 9.1.1 and EP1.

One old component often leads you to another

Finding unexpectedly old Tools or virtual hardware doesn’t prove the whole environment is neglected, but it’s a good reason to look a little further. Consider vSAN on-disk format: Broadcom KB 406680 describes database VM latency following a VCF 4.5-to-5.2 upgrade where the on-disk format hadn’t been brought forward. The infrastructure software had moved on; the storage format hadn’t. Or take the vSphere Distributed Switch, whose own versions introduce new networking features and compatibility requirements, described in KB 416520 and the upgrade guidance in KB 407905.

Neither is an invitation to upgrade every vSAN format or distributed switch indiscriminately. Both deserve their own compatibility checks and, frankly, their own articles. They simply illustrate the same principle: platform upgrades don’t automatically modernize every configuration carried forward within the platform.

Start with visibility, not a mass upgrade

If there’s one action I’d recommend, it’s to inventory what you’re actually running before deciding what needs to change. Establish the supported lifecycle of your VMware Tools installations, check the virtual hardware compatibility across workloads, and record intentional exceptions rather than treating every older number as a defect. For Secure Boot, guest firmware and vTPM settings are only part of the picture; use the documented procedure to establish whether the certificate and PK state actually requires remediation.

• VMware Tools: Version, running status, upgrade policy, repository or package source, and relevant advisories.
• Virtual hardware: Compatibility level, guest OS support, host interoperability, EVC, and required virtual device capabilities.
• Secure Boot: UEFI and Secure Boot configuration, hardware version, vTPM/BitLocker dependencies, PK state, and applicable host and guest patches.
• Beyond the VM: vSAN on-disk format, vDS version, and other compatibility settings that may have outlived previous upgrades.

PowerCLI can help inventory and coordinate changes, but the first job is to know what you’ve inherited. For a complementary look at the physical side of modernization, see my VCF Readiness Tool overview. There’s a tremendous difference between intentionally maintaining an older configuration and discovering nobody has reviewed it in twelve years. In that recent environment, the 90% running version 21 was a good modernization story. The other 10% was a reminder that an average—or a majority—doesn’t tell you everything.

What’s new is old again

One of virtualization’s greatest strengths is that workloads survive server refreshes, hypervisor upgrades, and migrations with remarkably little disruption. That’s exactly what we want. But the same capability can let a VM keep its original integration components or hardware compatibility long after the surrounding infrastructure has changed.

That’s what the VMware Tools 13.1.6.0 announcement brought back to mind, just as VMware Tools 12.5.1 did in April 2025. Keep your Tools maintained, understand your virtual hardware, and pay attention to dependencies between guest operating systems, security features, and the platform underneath them. When you discover something unexpectedly old, look a little deeper—because some of the most interesting technical debt in a modern data center is still running quite happily inside the VMs you migrated years ago.

---

References and further reading

VMware Tools and virtual hardware

• VMware Tools 13.1.6.0 Release Notes
• Six Methods for Keeping VM Tools Up to Date
• KB 315655 — Virtual Machine Hardware Versions

Security and Secure Boot

• VMSA-2025-0015 — VMware Tools and Aria Operations
• VMSA-2025-0007 — VMware Tools
• KB 423893 — Secure Boot Certificate Expirations
• KB 423919 — Manual Secure Boot Variable Updates
• Microsoft Secure Boot Certificate Update Guidance

Infrastructure lifecycle

• KB 406680 — vSAN On-Disk Format and Database Latency
• KB 416520 — vDS Features by Version
• KB 407905 — vDS Upgrade Best Practices

Related Architect’s Edge articles

• April 2025 — What’s New Is Old Again
• October 2026 — VCF 9.1.1 and EP1

Architect’s Edge | Enterprise architecture, VMware Cloud Foundation, security, and the occasionally surprising things hiding inside production infrastructure.