Eric Chen is a Broadcom distinguished engineer and one of the people who built the thing. This is how he described his own virtual patching: "we always still want you to patch; that is the right thing to do, but this basically buys you time". He is right on both halves, and it is worth something that he is the one saying it. The question left open is what you are going to spend that time on. Because if you did not patch in time, it was not for lack of knowing there was a patch.
What it is, in the vendor's own words
The release is dated today, 13 October 2026, with a Palo Alto dateline; the same day, VMware is telling the story at VMware Explore on Tour Frankfurt, running today and tomorrow. VMware HyperArmor protects the ESX component of VMware Cloud Foundation, supports ESX 8.x and later, is sold as a separate add-on to VCF, and has no published price. Three pieces, with the names the vendor gives them:
- 1"Virtual patching for VCF's ESX Component Host Environment". It detects and blocks the exploitation attempt without touching the vulnerable software: no host reboot, no upgrade. The binary is still yesterday's binary.
- 2"Positive Host Security Guardrails". An execution allowlist: "unauthorized executables and scripts are blocked by default". So that nothing breaks on day one, it inventories the scripts already on the host and takes them as good; new ones you approve yourself.
- 3"Hypervisor-level multi-factor authentication". It adds a second factor to ESX's SSH: credentials and then a time-based code "tied to a separate identity". A stolen root password does not get you to the command line.
Paul Turner, chief product officer of the VMware Cloud Foundation division, sums it up: "VMware HyperArmor takes a different approach by allowing only what is 'known good' to run on the host". The headline claim is that all of it arrives "with no downtime, software upgrades, or in-guest agents". Those are precisely the three things that turn a hypervisor update into a project.
Why now: somebody else sets the pace
The context came from Prashanth Shenoy, of Broadcom, speaking in Frankfurt: VMware recently moved to monthly software updates, in part to address bugs found by AI. And Shenoy concedes that even before that change customers "struggled to keep up with the pace of change", because testing the impact of a patch takes time. His way of putting it is that people need "room to breathe". That is what went on sale today.
The release closes the argument with Stephen Elliot of IDC: "attackers are using automation and AI to exploit infrastructure weaknesses faster than most organizations can patch". It is the same arithmetic we ran in AI already finds zero-days on its own: the bottleneck is the days between the patch existing and the patch reaching your production. What is new today is that the acceleration no longer shows up only in the attacker's calendar. It shows up in the vendor's calendar, and that one you do have to keep up with.
You already had a way not to reboot. It comes with an exclusion list
Since vSphere 8.0 Update 3 there has been Live Patch, and its documentation promises exactly what the new product's headline promises. During remediation, Broadcom writes, "vSphere Lifecycle Manager does not place the hosts in the cluster into maintenance mode", hosts are not rebooted and "there is no need to migrate the virtual machines running on the hosts in the cluster". Free, inside what you already pay for.
The small print runs longer. Live Patch requires the cluster to be managed by a single vSphere Lifecycle Manager image — it does not work with baselines, and the conversion is one-way: once converted you cannot go back — it requires DRS enabled, and it forces you to patch sequentially, host by host. There are two more lines: "Live Patch is incompatible with systems configured with TPM devices or systems using DPUs via vSphere Distributed Services Engine", with the note that TPM compatibility begins with vSphere 9.1.
The free route to not rebooting excludes hosts configured with TPM devices. It is the same file we wrote about in VCF hardening: the P0 shuts the door and the P2 leaves you the key — the controls do not contradict each other on paper, they contradict each other on the specific host you actually have racked. There is a way out — vSphere 9.1 lifts the restriction — but the way out is another upgrade, which is exactly the work you were trying to postpone.
There is a third exclusion, this one on the virtual machine side: those that cannot do Fast Suspend and Resume — Fault Tolerance, DirectPath I/O passthrough, vSphere pods, shared-disk clustering — have to be migrated or power-cycled anyway. And in that same knowledge base article: "remediation is blocked if you attempt a live patch on hosts that require maintenance mode". The live patch does not warn you that the host falls outside its scope: it blocks the whole remediation.
Of the three pieces, one you already have for free. And it is switched off
This is the order we find useful: start with what you already have, end with what genuinely has to be bought.
- →The SSH second factor. On ESXi 8, SSH ships deactivated by default. If it is off and nobody turns it on, there is no login to protect. The nuance matters: lockdown mode does not close that door, and Broadcom's documentation says so in one line — "if the ESXi Shell or SSH is activated and the host is placed in lockdown mode, accounts on the Exception Users list who have administrator privileges can use these services". So the useful question is who is on the exception list, and why. If there is an account on it that you opened for a support case eighteen months ago, the vendor's MFA plugs a real hole.
- →The execution allowlist. ESXi already ships one, stricter and free:
execInstalledOnly, which makes it so that "the VMkernel executes only those binaries that have been packaged and signed as part of a VIB". The snags are written on the same page: it requires UEFI secure boot underneath, it ships set to false, and turning it on requires a host restart. Which is to say: the free version of "only known code runs" costs exactly what the paid product promises to save you. - →The virtual patching. This one you cannot build, and it is only honest to say so. It takes knowing which sequence of calls exploits which flaw in which hypervisor version, and the people who know that are the people who write the hypervisor. And that is the vendor's own argument: Broadcom knows which processes should run on its hypervisor, which is why it can enforce the restriction inside the host rather than only by inspecting the network. It is the product's strongest argument, and it has no home-made equivalent.
One detail of piece two deserves to be looked at head on, because it is the difference between an allowlist and a photograph. HyperArmor's baseline is built by inventorying the scripts already running and allowing them. That is the right call if the product is to be switched on a Tuesday without breaking half the platform. But Turner's "known good" assumes the host was good on the day the photo was taken. If something was already inside, the baseline blesses it, and it becomes authorised in writing.
What we are not going to tell you
- ✗That this is snake oil. It is not. It is a real mitigation, described precisely by the person who built it, and it covers two routes in that genuinely exist: the stolen root credential and the unpatched flaw. Having the product's headline sentence be its own engineer saying "it buys you time" is more honest than the sector average.
- ✗That you should leave VMware over this. And we say it with the conflict of interest up front: we do VMware-to-Proxmox migrations, and we are resellers of neither Proxmox nor VMware — we sell licences for neither. A hypervisor security product is not an argument for changing hypervisor.
- ✗That we know whether it pays off. No price has been published, it is sold as a separate product, and we have not put it through a lab. Everything above is public documentation and statements made today. The day we test it with metal in front of us, we will report it with numbers and with whatever snags we find.
The two questions that decide whether it helps you
Neither of them is technical, which is why no brochure answers them.
First: how long did the last host take to come back? With a date on it. From entering maintenance mode to the cluster regaining full redundancy. If that number exists nowhere, you do not have a maintenance window; you have an expectation. And expectations cannot be multiplied by your host count.
Second: who signs off on the window? Security wants the patch in; whoever owns the ERP wants nobody touching anything until after month-end close. As long as that argument has no owner with a name on it, any layer that lets you avoid deciding will be used to avoid deciding. That is the trap in buying time: it works, and precisely because it works, next month you are in the same place.
If both questions have answers in your shop, HyperArmor takes pressure off during the weeks between the advisory and the window, and that is worth money. If they do not, what you are buying is not security: it is a postponement of the same conversation, renewable monthly.
What stays on the record
A virtual patch expires the day the real one lands. Until then, your hypervisor's binary is still yesterday's, and that has to be written down wherever you record what is mitigated and what is fixed, which are not the same column.
Broadcom has put breathing room on sale. The reboot is still yours.
Sources (checked 13 Oct 2026): the names of the three capabilities, the Paul Turner quote, the Stephen Elliot (IDC) quote, ESX 8.x support and the "with no downtime, software upgrades, or in-guest agents" line come from the press release Broadcom Introduces VMware HyperArmor (Palo Alto, 13 Oct 2026). The Eric Chen quotes, the default blocking of executables and scripts, the baseline inventory, the second-factor detail and the fact that pricing was not disclosed come from SiliconANGLE. Prashanth Shenoy's statements on the monthly cadence, bugs found by AI and "room to breathe", and that it is sold as a separate add-on, come from The Register, reporting from VMware Explore Frankfurt. What Live Patch avoids, its requirements and its exclusions —TPM, DPUs, FSR, single vLCM image, DRS, sequential remediation— come from the vSphere Lifecycle Manager documentation and from Broadcom knowledge base article 419942, which is where the note about TPM compatibility starting in 9.1 appears. Lockdown mode's behaviour with SSH and the exception users list comes from Lockdown Mode Behavior. The execInstalledOnly details —what it enforces, that it requires UEFI secure boot, that it ships disabled and that it needs a restart— come from its techdocs page. Every quoted sentence is verbatim from those sources. We have not tested HyperArmor: there is no measurement of our own in this piece.
How long did the last host you rebooted take to come back?
If the answer is "it depends", the window does not exist yet. At everyWAN we run hypervisors in production and provide the 24x7 support for the small hours when a host does not come back; we document the controls and the accepted risk under compliance and continuity, which is where that distinction has to be written down; and when the window goes unsigned because security and applications cannot agree, that is solved by a team with shared objectives, which is what the RID programme is for.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN