VMware HyperArmor: What It Adds to ESX Security, and Whether You Need It

‍

Last verified: October 16, 2026.

Broadcom announced VMware HyperArmor on October 13, 2026, at VMware Explore on Tour in Frankfurt. HyperArmor is a security add-on for the ESX hypervisor. It adds three controls to each host: virtual patches, an allow list for executables and scripts, and multi-factor authentication (MFA) on SSH logins.

The most important fact is simple. HyperArmor gives you time between the disclosure of a vulnerability and the installation of its patch. Eric Chien, a Broadcom engineer who helped build the product, told SiliconANGLE that customers must still patch, and that HyperArmor “basically buys you time.”

Today, HyperArmor is an announcement. Broadcom has not published a release date, a price or technical documentation. Each functional claim below that comes only from Broadcom carries the label Broadcom states.

Your Broadcom account team will probably offer HyperArmor at your next VMware Cloud Foundation renewal. Before that call, you need one answer: what does HyperArmor add to the ESX 8 controls that you already own? Part of the answer is a control that you can activate today with no extra license.

‍

What VMware HyperArmor is

VMware HyperArmor is a host security product for ESX 8.x and later. Broadcom states that it operates at the ESX layer and needs no agents inside guest virtual machines. It has three components:

• Host-level virtual patching. Broadcom states that HyperArmor detects and blocks malicious actions on the host before an attacker can exploit a vulnerability. A virtual patch needs no host reboot and no ESX upgrade.
• Positive Host Security Guardrails. This is the allow list. Broadcom states that an ESX host runs a small, fixed set of processes, so HyperArmor blocks each executable or script that is not on the list.
• MFA on SSH. HyperArmor adds a time-based one-time password (TOTP) after the usual SSH credentials. The TOTP connects to an identity that you define separately.

The press release positions HyperArmor for VMware Cloud Foundation (VCF). The VCF launch blog says that Broadcom built it for VCF and for VMware vSphere Foundation (VVF). If you run VVF, get the supported editions in writing before you budget.

Prashanth Shenoy, a Broadcom product marketing vice president, told TechTarget that HyperArmor is “an optional add-on.” Channel Dive reports that Broadcom partners sell it per core. No Broadcom source puts HyperArmor inside a VCF edition.

A note on names: Broadcom renamed ESXi to ESX with version 9.0, which shipped on June 17, 2025. HyperArmor materials refer to ESX 8.x, the release that shipped as ESXi 8. This article uses ESX for both.

‍

How HyperArmor works on an ESX host

A vendor patch fixes the code. A virtual patch blocks the path to the defective code until the fix is on the host. HyperArmor gives you that block on the host itself, while your patch moves through test and change control.

‍

Host-level virtual patching: two possible models

Broadcom states that HyperArmor intercepts malicious actions during process execution, in real time. Broadcom has not documented the mechanism. The public descriptions point to two different models.

Shenoy told TechTarget that HyperArmor blocks any execution that is not on an approved list, whatever vulnerability is behind it. That is a behavior model. The launch blog says that HyperArmor shields hosts from the latest critical CVEs. That reads as a per-vulnerability model.

The difference matters for one class of attack. In March 2025, VMSA-2025-0004 fixed ESXi flaws that let an attacker run code in the VMX process and escape its sandbox. An allow list stops new programs. An exploit that stays inside an approved process can need a per-vulnerability control. Ask Broadcom which model covers that case.

The allow list: Positive Host Security Guardrails

Broadcom states that HyperArmor takes an inventory of the scripts on each host and allows them automatically. Administrators approve new scripts. The launch blog adds file write attempts and unauthorized configuration changes to the list of blocked actions.

The inventory trusts what it finds. If an attacker already has a script on the host, the inventory can allow it. Build the baseline on a host that you trust, and reinstall a doubtful host from a known image first.

Each change to the host also meets the allow list. A new VIB, a hardware vendor agent or a backup script can need an approval. Broadcom has not documented how installs and patches update the list, so test this in a lab before production.

‍

MFA on the ESX SSH login path

HyperArmor adds a TOTP challenge after the SSH user name and password. This step targets a known attack path. The CISA and FBI #StopRansomware: Akira advisory lists SSH as a lateral movement technique, and Akira has an ESXi encryptor.

Native ESX 8 has no documented MFA for a direct SSH session on a host. vCenter supports MFA through identity federation, but that control applies to vCenter logins. Before you activate HyperArmor MFA, write down the break-glass process for an outage when the TOTP identity is not available.

Why HyperArmor needs no guest agents

HyperArmor runs on the host, so you change nothing inside the guest operating systems. The same fact sets its limit. HyperArmor gives no documented protection to a Windows or Linux guest, so your in-guest EDR stays in place.

How HyperArmor relates to live patching

Live patching installs the real patch without maintenance mode. HyperArmor covers the time before a patch exists, or before your tests are complete. The two controls work on different parts of the same window.

On ESX 8, live patching applies to the VM execution runtime (vmx) only. It needs DRS in fully automated mode, and it does not support hosts with TPM devices. VCF 9.0 extends live patching to the vmkernel, user-space daemons and NSX components. The VCF 9.1 FAQ says that VCF 9.1 activates live patching by default and supports TPM-enabled hosts.

Not every patch qualifies. The ESX 9.0.2.0 release of January 20, 2026, carries the note Live Patchable: No. On ESX 8, check one more conflict: the TPM that enforces execInstalledOnly is also the device that ESX 8 live patching does not support. Confirm the behavior for your ESX 8 build before you plan around both controls.

‍

What ESX 8 and VMware Cloud Foundation already protect

ESX 8 already contains the base of an allow list. The execInstalledOnly setting lets only binaries from installed, signed packages (VIBs) run. The weak point is the switch: the protection that stops someone from turning it off is off until you activate it.

An HPE knowledge base article says that the runtime flag is on by default in ESX 8, and the boot-time option is off. Broadcom TechDocs describes the enforcement step. It uses the TPM to stop anyone from turning execInstalledOnly off, and it needs Secure Boot enforcement first.

Many environments that I see described as hardened have the runtime flag and nothing more. Without enforcement, an attacker with root can change the setting. Activate enforcement before you pay for a second allow list.

‍

VCF 9.x adds more host controls. ESX 9.0 adds script sandboxing for Python and shell scripts. VCF 9.1 adds a framework for third-party EDR agents on ESX, and File Integrity Monitoring that checks vCenter-installed files every four hours.

VMware vDefend works one layer out. It gives microsegmentation, distributed IDS/IPS and network-level virtual patching, and you license it separately from VCF. HyperArmor works on the host. Shenoy put the split in one line for SiliconANGLE: HyperArmor is at the ESX host layer.

The matrix below takes six attack techniques one at a time. Select a technique to see what each layer documents, and the question to ask Broadcom.

‍

Three claims stay after the comparison. Only HyperArmor claims host-level virtual patching, an allow list that covers scripts and file writes with an approval step, and MFA on host SSH. Each claim waits for documentation.

Also, some value depends on your current state. If execInstalledOnly enforcement is not active on your hosts, activate it first. The checklist below gives the six native steps that I complete before any discussion about an add-on.

‍

Why attackers target the ESX hypervisor

One host runs many virtual machines. When an attacker gets admin access to the host, the attacker can encrypt every workload on it in one operation. Microsoft Threat Intelligence documented this mass-encryption pattern in July 2024.

Broadcom states that most hypervisor attacks come from stolen root credentials and unpatched vulnerabilities. Broadcom has published no data for the word most. The government record shows both paths:

• In February 2023, the CISA and FBI advisory AA23-039A on ESXiArgs counted over 3,800 compromised servers worldwide. The advisory says that the actors may exploit known flaws in unpatched ESXi.
• In July 2024, attackers used CVE-2024-37085 to get full host admin rights through an Active Directory group named ESX Admins.
• In March 2025, CISA listed three VMSA-2025-0004 flaws as exploited on the day that VMware published the fixes.

