VMware ESXi Hardening Guide: Securing Hosts and vCenter

An attacker with administrator access to vCenter or root on an ESXi host can stop and encrypt every virtual machine in a cluster, and most ESXi estates still run with default service, logging and authentication settings. ESXi has become a standard ransomware target, vCenter flaws have been exploited by espionage groups, and in 2025 Broadcom confirmed in-the-wild exploitation of a guest-to-host escape chain. This guide turns Broadcom's own Security Configuration and Hardening Guide into a prioritised programme: which settings matter most, how to separate vSphere administration from the corporate directory, how to patch, log and detect, and how to roll changes out safely. It is for vSphere administrators, infrastructure security engineers and incident responders. For the vendor-neutral view of the virtualisation layer, see the Hypervisor and Virtualisation Security Guide.

Key takeaways

• Use the current Broadcom baseline. VMware is now part of Broadcom, and the Security Configuration and Hardening Guide (SCG) is published on GitHub: the vSphere 8 kit was built on 8.0 Update 3, and from 9.0 vSphere guidance is part of the VMware Cloud Foundation SCG. Broadcom says to prefer its guidance where the CIS ESX 8.0 Benchmark conflicts.
• Three settings stop most hands-on-keyboard attacks. Normal lockdown mode, SSH and ESXi Shell stopped with a timeout, and VMkernel.Boot.execInstalledOnly set to true remove the direct-access and custom-binary paths ransomware operators rely on.
• Do not let Active Directory own vSphere. CVE-2024-37085 gave full ESXi admin to anyone who could create an "ESX Admins" group, and help desk social engineering has handed vCenter to Scattered Spider. Use local SSO groups for authorisation and MFA on vCenter.
• Patch vCenter first, then hosts, as emergency changes. VMSA-2025-0004 (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) was exploited in the wild with no workaround, and several vCenter CVEs are in CISA's KEV catalogue.
• Logs must leave the host. Set Syslog.global.logHost, enable Syslog.global.auditRecord.remoteEnable and keep vCenter events flowing to the SIEM, because EDR agents do not run on ESXi itself.

The threat picture for ESXi and vCenter

The ATT&CK techniques most specific to this platform are T1059.012 Hypervisor CLI (abuse of esxcli and vim-cmd) and T1675 ESXi Administration Command (running commands in guests through the VMware Tools service and APIs such as StartProgramInGuest). Impact usually combines T1489 Service Stop, T1490 Inhibit System Recovery and T1486 Data Encrypted for Impact.

Priority ESXi host settings

The SCG assigns each control a priority (P0 is the most important, then P1 and P2). The table lists the controls that address the attacks above, with the parameter, default and the SCG baseline value for vSphere 8.

• Lockdown modes: normal lockdown forces management through vCenter so its roles and audit always apply; strict lockdown also removes DCUI access, so if the host loses contact with vCenter it cannot be managed until the connection returns. Users on the Exception Users list keep their privileges in lockdown and can defeat it, so keep that list empty or minimal. Only users on DCUI.Access (root by default) keep console access in normal mode.
• execInstalledOnly: tells ESXi to run only binaries delivered in a valid, signed VIB, which Broadcom says makes prebuilt attacker toolkits harder to use. With Secure Boot on, the CommunitySupported acceptance level is blocked, so unsigned VIBs cannot be installed even with --force.
• Management VMkernel ports: only VMkernel adapters meant for management should carry management services (esxi-8.vmk-management), otherwise vMotion or storage networks become management paths.

Hardening vCenter Server

vCenter holds the keys to every host: it creates the privileged vpxuser account on each host and rotates its password, by default every 30 days (VirtualCenter.VimPasswordExpirationInDays). Treat it as Tier 0.

