VMware vSphere 7 End of General Support: Upgrade Planning Under Broadcom Licensing

VMware vSphere 7 reached End of General Support on 2 October 2025, so ESXi 7 hosts and vCenter Server 7 appliances no longer receive security patches from Broadcom under standard support. Hypervisors are a favourite ransomware target because one compromised host or vCenter can encrypt hundreds of virtual machines at once. Planning is harder than a normal upgrade: vSphere 8 itself reaches End of General Support on 11 October 2027, older servers and boot devices may not qualify, and Broadcom's move to subscription licensing changes what you buy. This guide is for virtualisation engineers, infrastructure leads and security teams. It covers the official dates, how to find affected hosts and the identities that manage them, the upgrade and exit options, testing and rollback, and interim hardening while you move. Configuration hardening itself is in the VMware ESXi Hardening Guide.

This is an independent guide from NHI Mgmt Group, based on Broadcom's public documentation as of November 2026. It is not sponsored or reviewed by Broadcom. Product features change, so confirm settings against Broadcom's current documentation.

Key takeaways

• General support ended on 2 October 2025. Broadcom extended vSphere 7 general support by six months from 2 April 2025; after 2 October 2025 product support, security patches and updates stopped.
• vSphere 8 is a short stop. ESXi 8, vCenter Server 8 and vSAN 8 reach End of General Support on 11 October 2027, and Broadcom recommends VMware Cloud Foundation 9 or vSphere Foundation 9 as the target.
• Hardware decides the path. Check every host's CPU, I/O devices and boot media against the Broadcom Compatibility Guide before choosing between an in-place upgrade, new hardware or another platform.
• Licensing is now subscription only. Broadcom no longer sells perpetual licences or renews support for them, so upgrade and exit decisions are also budget decisions.
• The management plane is an identity problem. vCenter SSO, Active Directory joins, local root accounts and automation service accounts must be inventoried and hardened, because an exploited unpatched host gives attackers every VM on it.

What is changing and why

VMware products follow a lifecycle with a General Support phase (maintenance updates, security patches and technical support) followed, for some contracts, by a Technical Guidance phase (self-help and limited guidance, without new patches). vSphere 7, which covers ESXi 7.x, vCenter Server 7.x and vSAN 7.x, became generally available on 2 April 2020. Its General Support was due to end on 2 April 2025; in July 2024 Broadcom announced a six-month extension to 2 October 2025, citing customer flexibility in planning upgrades.

The extension came with caveats that Broadcom published in August 2024: fixes for critical open source vulnerabilities depended on upstream patches being available and were not guaranteed; Kubernetes support on vCenter 7.x stopped at version 1.28; and the embedded Harbor registry was not covered. In other words, even before the end date, vSphere 7 was already receiving a narrower set of fixes than vSphere 8.

At the same time Broadcom changed how VMware is sold. Its business transformation announcement ended sales of perpetual licences and renewals of support for them, moved all offerings to subscription or term licences, and positioned VMware Cloud Foundation as the flagship offering and VMware vSphere Foundation for mid-sized and smaller customers. Existing perpetual licences can still be used under their existing contracts. Many organisations therefore face the end of vSphere 7 alongside a licensing renewal, which is why some are evaluating other platforms. That route is covered in the Migrating Off VMware guide.

Official timeline and current status

All dates below are from Broadcom and VMware announcement pages and knowledge base articles listed in Standards and references, checked on 8 November 2026. Lifecycle dates can change, so confirm with Broadcom before committing a plan.

After 2 October 2025, Broadcom's reminder notice states that support cases are no longer accepted for vSphere 7, and that patches and fixes published before that date remain available through self-service for the rest of the maintenance period under Broadcom's Software Maintenance policy. For extended support availability it directs customers to their Broadcom representative, reseller or Broadcom Support.

Who and what is affected

• ESXi 7 hosts and vCenter Server 7 appliances: every build of 7.0, including those patched to the last 7.0 Update 3 release.
• vSAN 7 clusters: storage services run inside ESXi, so they follow the same dates.
• vSphere with Tanzu on vCenter 7: Kubernetes support stopped at 1.28 and the embedded Harbor registry was excluded from the extension.
• Dependent tools: backup, replication, monitoring and automation products have their own compatibility matrices, and some will drop vSphere 7 support.
• Identities that manage the platform: vCenter Single Sign-On users and groups, Active Directory or LDAP identity sources, ESXi local root and service accounts, API tokens and service accounts used by backup and automation tools. These keep their access on an unpatched platform.

Finding affected systems and identities

1. Build the host and appliance list from vCenter: export every host's ESXi version and build, hardware model, CPU model, network and storage adapters with driver names, and boot device type. Include standalone hosts that are not in any vCenter, which are often forgotten in branch sites.
2. Cross-check with the CMDB and scanners: authenticated vulnerability scans and the CMDB catch hosts outside vCenter and appliances embedded in vendor products. See the Asset Inventory and CMDB Security Guide.
3. List licence entitlements: record which hosts run on perpetual licences, which on subscription, and contract end dates, because this determines what you are entitled to upgrade to.
4. Inventory management identities: list vCenter SSO identity sources, global permissions and roles; ESXi hosts joined to Active Directory and the AD group that grants admin rights; local accounts on each host; and every service account or API credential used by backup, monitoring and orchestration. The VMware vCenter Server Hardening Guide covers the settings to review.
5. Map exposure: record which management interfaces (vCenter web client and API, ESXi host client, SSH, SLP) are reachable from which networks. Anything reachable from user networks or the internet is the first priority.

