Eric Chen es distinguished engineer de Broadcom y uno de los que han construido el producto. Describió así su propio virtual patching: «we always still want you to patch; that is the right thing to do, but this basically buys you time». Tiene razón en las dos mitades, y se agradece que lo diga él. La pregunta que queda abierta es en qué vas a gastar ese tiempo. Porque si no parcheaste a tiempo no fue porque no supieras que había un parche.
Qué es, en las palabras del fabricante
La nota lleva fecha de hoy, 13 de octubre de 2026, y dateline de Palo Alto; el mismo día, VMware lo cuenta en VMware Explore on Tour Frankfurt, que se celebra hoy y mañana. VMware HyperArmor protege el componente ESX de VMware Cloud Foundation, soporta ESX 8.x y posteriores, se vende como producto aparte, como add-on de VCF, y no tiene precio publicado. Son tres piezas, con los nombres que les pone el fabricante:
- 1«Virtual patching for VCF's ESX Component Host Environment». Detecta y bloquea el intento de explotación sin tocar el software vulnerable: ni reinicio del host ni actualización. El binario sigue siendo el mismo de ayer.
- 2«Positive Host Security Guardrails». Lista blanca de ejecución: «unauthorized executables and scripts are blocked by default». Para no romperte nada el primer día, inventaría los scripts que ya hay en el host y los da por buenos; los nuevos los apruebas tú.
- 3«Hypervisor-level multi-factor authentication». Al SSH del ESX le añade un segundo factor: credenciales y, detrás, un código temporal «tied to a separate identity». Con la contraseña de root robada no se llega a la línea de comandos.
Paul Turner, chief product officer de la división de VMware Cloud Foundation, lo resume así: «VMware HyperArmor takes a different approach by allowing only what is 'known good' to run on the host». El reclamo central de la nota es que todo esto llega «with no downtime, software upgrades, or in-guest agents». Son exactamente las tres cosas que convierten una actualización de hipervisor en un proyecto.
Por qué ahora: el ritmo lo marca otro
El contexto lo puso en Frankfurt Prashanth Shenoy, de Broadcom: VMware pasó hace poco a publicar actualizaciones mensuales, en parte para atender fallos encontrados por IA. Y Shenoy reconoce que ya antes de ese cambio los clientes «struggled to keep up with the pace of change», porque probar el impacto de un parche lleva tiempo. Su manera de decirlo es que a la gente le hace falta «room to breathe». Eso es lo que se pone hoy a la venta.
La nota remata la idea con Stephen Elliot, de IDC: «attackers are using automation and AI to exploit infrastructure weaknesses faster than most organizations can patch». Es la misma cuenta que hicimos en La IA ya encuentra fallos de día cero sola: el cuello de botella son los días que pasan entre que existe el parche y entra en tu producción. Lo nuevo de hoy es que esa aceleración ya no se nota solo en el calendario del atacante. Se nota en el calendario del fabricante, y ese sí lo tienes que seguir tú.
Ya tenías una forma de no reiniciar. Viene con lista de exclusiones
Desde vSphere 8.0 Update 3 existe Live Patch, y su documentación promete exactamente lo mismo que el titular del producto nuevo. Durante la remediación, dice Broadcom, «vSphere Lifecycle Manager does not place the hosts in the cluster into maintenance mode», los hosts no se reinician y «there is no need to migrate the virtual machines running on the hosts in the cluster». Gratis, dentro de lo que ya pagas.
La letra pequeña ocupa más. Live Patch exige que el clúster se gestione con una imagen única de vSphere Lifecycle Manager —no funciona con baselines, y la conversión es de ida: una vez convertido no se vuelve—, exige DRS activado y obliga a parchear secuencialmente, host a host. Hay dos líneas más: «Live Patch is incompatible with systems configured with TPM devices or systems using DPUs via vSphere Distributed Services Engine», con la coletilla de que la compatibilidad con TPM empieza en vSphere 9.1.
El camino gratuito para no reiniciar deja fuera a los hosts configurados con TPM. Es el mismo expediente del que hablábamos en Hardening de VCF: el P0 cierra la puerta y el P2 te deja la llave — los controles no se contradicen en el papel, se contradicen en el host concreto que tienes montado. Hay salida —vSphere 9.1 levanta la restricción—, pero la salida es otra actualización, que es exactamente el trabajo que estabas intentando aplazar.
Hay una tercera exclusión, esta del lado de las máquinas virtuales: las que no soportan Fast Suspend and Resume —Fault Tolerance, DirectPath I/O en passthrough, vSphere pods, clúster de disco compartido— hay que migrarlas o apagarlas y encenderlas igualmente. Y en el mismo artículo de la base de conocimiento: «remediation is blocked if you attempt a live patch on hosts that require maintenance mode». El parche en caliente no te avisa de que ese host queda fuera de su alcance: bloquea la remediación entera.
De las tres piezas, una ya la tienes gratis. Y está apagada
Este es el orden que nos parece útil: empezar por lo que ya tienes y acabar por lo que de verdad hay que comprar.
- →El segundo factor del SSH. En ESXi 8 el SSH viene desactivado de fábrica. Si está apagado y nadie lo enciende, no hay login que proteger. El matiz importa: el modo lockdown no cierra esa puerta, la documentación de Broadcom lo dice en una línea —«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»—. Así que la pregunta útil es quién está en la lista de excepciones y por qué. Si ahí hay una cuenta que abriste para un caso de soporte de hace año y medio, el MFA del fabricante te tapa un agujero real.
- →La lista blanca de ejecución. ESXi ya trae una, más estricta y gratis:
execInstalledOnly, que hace que «the VMkernel executes only those binaries that have been packaged and signed as part of a VIB». Las pegas están escritas en la misma página: exige el arranque seguro UEFI por debajo, viene en false de serie y encenderla pide reiniciar el host. Es decir, la versión gratuita del «solo corre lo conocido» cuesta justo lo que el producto de pago promete ahorrarte. - →El virtual patching. Esta no la puedes construir, y es honesto decirlo. Hace falta saber qué secuencia de llamadas explota qué fallo en qué versión del hipervisor, y eso lo sabe quien escribe el hipervisor. Y el argumento del fabricante es ese: Broadcom sabe qué procesos deberían correr en su hipervisor, y por eso puede imponer la restricción dentro del host y no solo inspeccionando la red. Es el argumento más fuerte del producto, y no tiene equivalente casero.
Queda un detalle de la pieza 2 que conviene mirar de frente, porque es la diferencia entre una lista blanca y una fotografía. La línea base de HyperArmor se construye inventariando los scripts que ya están corriendo y permitiéndolos. Es la decisión correcta para que el producto se pueda encender un martes sin romper la mitad de la plataforma. Pero el «known good» de Turner da por supuesto que el host estaba bien el día que se tomó la foto. Si llevabas algo dentro desde antes, la línea base lo bendice y pasa a ser autorizado por escrito.
Lo que no vamos a decirte
- ✗Que esto sea humo. No lo es. Es una mitigación real, descrita con precisión por quien la ha hecho, y cubre dos caminos de entrada que existen: la credencial de root robada y el fallo sin parchear. Que la frase de cabecera del producto la ponga su propio ingeniero en «te compra tiempo» es más honesto que la media del sector.
- ✗Que te vayas de VMware por esto. Y lo decimos con el conflicto de interés por delante: hacemos migraciones de VMware a Proxmox, y no somos resellers de Proxmox ni de VMware —no vendemos licencias de ninguna de las dos—. Un producto de seguridad del hipervisor no es un argumento para cambiar de hipervisor.
- ✗Que sabemos si sale a cuenta. No se ha publicado precio, se vende como producto aparte y no lo hemos pasado por laboratorio. Todo lo de arriba es documentación pública y declaraciones de hoy. El día que lo probemos con hierro delante, lo contaremos con números y con las pegas que encontremos.
Las dos preguntas que deciden si te sirve
Ninguna de las dos es técnica, y por eso no las contesta ningún folleto.
Primera: ¿cuánto tardó el último host en volver? Con fecha. Desde que entró en modo mantenimiento hasta que el clúster recuperó la redundancia completa. Si ese número no existe en ningún sitio, no tienes una ventana de mantenimiento; tienes una expectativa. Y las expectativas no se pueden multiplicar por el número de hosts.
Segunda: ¿quién firma la ventana? Seguridad quiere el parche dentro; quien responde del ERP quiere que nadie toque nada hasta después del cierre de mes. Mientras esa discusión no tenga un dueño con nombre, cualquier capa que permita no decidir se va a usar para no decidir. Esa es la trampa de comprar tiempo: funciona, y precisamente porque funciona, el mes que viene estás igual.
Si las dos preguntas tienen respuesta en tu casa, HyperArmor te quita presión de encima durante las semanas que van del aviso a la ventana, y eso vale dinero. Si no la tienen, lo que compras no es seguridad: es el aplazamiento de la misma conversación, renovable todos los meses.
Lo que queda apuntado
El parche virtual caduca el día que entra el de verdad. Hasta entonces, el binario de tu hipervisor sigue siendo el de ayer, y eso tiene que estar escrito en el sitio donde apuntas lo que está mitigado y lo que está corregido, que no son la misma columna.
Broadcom ha puesto a la venta la respiración. El reinicio sigue siendo tuyo.
Fuentes (consultadas el 13-10-2026): los nombres de las tres capacidades, la cita de Paul Turner, la de Stephen Elliot (IDC), el soporte de ESX 8.x y el «with no downtime, software upgrades, or in-guest agents» salen de la nota de prensa Broadcom Introduces VMware HyperArmor (Palo Alto, 13-10-2026). Las citas de Eric Chen, el bloqueo por defecto de ejecutables y scripts, el inventario de la línea base, el detalle del segundo factor y que el precio no se ha hecho público, de la cobertura de SiliconANGLE. Las declaraciones de Prashanth Shenoy sobre la cadencia mensual, los fallos encontrados por IA y el «room to breathe», y que se vende como producto aparte, de The Register desde VMware Explore Frankfurt. Lo que Live Patch evita, sus requisitos y sus exclusiones —TPM, DPU, FSR, imagen única de vLCM, DRS, remediación secuencial—, de la documentación de vSphere Lifecycle Manager y del artículo 419942 de la base de conocimiento de Broadcom, que es donde figura que la compatibilidad con TPM empieza en 9.1. El comportamiento del modo lockdown con el SSH y la lista de excepciones, de Lockdown Mode Behavior. Lo de execInstalledOnly —qué aplica, que exige arranque seguro UEFI, que viene desactivado y que pide reinicio—, de su página en techdocs. Todas las frases entrecomilladas son literales de esas fuentes. No hemos probado HyperArmor: no hay aquí ninguna medición propia.
¿Cuánto tardó en volver el último host que reiniciaste?
Si la respuesta es «depende», la ventana no existe todavía. En everyWAN operamos hipervisores en producción y damos el soporte 24x7 de la madrugada en que un host no vuelve; documentamos los controles y el riesgo asumido en cumplimiento y continuidad, que es donde esa distinción tiene que quedar escrita; y cuando la ventana no se firma porque seguridad y aplicaciones no se ponen de acuerdo, eso lo resuelve un equipo con objetivos compartidos, que es de lo que va el programa RID.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN