VMware HyperArmor Explained: Virtual Patching for ESX

VMware HyperArmor is a paid add-on that Broadcom announced on 13 October 2026 at VMware Explore on Tour in Frankfurt. It runs on the ESX host and does three things: it blocks exploits for known vulnerabilities before you've patched, it only lets known-good executables and scripts run, and it adds MFA to SSH logins. It supports ESX 8.x and later, but you can't buy it yet. Broadcom has published an October 2026 solution brief, but not a price or an install guide.

This post covers what we know so far, what's still missing, how HyperArmor compares with the hardening already built into ESX, and the questions I'd ask before paying for it. I'll write a follow-up once it ships and I can test it in my lab. Until then, the hardening section further down is the part you can act on today.

Last checked 1 November 2026.

Why Broadcom built HyperArmor

The pitch is about the gap between a vulnerability being disclosed and you getting the patch onto every host. Broadcom's Prashanth Shenoy told The Register that customers need "room to breathe" to test patches, especially now that AI tools are finding bugs faster.

The threat is real. In March 2025, VMSA-2025-0004 fixed three ESXi flaws (CVE-2025-22224, CVE-2025-22225 and CVE-2025-22226) that were already being exploited. Together they let an attacker with admin rights in a VM escape to the hypervisor. Huntress later found a toolkit for that chain covering more than 150 ESXi builds, with code that appears to date from February 2024, a year before the fix. In early 2026, CISA confirmed ransomware groups were using CVE-2025-22225.

Broadcom is clear that HyperArmor doesn't replace patching. Eric Chien, a Broadcom Distinguished Engineer, told SiliconANGLE: "We always still want you to patch; that is the right thing to do, but this basically buys you time."

What we know so far

The press release and launch blog describe three components.

Component	What Broadcom says it does	What isn't documented yet
Host-level virtual patching	Detects and blocks exploit attempts on the host, with no reboot or ESX upgrade	How shields are built and delivered, and which CVEs they cover
Positive host security guardrails	Builds a known-good baseline and blocks unauthorised executables, scripts, file writes and configuration changes	How it handles VIB installs and upgrades, and where blocks are logged
MFA for ESX SSH	Adds a time-based one-time password (TOTP) after the normal SSH login, tied to a separately defined identity	How you enrol, which identity sources work, and the break-glass process

Host-level virtual patching

This is the same idea as virtual patching in vDefend, moved from the network to the host. Instead of changing the vulnerable code, HyperArmor intercepts the malicious action while it's running. The press release says it detects and blocks attempted malicious actions on the host before a vulnerability is exploited. It doesn't say how quickly a shield follows a VMSA, or whether every critical ESX advisory gets one.

Positive host security guardrails

An ESX host runs a small, fixed set of processes, so HyperArmor records that set as a baseline. Existing scripts are inventoried and allowed, new ones need an administrator to approve them, and anything else is blocked. It runs on the host itself, so there's nothing to install in your guest VMs.

MFA for ESX SSH

After the usual SSH username and password, you also enter a TOTP code. The aim is to make a stolen root password useless on its own at the command line.

Versions, licensing and availability

Supported versions: ESX 8.x and later. ESXi 7 isn't supported.
Products: the launch blog says it's built for VCF and VVF.
Licensing: a paid add-on, sold through the same channels as VCF. The price hasn't been published.
Availability: no date from Broadcom. TechTarget reports it's expected in Broadcom's fiscal Q1 2027, which runs from November 2026 to January 2027.
Who built it: according to The Register, Broadcom's Symantec and Carbon Black teams.

Broadcom hasn't said whether vSphere Standard 8 or Enterprise Plus 8 customers can buy it.

What we don't know yet

These are the gaps I'd want closed before I trusted HyperArmor in production:

Shield coverage. Broadcom hasn't committed to a virtual patch for every critical ESX VMSA, or said how quickly one would follow. Fernando Montenegro at Futurum flags this as the detail to watch.
VM escapes. The VMSA-2025-0004 chain ran inside the VMX process, which is supposed to be running anyway. Broadcom hasn't said whether HyperArmor would have stopped it.
Management. There's no word yet on where you configure it (vCenter or VCF Operations), how you approve a script, or how alerts get to your SIEM.
Patching and upgrades. Nothing published yet on how the allow-list behaves when you install a VIB or upgrade a host.
SSH MFA recovery. There's no documented break-glass process for getting onto a broken host when the TOTP identity isn't available.
Price. The Register and TechTarget both question charging extra for MFA. I agree. MFA on the host's SSH path feels like something that belongs in the base product.

It also only covers the host. It doesn't protect vCenter, your guest operating systems or your backups.

How VMware HyperArmor compares with native ESX hardening

Some of what HyperArmor does overlaps with controls ESX already has. Most of them are switched off by default.

Control	What it does natively	What HyperArmor adds
SSH and ESX Shell	Disabled by default	MFA when SSH is enabled
Lockdown mode	Forces management through vCenter	Nothing directly. It limits access paths, HyperArmor limits what runs
Secure Boot and execInstalledOnly enforcement	With a TPM, only binaries from installed, signed VIBs can run	Covers scripts, file writes and configuration changes as well as binaries
ESX live patching	Installs some real fixes without a full maintenance window	Blocks the exploit before you've patched
vDefend	Virtual patching and IDS/IPS at the network layer	The same idea at the host layer
vCenter identity federation	MFA for vCenter logins	Nothing. HyperArmor doesn't cover vCenter

Harden your ESX hosts now without HyperArmor

You can close a lot of the same gaps today at no extra cost. Test each change in a lab or on one host first.

Keep SSH and the ESX Shell off

Select the host and go to Configure > System > Services.
Select SSH, then Stop.
Select Edit Startup Policy and choose Start and stop manually.
Repeat for ESXi Shell.

When you do need SSH, set UserVars.ESXiShellTimeOut under Advanced System Settings so the service switches itself off again.

Enable lockdown mode

Select the host and go to Configure > System > Security Profile.
Under Lockdown Mode, select Edit and choose Normal.
Add any service accounts that need direct host access as Exception Users.

Warning: Strict lockdown mode also disables the DCUI. If vCenter is down, you can't get into the host. Use Normal unless you have a tested recovery process.

Enforce Secure Boot and execInstalledOnly

This needs a TPM 2.0 and Secure Boot enabled in the server firmware.

Warning: Once a host is in TPM mode, you can't undo it. If the TPM or motherboard is replaced, the host won't boot without its recovery key. Back up the key first.

Check the current settings:

``bash esxcli system settings encryption get ``

If Mode shows NONE, set it to TPM:

``bash esxcli system settings encryption set --mode=TPM ``

Back up the recovery key and store the output somewhere safe, off the host:

``bash esxcli system settings encryption recovery list ``

Enforce Secure Boot:

``bash esxcli system settings encryption set --require-secure-boot=T ``

Set execInstalledOnly as a boot option, then shut down and restart the host:

``bash esxcli system settings kernel set -s execInstalledOnly -v TRUE ``

After the host is back up, enforce it:

``bash esxcli system settings encryption set --require-exec-installed-only=T ``

Save the configuration:

``bash /bin/backup.sh 0 ``

Confirm that Require Secure Boot and Require Executables Only From Installed VIBs both show true:

``bash esxcli system settings encryption get ``

The same commands are in the ESX 9.1 security documentation. Secure Boot has to be enforced before execInstalledOnly. The old vSphere 8 procedure link now opens the security book index, not the steps.

Stop the ESX Admins group being trusted automatically

CVE-2024-37085 let anyone who could create an AD group called "ESX Admins" get full admin rights on domain-joined hosts. Microsoft saw ransomware operators using it for mass encryption in 2024.

Go to Configure > System > Advanced System Settings and select Edit.
Find Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd.
Make sure it's set to false.

Keep patching

None of this replaces patching. Subscribe to the VMware Security Advisories on the Broadcom support portal (KB 368744 explains where they moved to) and plan for monthly host updates.

Questions to ask Broadcom before you buy HyperArmor

Which ESX CVEs from the last 12 months would it have shielded, and how quickly after each VMSA?
Would it have blocked the VMSA-2025-0004 VM escape chain?
Where do I manage it and where are blocks logged?
How does the allow-list handle VIB installs, upgrades and vendor tools?
How does the SSH MFA break-glass process work?
What does it cost per core, and is SSH MFA available on its own?
Can vSphere Standard 8, Enterprise Plus 8 and VVF customers buy it?

If you're planning to leave VMware in the next 12 to 18 months, I'd spend the money on the migration and use the native controls above.

What's next

When HyperArmor is released I'll test it in my lab: install it on an ESX 9.1 host, set up the SSH MFA, try running an unapproved script, and see what gets logged. If there's anything specific you'd like me to check, let me know.

Resources

Feedback

If you found this guide useful, subscribe to the mailing list or follow me on X and YouTube. You can contact me through any of these with issues or suggestions for this guide.

Questions? Email me (contact@virtualg.uk) or DM me on X (@virtualg_uk).

EOF · Published 2026-11-01