Migration options

Decision guidance: small estates on compatible hardware usually upgrade to the current release they are entitled to and plan the next step on a normal cycle. Large estates should decide the three-year platform strategy first (VMware 9, mixed, or exit), then choose the upgrade that fits it, because a rushed vSphere 8 upgrade can mean repeating the work before October 2027. Whatever the choice, internet-facing or user-reachable vCenter and ESXi management interfaces must be isolated now.

Hardware compatibility checks

A phased upgrade

1. Contain: restrict management interfaces to a dedicated management network reachable only from privileged access workstations or a jump host, and disable SSH and unused services on hosts.
2. Decide the target per cluster from the options table, with the licence position confirmed.
3. Upgrade vCenter first, because vCenter must be at the same or a later version than the hosts it manages, then upgrade hosts cluster by cluster.
4. Use lifecycle images (vSphere Lifecycle Manager) so that every host in a cluster runs the same validated image and drivers.
5. Upgrade vSAN on-disk format and tools last, after all hosts in the cluster are on the new release and stable.
6. Re-harden and re-baseline each cluster against the hardening guide and record the new configuration.

Testing and rollback

• Back up vCenter before upgrading: take a file-based backup of the vCenter appliance and confirm it restores in an isolated network.
• Pilot one cluster: upgrade a non-production or low-risk cluster first and run backup jobs, replication, monitoring and automation against it for at least one full cycle.
• Check dependent products: confirm every integrated product's compatibility with the target release before the pilot, not after.
• Keep a host rollback path: ESXi keeps the previous image on an alternate boot bank, which can be used to revert a host, but this is not a substitute for tested backups and does not apply once on-disk formats or vCenter have moved on. Do not upgrade vSAN on-disk format until you no longer need to roll back.
• Verify identity paths: after each step, test vCenter SSO logins, AD-based host access and every service account used by tooling, then remove any temporary accounts created for the upgrade.

Risks of doing nothing

• Security fixes stop arriving: after the end of general support, new ESXi and vCenter security fixes are published for supported versions, so vSphere 7 hosts depend on compensating controls until they are upgraded. Track the Broadcom security advisories (VMSAs).
• Mass encryption: attackers who reach ESXi can encrypt every VM's disks from the hypervisor, bypassing endpoint tools in the guests. The ESXi Ransomware Playbook describes the response.
• Directory-linked compromise: AD-joined hosts trust directory groups, so anyone with enough AD permissions to recreate the configured admin group could gain host access. Review which AD groups grant host administration.
• Support dead ends: no new support cases for vSphere 7, and backup and monitoring vendors drop compatibility over time.
• Compliance findings: NIST SP 800-53 SA-22 and CSF 2.0 PR.PS-02 expect unsupported components to be replaced or covered by a documented exception.

Detection, metrics and framework mapping

While vSphere 7 remains, forward ESXi and vCenter logs to the SIEM and alert on new local accounts, permission changes, SSH enablement, changes to the AD admin group, and mass VM power-off or snapshot deletion. The ESXi Logs Detection Guide lists the log sources and events.

• Number of ESXi 7 hosts and vCenter 7 appliances remaining (trend to zero).
• Percentage of management interfaces reachable only from the management network (target 100%).
• Number of hosts with SSH enabled outside a change window (target zero).
• Percentage of management service accounts with a named owner and rotated credentials.
• Hosts blocked by hardware compatibility, with a funded replacement date.

Practitioner checklist

• Export every ESXi and vCenter version, hardware model, CPU, adapter driver and boot device, including standalone hosts.
• Restrict vCenter and ESXi management interfaces to a dedicated management network now.
• Inventory vCenter SSO sources, AD groups granting host admin, local accounts and tool service accounts, and remove what is unused.
• Confirm licence entitlement and contract dates before choosing an upgrade target.
• Check CPUs, I/O devices and boot media against the Broadcom Compatibility Guide for the target release and the one after it.
• Decide between vSphere 8, VCF or VVF 9, hardware refresh or exit, with the 11 October 2027 vSphere 8 date in mind.
• Back up vCenter, pilot one cluster, and test backup, monitoring and identity paths before wider rollout.
• Track Broadcom security advisories for ESXi and vCenter and apply compensating controls to any remaining vSphere 7 hosts.

Standards and references

• VMware by Broadcom: Announcing extension of vSphere 7.x and vSAN 7.x general support period
• VMware by Broadcom: Reminder, vSphere 7 to reach end of service October 2, 2025
• Broadcom: End of General Support for vSphere 7.0
• Broadcom: Upcoming End of Service for vSphere 8, vSAN 8, Aria 8, NSX 4 and VCF 5
• Broadcom: Devices deprecated and unsupported in ESXi 8.0
• Broadcom: SD card/USB boot device revised guidance
• Broadcom: VMware by Broadcom business transformation

Related NHI Mgmt Group resources: VMware ESXi Hardening Guide · VMware vCenter Server Hardening Guide · Migrating Off VMware · ESXi Ransomware Playbook · Hypervisor and Virtualisation Security Guide