• Separate authentication from authorisation (vcenter-8.administration-sso-groups, P0): Broadcom warns that combining both in Active Directory risks infrastructure breaches if AD is compromised, and suggests local SSO groups for authorisation.
• MFA: vCenter supports multifactor sign-in through smart cards, LDAP proxies from identity services, or vSphere Identity Federation.
• Appliance SSH off (vcenter-8.vami-access-ssh): keep VCSA SSH deactivated except where vCenter Server High Availability requires it; Scattered Spider enabled it after resetting root.
• File-based backup (vcenter-8.vami-backup, P0): configure it to a secure location; Broadcom notes the backup contains privileged access information for the cluster, so protect it like a credential store.
• Event logging: keep vpxd.event.syslog.enabled true and forward to the SIEM; local task and event retention defaults to 30 days, which is far too short for investigations.
• Distributed switches: reject promiscuous mode, MAC changes and forged transmits on port groups, restrict port mirroring and NetFlow, and block port-level overrides.
• Authentication Proxy: if hosts join AD, use the vSphere Authentication Proxy so AD credentials are not stored on hosts (esxi-8.ad-auth-proxy).

Where identity fits

Most ESXi compromises are identity attacks. Three machine and admin identities need specific treatment:

• "ESX Admins" and directory groups: on unpatched or AD-joined hosts, Microsoft recommends disabling Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd, changing the ESXi admin group to a different, protected group, and alerting when a group with the configured name is created. Broadcom's workaround is KB369707. See the Active Directory and Entra ID Hardening Guide.
• Integration service accounts: backup, monitoring and automation tools connect with vCenter roles. Give each a custom role scoped to what it needs, never Administrator, vault the secret and alert on interactive logins. See the Service Account Security Guide.
• Root and break-glass: unique root password per host, stored in a vault, rotated after any use. See the Break-Glass Account Guide.

Virtual machine and guest settings

• vMotion encryption: set VM vMotion encryption to required rather than the default opportunistic (vm-8.vmotion-encrypted, P1).
• Host information: keep tools.guestlib.enableHostInfo false so guests cannot learn host details.
• Remove unnecessary devices: floppy, serial, parallel, USB and CD devices are attack surface for escape flaws; also disable console copy and paste and drag-and-drop.
• Guest operations: the VMware Tools guest operations channel underpins T1675; where workloads do not need it, set guestoperations disabled to true (not on templates). Broadcom notes these channels still require guest OS credentials, so keep guest admin accounts out of the infrastructure identity source.
• Tier 0 VMs: encrypt domain controllers, PKI and vault VMs with VM encryption or vTPM, and restrict who can snapshot, clone or reconfigure them.

Patching and lifecycle

1. Stay supported: the SCG's first P0 controls are esxi-8.supported and esxi-8.updates. Broadcom's ESXiArgs answers stress that versions past End of General Support (vSphere 6.x then) no longer receive fixes.
2. Order matters: update vCenter Server first, then ESXi hosts, as the SCG recommends.
3. Classify security patches correctly: Broadcom suggests treating routine updates as standard changes and Important or Critical security fixes as emergency changes, noting that with AD-backed authentication an attacker may already be authenticated.
4. Patch without downtime: use vMotion and vSphere Lifecycle Manager images; an unauthorised VIB makes a host non-compliant with its image, which is itself a detection signal.
5. Subscribe to VMSAs: Broadcom offers an email alert list and states there is no automated RSS feed, so pair it with daily checks of the CISA KEV catalogue. See the Patch Management Guide.

Rolling out the baseline safely

1. Assess: run the SCG kit's PowerCLI audit scripts (the controls spreadsheet includes assessment and remediation examples) against every cluster and record the starting state.
2. Isolate management first: place ESXi, vCenter, NSX Manager and hardware controllers on a dedicated management segment reachable only from privileged access workstations, then restrict the host firewall to those addresses.
3. Pilot: apply P0 controls to one non-production cluster. Confirm backup, monitoring and automation tools still connect after lockdown, because tools that connect directly to hosts will break.
4. Add exceptions deliberately: if a tool must reach hosts directly, prefer its vCenter integration; only then add a named service account to Exception Users, with a ticket and an owner.
5. Roll out by cluster: remediate one cluster at a time using the remediation examples, and re-run the audit to confirm.
6. Roll back: exit lockdown from the vSphere Client, or from the DCUI using an account on DCUI.Access; revert advanced settings to the values recorded in step 1. Test this path before strict lockdown is used anywhere.
7. Keep it enforced: rerun the audit on a schedule and alert on drift.