Since January 2023, the CISA Known Exploited Vulnerabilities catalog has listed four ESXi CVEs. Two carry the known ransomware use flag.

‍

The CVSS score does not predict exploitation here. The lowest score on the chart, 6.8 for CVE-2024-37085, belongs to a flaw with confirmed ransomware use. Microsoft named Storm-0506, Storm-1175, Octo Tempest and Manatee Tempest, with Akira and Black Basta deployments.

Map these incidents to HyperArmor, and the fit is partial. SSH MFA addresses the stolen-password path over SSH. The allow list addresses a dropped encryptor binary, as enforced execInstalledOnly does today. CVE-2024-37085 used an Active Directory path, and a host setting closes it. Broadcom documents no HyperArmor control for that path.

‍

What VMware HyperArmor does not do

HyperArmor covers one layer for one period of time. Five jobs stay with your team.

You still patch. Broadcom says that virtual patching gives teams time to “test and apply official patches on the schedule they prefer.” The real patch removes the defect. A virtual patch only blocks a path to it, and only if a virtual patch exists for that flaw.

Guest operating systems keep their own protection. HyperArmor runs on the host and gives no documented protection inside a guest. Your EDR, patch tools and backups for Windows and Linux guests stay in place.

ESXi 7 hosts get no coverage. HyperArmor supports ESX 8.x and later. vSphere 7.0 reached End of General Support on October 2, 2025, and ESXi 7 gets no more patches. HyperArmor does not extend the life of those hosts, so upgrade them first.

vCenter stays outside its scope. HyperArmor is a host product. CISA added a vCenter Server flaw, CVE-2026-59310, to the KEV catalog on August 18, 2026. Patch and isolate vCenter on its own schedule.

Budget stays an open line. HyperArmor is a separate purchase, it is not yet available, and Broadcom has not published a price.

‍

Do you need VMware HyperArmor? Five situations

The value of HyperArmor depends on two numbers: how long your hosts stay exposed, and how much native hardening you already run. Shenoy told TechTarget that customers with lower exposure do not have to buy it. I agree with that test.

You renew VCF and your change windows are long. If a critical host patch takes weeks to reach every host, a virtual patch covers those weeks. HyperArmor is worth an evaluation. Ask for the virtual patch record for the last critical ESX flaw before you sign.

You work in a regulated environment with slow patch cycles. The same logic applies, and SSH MFA adds a second benefit. If an auditor or insurer asks for MFA on every admin path, host SSH is a common gap. See the evidence that insurers and auditors accept before you count HyperArmor as proof.

Your hosts are already hardened. SSH is off, lockdown mode is on and execInstalledOnly enforcement is active. The benefit is smaller. Virtual patching is the main addition left, so the virtual patch speed decides the case.

You plan to leave VMware within 12 to 18 months. HyperArmor is probably not worth it. Use the native checklist above, and put the budget into the migration.

You still run ESXi 7. HyperArmor does not support it. Upgrade to ESX 8 or migrate first.

‍

If you are leaving VMware: host hardening on Hyper-V, Proxmox and Nutanix

If HyperArmor arrives in the same year as your exit plan, compare host hardening on the platform that you move to. Each alternative documents its own controls for code integrity, admin access and baseline drift. The cards below list what each vendor documents, with no ranking.

For the wider platform choice, start with VMware alternatives in 2026 and the Hyper-V vs VMware vs Nutanix comparison. Plan your recovery path early too: your backup strategy changes when you leave VMware.

‍

Questions to ask Broadcom before you buy HyperArmor

Broadcom has not published answers to the questions that decide a security purchase. Ask them in writing, and attach the answers to the renewal file. If the answer is not documented yet, record that too.

Three questions carry the most weight. The virtual patch record shows the real size of the time that HyperArmor buys. The fail-open or fail-closed answer shows the outage risk. The overlap answer shows what you pay for beyond execInstalledOnly.

Root credentials are the second attack path that Broadcom names. Treat ESX root accounts as privileged accounts, with vaulted passwords and session records, whatever you decide on HyperArmor.