The detail is in the baseline
Start with the scripts already on the host. Broadcom says HyperArmor inventories them and automatically allows them. That small implementation detail deserves as much attention as the wider security promise. An allowed script is not necessarily a safe one.
Announced October 13 for ESX 8.x and later, VMware HyperArmor combines host-level virtual patching, controls on executable code and scripts, and an additional authentication factor for SSH access. Broadcom says the protections work without guest agents and can mitigate vulnerabilities without host reboots or upgrades. Those are vendor claims, not results from Silver Owl attack testing.
The baseline therefore needs scrutiny before it becomes an operating assumption. Who reviews the code already present? How are later exceptions approved, audited and removed? These questions concern the starting point of the protection; the announcement does not demonstrate that any particular customer's existing host is clean.
Source: Broadcom announcement · 2026-10-13 · Primary source context · attributed account
Protection still needs a defined scope
The attraction is understandable: if the no-reboot claim holds, administrators could gain time to test official patches while workloads keep running. Virtual patching remains a mitigation claim. It does not establish that the underlying software defect has gone away.
Exploit coverage, false positives, emergency access, overhead and commercial terms remain evaluation questions. So does the boundary around authentication: a second factor on SSH does not prove equivalent protection across every management interface. Test HyperArmor against a defined threat model. Know what it covers, and be equally clear about what it does not establish.
Source: Broadcom announcement · 2026-10-13 · Primary source context · attributed account