For most of my career, “ESXi security” meant strong passwords and not exposing the management interface to the internet. That’s no longer enough. Over the last year, ransomware crews stopped breaking into guests one at a time and started going straight for the hypervisor — because owning one host means owning every VM on it. This is the hardening baseline I now consider non-negotiable, with the exact commands to get there.
The shift in attacker behavior is the reason the alternative-platform conversation at my own job has cooled and the security conversation has heated up. Threat-hunting teams have reported hypervisor ransomware’s share of malicious encryption cases jumping from a small fraction in early 2025 to roughly a quarter by late 2025, with the Akira group driving much of it. The hypervisor is the ultimate land-and-expand target: it’s a proprietary, restricted OS where you usually can’t install an EDR agent, so it’s a blind spot by design. Attackers have even used the host’s own openssl to encrypt VM volumes — no custom malware to detect.
You can’t put an agent on ESXi, so you harden the platform itself. Three controls do most of the heavy lifting, and they build on each other in a specific order.
The chain: TPM → Secure Boot → execInstalledOnly
These three aren’t independent checkboxes — they’re a dependency chain, and that order matters. TPM 2.0 gives you a hardware root of trust. UEFI Secure Boot uses it to guarantee only signed bootloaders and kernels run. And execInstalledOnly builds on Secure Boot to guarantee the running VMkernel only executes binaries that shipped, signed, inside a VIB. Miss a link and the chain doesn’t hold.
Step 1: TPM 2.0 and configuration encryption
Get TPM 2.0 enabled in firmware on every host. Modern server hardware almost always has it; it just needs turning on in BIOS/UEFI. Once it’s active, vCenter starts reporting attestation automatically under Cluster → Monitor → Security. Green is full trust; red is attestation failure and means something in the boot chain changed.
Verify TPM presence and version across the fleet with PowerCLI:
foreach ($h in Get-VMHost) {
$v = (Get-View $h).Capability
[pscustomobject]@{
Host = $h.Name
TpmPresent = $v.TpmSupported
TpmVersion = $v.TpmVersion
}
}With a TPM present, confirm the host is set to use it for configuration encryption. In vSphere 7.0 U2 and later the archived host configuration is encrypted, and the TPM “seals” that configuration to the host — a strong defense against offline tampering. Check the mode over ESXCLI / SSH:
esxcli system settings encryption get
# Mode: TPM
# Require Executables Only From Installed VIBs: false
# Require Secure Boot: trueIf Mode shows NONE, the TPM isn’t set as the encryption mode yet. Enable it in firmware first, then:
esxcli system settings encryption set --mode=TPMImportantBefore you go further, back up the secure-configuration recovery key and store it somewhere offline and safe. If you clear the TPM, the TPM fails, or you swap the motherboard or TPM device, you need that key to recover the host’s secure configuration — or you’re rebuilding the host. List it and save the output:
esxcli system settings encryption recovery listStep 2: UEFI Secure Boot enforcement
Secure Boot verifies the digital signatures of bootable code during startup, so unsigned or tampered bootloaders and kernels never execute. It’s also a hard prerequisite for the next step. The TPM-based enforcement on ESXi goes beyond plain Secure Boot — it uses the TPM to measure and verify the entire boot chain from firmware up to the kernel, creating that hardware-backed root of trust and enabling remote attestation. This flips ESXi from merely supporting Secure Boot to requiring it.
Enable Secure Boot enforcement before attempting execInstalledOnly — the latter is built on top of it and will refuse to enable otherwise.
Step 3: execInstalledOnly — the anti-ransomware control
This is the relatively unknown setting that directly counters the “run encryption from the hypervisor” technique. When execInstalledOnly is TRUE, the VMkernel will only run binaries that were packaged and signed as part of a VIB from VMware or a certified partner. An attacker who lands on the host can’t drop and execute a custom ransomware binary, because it isn’t signed into a VIB. Combined with Secure Boot and the TPM tamper-proofing the existing VIBs, this is a genuinely strong layered defense — and it’s far easier to enforce on ESXi than on a general-purpose OS, precisely because ESXi is an appliance that has no legitimate need to run arbitrary code.
Because it’s enforced through the TPM, you set it via ESXCLI. Secure Boot enforcement must already be on:
# Check current state
esxcli system settings kernel list -o execInstalledOnly
# Enable it
esxcli system settings kernel set -s execInstalledOnly -v TRUEThen verify the enforcement reflects in the encryption status — Require Executables Only From Installed VIBs should flip to true:
esxcli system settings encryption get
# Require Executables Only From Installed VIBs: true
# Require Secure Boot: trueTest firstIf you’ve ever changed a host’s acceptance level to install a CommunitySupported VIB — a community NIC driver, say — execInstalledOnly will block it from running. Audit your VIB acceptance levels before flipping this in production, and confirm every third-party agent you depend on ships as a properly signed VIB. Roll it out to a non-critical host, reboot, validate, then expand.
Lockdown mode: force everything through vCenter
Lockdown mode deactivates direct access to the host and requires management through vCenter, so the roles and permissions you defined centrally can’t be bypassed by someone logging straight into the host. There are three settings: Disabled, Normal, and Strict.
- Normal — direct access is restricted but the DCUI stays available, so if vCenter connectivity is lost a privileged user at the console can still recover. This suffices for most deployments.
- Strict — the DCUI is stopped too. If the host loses contact with vCenter and you have no Exception Users defined, you cannot manage it until the connection is restored — and if it can’t be restored, you rebuild the host. Strict exceeds the needs of most environments.
My default is Normal lockdown across the cluster, with a deliberately maintained Exception Users list for break-glass access. Note that lockdown mode is a vCenter-managed control, so it doesn’t apply to truly standalone hosts.
# Set Normal lockdown across the cluster
Get-VMHost | Foreach-Object {
$_ | Get-View | ForEach-Object {
$_.EnterLockdownMode() # or set via (Get-VMHost).ExtensionData
}
}And define the Exception Users carefully — this is the DCUI.Access list that determines who can reach the console when lockdown is active. You can’t remove root from it; audit everyone else.
The settings that round out the baseline
Beyond the big three plus lockdown, these are the ones I set on every host:
| Control | Setting | Why |
|---|---|---|
| Account lockout | Security.AccountLockFailures = 5 | Resists brute-force against local accounts (CIS baseline). |
| ESXi Shell / SSH | Disabled by default; enable only for troubleshooting | Smaller attack surface. Remember: even under lockdown, an enabled shell is still reachable. |
| SLP service (port 427) | Disabled | Exploited by ESXiArgs-class ransomware. Turn it off if you don’t need it. |
| MOB (Managed Object Browser) | Config.HostAgent.plugins.solo.enableMob = false | Removes a needless information-disclosure/manipulation vector. |
| Central logging | Remote syslog to a tamper-resistant collector | You can’t put EDR on ESXi, so off-host logs are your forensic record. |
Set the account lockout fleet-wide with PowerCLI:
Get-VMHost | Get-AdvancedSetting -Name Security.AccountLockFailures |
Set-AdvancedSetting -Value 5 -Confirm:$falseDon’t join ESXi and vCenter to Active Directory
This one runs against years of “integrate everything with AD” habit, and I hold it firmly. Keep ESXi and the vCenter Server Appliance out of your AD domain. The reasoning is blast radius: if AD is compromised — and in a lot of intrusions AD is the thing that gets compromised — domain-joined hosts hand the attacker your entire virtual estate through the same credentials. Use local ESXi accounts for host access and reserve general-purpose domain admin accounts for nothing on the hypervisor. Threat hunters specifically call out AD-joined ESXi as a lateral-movement amplifier.
Defense in depthNone of these controls is sufficient alone. The point is layers: TPM-anchored Secure Boot stops boot tampering, execInstalledOnly stops custom-code execution, lockdown stops permission bypass, AD separation contains credential blast radius, and immutable backups are the last line when everything else fails. Adopt the 3-2-1 rule and keep at least one copy off the hypervisor network entirely.
Patch discipline, stated plainly
I’ve written whole posts on upgrade pain, so I’ll be brief: keep vCenter, ESXi, and VMware Tools current, prioritize anything tagged as a hypervisor CVE, and always patch vCenter before the hosts. Staged rollouts, read the release notes, test on a non-critical host. The ransomware crews are explicitly hunting unpatched, internet-reachable management interfaces — don’t be the easy target.
This baseline isn’t exotic. Every control here is documented and supported. The reason I’m writing it down now is that the threat model changed faster than most runbooks did, and “we use strong passwords” stopped being an answer. In the next post I’ll go up a layer — isolating the management plane itself with bastions and network segmentation, so an attacker who’s already inside the network still can’t reach vCenter or the host management interfaces in the first place.