Choosing between options

Smaller estates (a few standalone hosts, no vCenter) cannot use lockdown in the same way, so the priorities become patch currency, an isolated management VLAN, SSH off, execInstalledOnly, unique vaulted root passwords and remote syslog. Large estates should automate the SCG audit, run a separate infrastructure identity domain and feed vSphere events into detection engineering.

Detection and measurement

Broadcom's BRICKSTORM guidance recommends retaining these logs for two years or more and correlating them with VPN and identity logs. Metrics:

• Percentage of hosts compliant with all P0 SCG controls (target 100%).
• Days from VMSA publication to patched for Critical advisories and KEV-listed vSphere CVEs.
• Hours per month SSH is running across the estate, and number of starts without a ticket.
• Percentage of hosts forwarding audit records, and log retention in days.
• Number of AD accounts with vCenter or host administrator rights.
• Last successful restore test of vCenter and a full cluster from isolated backup.

Common failure patterns

• Directory admins are vSphere admins: in the MGM Resorts breach, an attack that started with a help desk call ended, according to ALPHV's own unconfirmed claim, with ransomware on more than 100 ESXi hypervisors.
• Lockdown enabled with a long exception list: every exception user bypasses vCenter controls, so lockdown becomes cosmetic.
• SSH left running after support work: the default shell timeout is 0, so a service started for a ticket stays open indefinitely.
• Logs only on the host: hosts booting from media without persistent scratch keep about a day of logs, reset on reboot.
• Backups in the same AD: attackers delete jobs, snapshots and repositories before encrypting; see the Backup Security and Immutable Backup Guide.
• vCenter patched on the quarterly cycle: espionage groups have used vCenter CVEs that already had patches available.

Framework mapping

The SCG spreadsheet itself maps each control to DISA STIG and PCI DSS 4.0 requirements. In CIS Controls v8.1 the work sits under Controls 4, 7 and 8; in ISO/IEC 27001:2022 Annex A under 8.9, 8.8 and 8.15. See the CIS Controls Guide.

Practitioner checklist

• Download the SCG for your exact version and run its audit scripts against every cluster.
• Confirm every host and vCenter is on a supported build with all Critical VMSAs and KEV-listed CVEs patched.
• Put ESXi, vCenter and hardware controllers on an isolated management network and restrict the host firewall.
• Enable normal lockdown, empty the Exception Users list, stop SSH and ESXi Shell, set the shell timeout to 600.
• Set execInstalledOnly to true and enable TPM-based Secure Boot enforcement.
• Move vCenter authorisation to local SSO groups, enforce MFA and disable ESX Admins auto-add on AD-joined hosts.
• Forward host logs and audit records over TLS and keep vCenter events in the SIEM for two years or more.
• Require vMotion encryption and encrypt Tier 0 VMs; restrict snapshot and disk attach rights.
• Back up vCenter and VMs to a system outside production AD, with immutable copies, and test the restore.

Standards and references

• Broadcom: VMware Security Configuration and Hardening Guide (vSphere and VCF)
• Broadcom: VMSA-2025-0004, VMware ESXi, Workstation and Fusion updates
• Broadcom: VMSA-2024-0013, VMware ESXi and vCenter Server updates
• Broadcom: BRICKSTORM Resources and Defense
• Broadcom: Protecting vSphere From Specialized Malware
• NIST: SP 800-125A Rev. 1, Security Recommendations for Server-based Hypervisor Platforms
• Microsoft Security: Ransomware operators exploit ESXi hypervisor vulnerability for mass encryption
• SecurityWeek: Scattered Spider targeting VMware vSphere environments

Related NHI Mgmt Group resources: Hypervisor and Virtualisation Security Guide · Ransomware Prevention Guide · Ransomware Response and Recovery Guide · Endpoint Security Guide · Virtual Desktop (VDI) and DaaS Security Guide